[[376045]]

本文轉(zhuǎn)載自微信公眾號「安琪拉的博客」，作者安琪拉的博客 。轉(zhuǎn)載本文請聯(lián)系安琪拉的博客公眾號。

 這個(gè)問題是安琪拉之前面試被問到的一個(gè)問題，正好順著上一篇文章介紹完線程調(diào)用時(shí)的用戶態(tài)和內(nèi)核態(tài)的切換，后續(xù)把Java 并發(fā)的都一起講了。

面試官：聽前一個(gè)面試官說你Java并發(fā)這塊掌握的不錯(cuò)，我們深入的交流一下;

我: 看了看面試官頭部稀疏的結(jié)締組織，已然覺得這場面試不簡單，不過好在事前把安琪拉的博客看了個(gè)遍，有所準(zhǔn)備，我回答說：咳咳，掌握的還算可以。

面試官：Java線程用過的吧?

我：用過。

面試官：那你給我講講Java線程和操作系統(tǒng)的?

我：啊!!!

劇情不應(yīng)該這樣的啊，開場不應(yīng)該先是 synchronized 或者 volatile，再然后是線程池和AQS，怎么上來就整這玩意。

我：好的，那我分三段講，

• 用戶態(tài)的線程
• 內(nèi)核態(tài)的線程
• Java 線程源碼

1. 用戶態(tài)的線程

第一階段:

其實(shí)早期的時(shí)候，操作系統(tǒng)是沒有線程的概念，線程是后面加進(jìn)來的，操作系統(tǒng)剛開始只有進(jìn)程，操作系統(tǒng)分配資源的最小單位是進(jìn)程，進(jìn)程與進(jìn)程之間相關(guān)隔離，每個(gè)進(jìn)程有自己的內(nèi)存空間，文件描述符，CPU調(diào)度以進(jìn)程作為最小調(diào)度單元;

第二階段:

初期的多線程，線程是在用戶空間下實(shí)現(xiàn)的。

什么意思?我們都知道內(nèi)存分用戶空間和系統(tǒng)空間，系統(tǒng)空間是給操作系統(tǒng)使用的，用戶空間是應(yīng)用程序使用的，應(yīng)用程序如果需要訪問系統(tǒng)空間，需要進(jìn)行系統(tǒng)調(diào)用，從用戶態(tài)切換到內(nèi)核態(tài)，這里詳細(xì)可以參考我上一篇文章: [講講用戶空間和內(nèi)核空間]

那怎么在用戶空間實(shí)現(xiàn)的多線程呢?

實(shí)際上是操作系統(tǒng)按進(jìn)程維度來調(diào)度，操作系統(tǒng)是不去管你用戶線程的切換的，應(yīng)用程序自己在用戶空間實(shí)現(xiàn)線程的創(chuàng)建、維護(hù)和調(diào)度。模型如下圖:

當(dāng)線程在用戶空間下實(shí)現(xiàn)時(shí)，操作系統(tǒng)對線程的存在一無所知，操作系統(tǒng)只能看到進(jìn)程，而不能看到線程。所有的線程都是在用戶空間實(shí)現(xiàn)。在操作系統(tǒng)看來，每一個(gè)進(jìn)程只有一個(gè)線程。

這種方式的好處之一就是即使操作系統(tǒng)不支持線程，也可以通過庫函數(shù)來支持線程。在JDK1.1中，就用的綠色線程，而不是原始線程。

下面是關(guān)于green thread的解釋，因?yàn)間reen thread不是今天的重點(diǎn)，就不細(xì)說了。

green threads 是一種由運(yùn)行環(huán)境或虛擬機(jī)(VM)調(diào)度，而不是由本地底層操作系統(tǒng)調(diào)度的線程。綠色線程并不依賴底層的系統(tǒng)功能，模擬實(shí)現(xiàn)了多線程的運(yùn)行，這種線程的管理調(diào)配發(fā)生在用戶空間而不是內(nèi)核空間，所以它們可以在沒有原生線程支持的環(huán)境中工作。

在Java 1.1中，綠色線程(至少在 Solaris 上)是JVM 中使用的唯一一種線程模型。由于綠色線程和原生線程比起來在使用時(shí)有一些限制，隨后的 Java 版本中放棄了綠色線程，轉(zhuǎn)而使用native threads。

這種模式的優(yōu)點(diǎn)和缺點(diǎn)都非常明顯:

缺點(diǎn): 因?yàn)椴僮飨到y(tǒng)不知道線程的存在，CPU的時(shí)間片切換是以進(jìn)程為維度的，如果進(jìn)程中有某個(gè)線程進(jìn)行了某些耗時(shí)長的操作，會(huì)阻塞整個(gè)進(jìn)程。另外當(dāng)一個(gè)進(jìn)程中的某一個(gè)線程(綠色線程)進(jìn)行系統(tǒng)調(diào)用時(shí)，比如網(wǎng)絡(luò)IO、缺頁中斷等操作而導(dǎo)致線程阻塞，操作系統(tǒng)也會(huì)阻塞整個(gè)進(jìn)程，即使這個(gè)進(jìn)程中其它線程還在工作。

優(yōu)點(diǎn): 使用庫函數(shù)來實(shí)現(xiàn)的線程切換，就免去了用戶態(tài)到內(nèi)核態(tài)的切換，這個(gè)味道熟不熟，對了，Go的協(xié)程就有借鑒了一部分這個(gè)思想。

2. 內(nèi)核態(tài)的線程

在 Java1.2 之后. Linux中的JVM是基于pthread實(shí)現(xiàn)的, 可以直接說 Java 線程就是依賴操作系統(tǒng)實(shí)現(xiàn)的，是1:1的關(guān)系。

現(xiàn)在的Java中線程的本質(zhì)，其實(shí)就是操作系統(tǒng)中的線程

另外我看很多資料上說 Java線程的實(shí)現(xiàn)采用的是LWP(輕量級進(jìn)程)，實(shí)際上從Linux 內(nèi)核2.6開始，就把LinuxThread 換成了新的線程實(shí)現(xiàn)方式NPTL，NPTL解決了LinuxThread中絕大多數(shù)跟POSIX標(biāo)準(zhǔn)不兼容的特性，并提供了更好的性能，可擴(kuò)展性及可維護(hù)性等等。

LinuxThread使用的是1 * 1模型，即每一個(gè)用戶態(tài)線程都有一個(gè)內(nèi)核的管理實(shí)體跟其對應(yīng)，這個(gè)內(nèi)核對應(yīng)的管理實(shí)體就是進(jìn)程，又稱LWP(輕量級進(jìn)程)

希望了解更多NPTL的可以去看詳細(xì)介紹NPTL.

我們知道，每個(gè)線程都有它自己的線程上下文，線程上下文包括線程的ID、棧、程序計(jì)數(shù)器、通用的寄存器等的合集?？傆X得上下文這個(gè)詞很模棱二可，但是發(fā)現(xiàn)也找不到更合適的詞來描述。

線程有自己的獨(dú)立的上下文，由操作系統(tǒng)調(diào)度，但是也有一個(gè)缺點(diǎn)，那就是線程消耗資源太大了，例如在linux上，一個(gè)線程默認(rèn)的棧大小是1M，單機(jī)創(chuàng)建幾萬個(gè)線程就有點(diǎn)吃力了。所以后來在編程語言的層面上，就出現(xiàn)了協(xié)程這個(gè)東西。

協(xié)程的模式有點(diǎn)類似結(jié)合了上面二種方式，即是在用戶態(tài)做線程資源切換，也讓操作系統(tǒng)在內(nèi)核層做線程調(diào)度。

協(xié)程跟操作系統(tǒng)的線程是有映射關(guān)系的，例如我們建了m個(gè)協(xié)程，需要在N個(gè)線程上執(zhí)行，這就是m: n的方案，這n個(gè)線程也是靠操作系統(tǒng)調(diào)度實(shí)現(xiàn)。

另外協(xié)程是按需使用棧內(nèi)存的，所以理論上可以輕輕松松創(chuàng)建百萬級的協(xié)程。

目前協(xié)程這塊支持的最好的是go語言, 不過現(xiàn)在OpenJDK社區(qū)也正在為JDK增加協(xié)程的支持。

3. 線程的源碼

我們在Java中調(diào)用 new Thread(Runnable ***).start() 方法時(shí)，怎么從用戶態(tài)切到內(nèi)核態(tài)，發(fā)送系統(tǒng)調(diào)用，在操作系統(tǒng)內(nèi)核層中創(chuàng)建一個(gè)線程的呢?

這個(gè)可以一步步往下鉆，關(guān)鍵點(diǎn)最后在JVM層系統(tǒng)調(diào)用pthread_create創(chuàng)建線程。

首先是native方法: private native void start0();

下到Thread.c 文件，：

OpenJDK1.8源代碼第44行，方法映射;追著 JVM_StartThread 進(jìn)到 jvm.cpp

linux 系統(tǒng)下的，看 src/hotspot/os/linux/os_linux.cpp

主要關(guān)注 pthread_create 這里，是通過linux 的 c庫函數(shù)完成系統(tǒng)調(diào)用，從用戶態(tài)切到內(nèi)核態(tài)完成線程的創(chuàng)建。

文中源代碼地址:

Thread.c 
 
pthread_create 
 
os_linux