jvm 實現多線程，本質上是調用所在平臺系統的接口創建多線程或者多進程。比如windows上，jvm調用_beginthreadex創建線程，這是內核線程。對于Linux，Linux從內核2.6開始使用NPTL （Native POSIX Thread Library）支持，但這時線程本質上還輕量級進程。其和核心線程一一對應，但也算是內核線程。 因為是內核線程直接提供支持和對應創建，銷毀。

Java里的線程是由JVM來管理的，它如何對應到操作系統的線程是由JVM的實現來確定的。Linux 2.6上的HotSpot使用了NPTL機制，JVM線程跟內核輕量級進程有一一對應的關系。線程的調度完全交給了操作系統內核，當然jvm還保留一些策略足以影響到其內部的線程調度，舉個例子，在linux下，只要一個Thread.run就會調用一個fork產生一個線程。

Java線程在Windows及Linux平臺上的實現方式，現在看來，是內核線程的實現方式。這種方式實現的線程，是直接由操作系統內核支持的——由內核完成線程切換，內核通過操縱調度器（Thread Scheduler）實現線程調度，并將線程任務反映到各個處理器上。內核線程是內核的一個分身。程序一般不直接使用該內核線程，而是使用其高級接口，即輕量級進程（LWP），也即線程。這看起來可能很拗口。看圖：

（說明：KLT即內核線程Kernel Thread，是“內核分身”。每一個KLT對應到進程P中的某一個輕量級進程LWP（也即線程），期間要經過用戶態、內核態的切換，并在Thread Scheduler 下反應到處理器CPU上。）

這種線程實現的方式也有它的缺陷：在程序面上使用內核線程，必然在操作系統上多次來回切換用戶態及內核態；另外，因為是一對一的線程模型，LWP的支持數是有限的。畢竟占用內核空間，給調度器帶來困難。不多對于多核CPU，我們可以適當的放寬內核線程數目。對于內核線程出現堵塞，那么內核將要將線程掛起，那么線程就會從內核狀態切換到用戶狀態，這也是很耗資源的。

對于有些平臺或者程序完全是建立在用戶線程上的（有的數據庫多線程），也就是內核里面只對應一個內核線程，但是上層多線程的同步，切換需要完全由開發者設計和實現。（UT User thread）這當然也需要系統的用戶線程的提供接口支持。

當然有的程序設計是基于內核線程和用戶線程混合的模式，在基于Unix平臺上的幾款虛擬機就是這樣設計的。

可見對于jvm多線程的實現僅僅從線程的角度就分好幾種（基于線程，有的多線程是基于進程如PHP）。

確立多核并發系統或者多CPU系統線程合適數目：

對于一個大型程序，我們可以開辟的線程數量至少等于運行機器的cpu內核數量。java程序里我們可以通過下面的一行代碼得到這個數量：

Runtime.getRuntime().availableProcessors();所以最小線程數量即時cpu內核數量。如果所有的任務都是計算密集型的，這個最小線程數量就是我們需要的線程數。開辟更多的線程只會影響程序的性能，因為線程之間的切換工作，會消耗額外的資源。 如果任務是IO密集型的任務，我們可以開辟更多的線程執行任務。當一個任務執行IO操作的時候，線程將會被阻塞，處理器立刻會切換到另外一個合適的線程去執行。如果我們只擁有與內核數量一樣多的線程，即使我們有任務要執行，他們也不能執行，因為處理器沒有可以用來調度的線程。 所以確定合適的線程數目，簡單地依據CPU數量*內核數量是不可行的！！！ 如果線程有50%的時間被阻塞，線程的數量就應該是內核數量的2倍。如果更少的比例被阻塞，那么它們就是計算密集型的，則需要開辟較少的線程。如果有更多的時間被阻塞，那么就是IO密集型的程序，則可以開辟更多的線程。于是我們可以得到下面的線程數量計算公式： 線程數量=內核數量 / （1 - 阻塞率） 我們可以通過相應的分析工具或者java的management包來得到阻塞率的數值。
#################################################################################### 操作系統線程狀態切換圖：
Java中線程狀態轉化圖：
什么是鎖死： 兩個線程的鎖分別已經被兩個數據對象拿到，但是這兩個線程還是相互的調用已獲取鎖的數據對象，重復進行相互的鎖附加動作。那么兩個線程都會被輪回的，不斷地在鎖池隊列中和運行狀態切換，而CPU一直在空當運轉。

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的jvm 并发原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。