http://blog.sina.com.cn/s/blog_605f5b4f010198b5.html

Linux從內(nèi)核2.6開始使用NPTL （Native POSIX Thread Library）支持，但這時(shí)線程本質(zhì)上還輕量級進(jìn)程。

?

Java里的線程是由JVM來管理的。它怎樣相應(yīng)到操作系統(tǒng)的線程是由JVM的實(shí)現(xiàn)來確定的。

Linux 2.6上的HotSpot使用了NPTL機(jī)制，JVM線程跟內(nèi)核輕量級進(jìn)程有一一相應(yīng)的關(guān)系。線程的調(diào)度全然交給了操作系統(tǒng)內(nèi)核。當(dāng)然jvm還保留一些策略足以影響到其內(nèi)部的線程調(diào)度。舉個(gè)樣例。在linux下，僅僅要一個(gè)Thread.run就會調(diào)用一個(gè)fork產(chǎn)生一個(gè)線程。

Java線程在Windows及Linux平臺上的實(shí)現(xiàn)方式，如今看來，是內(nèi)核線程的實(shí)現(xiàn)方式。這樣的方式實(shí)現(xiàn)的線程，是直接由操作系統(tǒng)內(nèi)核支持的——由內(nèi)核完畢線程切換，內(nèi)核通過操縱調(diào)度器（Thread Scheduler）實(shí)現(xiàn)線程調(diào)度，并將線程任務(wù)反映到各個(gè)處理器上。內(nèi)核線程是內(nèi)核的一個(gè)分身。程序一般不直接使用該內(nèi)核線程，而是使用其高級接口，即輕量級進(jìn)程（LWP）。也即線程。

這看起來可能非常拗口。看圖：

（說明：KLT即內(nèi)核線程Kernel Thread，是“內(nèi)核分身”。

每個(gè)KLT相應(yīng)到進(jìn)程P中的某一個(gè)輕量級進(jìn)程LWP（也即線程）。期間要經(jīng)過用戶態(tài)、內(nèi)核態(tài)的切換，并在Thread Scheduler 下反應(yīng)到處理器CPU上。）

????????這樣的線程實(shí)現(xiàn)的方式也有它的缺陷：在程序面上使用內(nèi)核線程，必定在操作系統(tǒng)上多次來回切換用戶態(tài)及內(nèi)核態(tài)；另外，由于是一對一的線程模型，LWP的支持?jǐn)?shù)是有限的。

對于一個(gè)大型程序。我們能夠開辟的線程數(shù)量至少等于執(zhí)行機(jī)器的cpu內(nèi)核數(shù)量。

java程序里我們能夠通過以下的一行代碼得到這個(gè)數(shù)量：

Runtime.getRuntime().availableProcessors();
所以最小線程數(shù)量即時(shí)cpu內(nèi)核數(shù)量。假設(shè)全部的任務(wù)都是計(jì)算密集型的，這個(gè)最小線程數(shù)量就是我們須要的線程數(shù)。開辟很多其它的線程僅僅會影響程序的性能，由于線程之間的切換工作。會消耗額外的資源。假設(shè)任務(wù)是IO密集型的任務(wù)。我們能夠開辟很多其它的線程運(yùn)行任務(wù)。當(dāng)一個(gè)任務(wù)運(yùn)行IO操作的時(shí)候。線程將會被堵塞，處理器立馬會切換到另外一個(gè)合適的線程去運(yùn)行。

假設(shè)我們僅僅擁有與內(nèi)核數(shù)量一樣多的線程。即使我們有任務(wù)要運(yùn)行，他們也不能運(yùn)行。由于處理器沒有能夠用來調(diào)度的線程。

??假設(shè)線程有50%的時(shí)間被堵塞，線程的數(shù)量就應(yīng)該是內(nèi)核數(shù)量的2倍。假設(shè)更少的比例被堵塞。那么它們就是計(jì)算密集型的。則須要開辟較少的線程。

假設(shè)有很多其它的時(shí)間被堵塞。那么就是IO密集型的程序，則能夠開辟很多其它的線程。

于是我們能夠得到以下的線程數(shù)量計(jì)算公式：

線程數(shù)量=內(nèi)核數(shù)量 / （1 - 堵塞率）

轉(zhuǎn)載于:https://www.cnblogs.com/llguanli/p/7095457.html

總結(jié)

以上是生活随笔為你收集整理的Java线程与Linux内核线程的映射关系的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。