多線程那些事，硬核有趣

這兩句話，我相信99%的同學都知道！但是，如果想進企鵝巴巴，如果想應付P20的科學家！我就一定要自行的結合業(yè)務回答并發(fā)并行的優(yōu)勢！

路人S和路人B果然都露出了滿意的笑容。

這回答的累死我了，不過為了能進企鵝巴巴，走向人生巔峰，一切都值了！

是...當我要脫口而出的時候，發(fā)現(xiàn)不對，這面試官在套路我！堂堂科學家，套路還沒入職的孩子么？

1對1模型：在一對一模型中，1個ULT對應1個KLT。自己不在進程中創(chuàng)建線程表來管理，幾行代碼之后直接通過系統(tǒng)調(diào)用調(diào)起KLT就能實現(xiàn)。

多對多模型：在多對多模型中，N個ULT對應小于等于N個的KLT。這種模型結合了1對1和多對1的優(yōu)點，用戶創(chuàng)建線程沒有限制，阻塞內(nèi)核系統(tǒng)的命令不會阻塞整個進程。

最后，就拿最熱門的HotSpot VM來說吧，他在Solaris上就有兩種線程實現(xiàn)方式，可以讓用戶選擇一對一或多對多這兩種模型；而在Windows和Linux下，使用的都是一對一的多線程模型，Java的線程通過一一映射到Light Weight Process（輕量級進程，LWP）從而實現(xiàn)了和KLT的一一對應。

看來同學對于底層的知識理解還湊合，那你有沒有看過HotSpot的源碼？能不能簡單說說看Java的線程是怎么運行的？

源碼以前看過，只能記得一個大概。

1、在Java中，使用java.lang.Thread的構造方法來構建一個java.lang.Thread對象，此時只是對這個對象的部分字段(例如線程名，優(yōu)先級等)進行初始化；

2、調(diào)用java.lang.Thread對象的start()方法，開始此線程。此時，在start()方法內(nèi)部，調(diào)用start0() 本地方法來開始此線程；

3、start0()在VM中對應的是JVM_StartThread，也就是，在VM中，實際運行的是JVM_StartThread方法(宏),在這個方法中，創(chuàng)建了一個JavaThread對象；

4、在JavaThread對象的創(chuàng)建過程中，會根據(jù)運行平臺創(chuàng)建一個對應的OSThread對象，且JavaThread保持這個OSThread對象的引用；

5、在OSThread對象的創(chuàng)建過程中，創(chuàng)建一個平臺相關的底層級線程，如果這個底層級線程失敗，那么就拋出異常；

6、在正常情況下，這個底層級的線程開始運行，并執(zhí)行java.lang.Thread對象的run方法；

7、當java.lang.Thread生成的Object的run()方法執(zhí)行完畢返回后，或者拋出異常終止后，終止native thread;

8、最后就是釋放相關的資源(包括內(nèi)存、鎖等)

大概就是以上這么個步驟吧。

那你說說什么是上下文切換吧。

多線程編程中一般線程的個數(shù)都大于 CPU 核心的個數(shù)，而一個 CPU 核心在任意時刻只能被一個線程使用，為了讓這些線程都能得到有效執(zhí)行，CPU 采取的策略是為每個線程分配時間片并輪轉的形式。

時間片是CPU分配給各個線程的時間，因為時間非常短，所以CPU不斷通過切換線程，讓我們覺得多個線程是同時執(zhí)行的，時間片一般是幾十毫秒。

當一個線程的時間片用完的時候就會重新處于就緒狀態(tài)讓給其他線程使用，這個過程就屬于一次上下文切換。

概括來說就是：當前任務在執(zhí)行完 CPU 時間片切換到另一個任務之前會先保存自己的狀態(tài)，以便下次再切換回這個任務時，可以再加載這個任務的狀態(tài)。任務從保存到再加載的過程就是一次上下文切換。

頻繁切換上下文會有什么問題？

上下文切換通常是計算密集型的，每次切換時，需要保存當前的狀態(tài)起來，以便能夠進行恢復先前狀態(tài)，而這個切換時非常損耗性能。

也就是說，它需要相當可觀的處理器時間，在每秒幾十上百次的切換中，每次切換都需要納秒量級的時間。所以，上下文切換對系統(tǒng)來說意味著消耗大量的 CPU 時間，事實上，可能是操作系統(tǒng)中時間消耗最大的操作。

Linux 相比與其他操作系統(tǒng)（包括其他類 Unix 系統(tǒng)）有很多的優(yōu)點，其中有一項就是，其上下文切換和模式切換的時間消耗非常少。

減少上下文切換的方式有哪些？

通常減少上下文切換的方式有：

1、無鎖并發(fā)編程：可以參照concurrentHashMap鎖分段的思想，不同的線程處理不同段的數(shù)據(jù)，這樣在多線程競爭的條件下，可以減少上下文切換的時間。

2、CAS算法：利用Atomic下使用CAS算法來更新數(shù)據(jù)，使用了樂觀鎖，可以有效的減少一部分不必要的鎖競爭帶來的上下文切換。

3、使用最少線程：避免創(chuàng)建不需要的線程，比如任務很少，但是創(chuàng)建了很多的線程，這樣會造成大量的線程都處于等待狀態(tài)。

4、協(xié)程：在單線程里實現(xiàn)多任務的調(diào)度，并在單線程里維持多個任務間的切換。

協(xié)程的英文單詞是Coroutine，這是一個程序組件，它既不是線程也不是進程。它的執(zhí)行過程更類似于一個方法，或者說不帶返回值的函數(shù)調(diào)用。

我看到過stack overflow和很多博客里，都認為這兩者是一個東西。但是，在我的理解中，這兩者還是有區(qū)別的。

不可否認的是，協(xié)程和ULT做的是同一個事情。所以從某種角度上講，他們確實是等價的！

但是，ULT這個概念被提出的時候，其背后的思想本質是講ULT是個本機線程，也就是使用了OS的用戶空間內(nèi)提供的庫類直接創(chuàng)建的線程。這個時候，你不需要在OS上面添加一些其他第三方的庫類。

而協(xié)程這個概念是康威定律的提出者Melvin Edward Conway在1958年提出的一個概念，其背后的思想是不直接使用OS本身的庫類，自己做一些庫類去實現(xiàn)并發(fā)。在那個年代，OS上面的第三方庫類并不像現(xiàn)在這么流行，OS本身的庫類和其他第三方庫類的結合也并不像今天這么容易。所以協(xié)程并不是本機線程，他是需要借助一些其他不屬于OS的第三方庫類調(diào)用OS用戶空間的庫類來實現(xiàn)達到ULT的效果。

當然，這個概念在今天來看，就會顯得很讓人混淆了。因為到底哪些庫類算是OS本機的庫類，哪些算是第三方庫類？這和1960年的時候已經(jīng)有絕大的區(qū)別了！所以大家認為這兩者是一個東西，其實也不能說他說的不對，只能說可能對這個思想本身背后代表的東西不明白。

那你知道fiber么？這個和上面兩個名詞有什么區(qū)別？

fiber也是一種本機線程，其本質是一種特殊的ULT，即更輕量級的ULT。說白了就是這種ULT的線程表一定存于進程之中。

而我們在構建一對一多線程模型的時候，ULT的線程表其實還是交給內(nèi)核了！這是兩者之間最直接的差別。所以我們經(jīng)常稱fiber就是協(xié)同調(diào)度的ULT，在win32中可以調(diào)用fiber來構建多對多的多線程模型。

其實，fiber、coroutine和ULT在用戶層面能看到的效果是基本等價的。

其中ULT是描述OS庫本身提供的功能；fiber描述的是OS提供的協(xié)同調(diào)度的ULT；coroutine描述的是第三方實現(xiàn)的并發(fā)并行功能。

這些名詞很多都是歷史原因的問題，同時也是深入研究需要了解的事情，我們普通程序員在使用的時候，更多的關心的是應用層方面的東西。而這些名詞的理解已經(jīng)深入到源碼層了。

還是講講看在 Java 程序中怎么保證多線程的運行安全吧。

Java的線程安全在三個方面體現(xiàn)：

原子性：提供互斥訪問，同一時刻只能有一個線程對數(shù)據(jù)進行操作，在Java中使用了atomic和synchronized這兩個關鍵字來確保原子性；

可見性：一個線程對主內(nèi)存的修改可以及時地被其他線程看到，在Java中使用了synchronized和volatile這兩個關鍵字確?？梢娦裕?/span>

有序性：一個線程觀察其他線程中的指令執(zhí)行順序，由于指令重排序，該觀察結果一般雜亂無序，在Java中使用了happens-before原則來確保有序性。

你剛才講了有序性，那你說說代碼為什么會重排序？

在執(zhí)行程序時，為了提高性能，處理器和編譯器常常會對指令進行重排序。

當然不是！不能隨意重排序，不是你想怎么排序就怎么排序，它需要滿足以下兩個條件：

1、在單線程環(huán)境下不能改變程序運行的結果；

2、存在數(shù)據(jù)依賴關系的不允許重排序。

所以重排序不會對單線程有影響，只會破壞多線程的執(zhí)行語義。

我們看這個例子，A和C之間存在數(shù)據(jù)依賴關系，同時B和C之間也存在數(shù)據(jù)依賴關系。因此在最終執(zhí)行的指令序列中，C不能被重排序到A和B的前面，如果C排到A和B的前面，那么程序的結果將會被改變。但A和B之間沒有數(shù)據(jù)依賴關系，編譯器和處理器可以重排序A和B之間的執(zhí)行順序。

這就是as-if-serial語義。

那你說說看你剛才講的happens-before原則吧。

happens-before說白了就是誰在誰前面發(fā)生的一個關系。

HB規(guī)則是Java內(nèi)存模型（JMM）向程序員提供的跨線程內(nèi)存可見性保證。

說的直白一點，就是如果A線程的寫操作a與B線程的讀操作b之間存在happens-before關系，盡管a操作和b操作在不同的線程中執(zhí)行，但JMM向程序員保證a操作將對b操作可見。

具體的定義為：

1、如果一個操作happens-before另一個操作，那么第一個操作的執(zhí)行結果將對第二個操作可見，而且第一個操作的執(zhí)行順序排在第二個操作之前。

2、兩個操作之間存在happens-before關系，并不意味著Java平臺的具體實現(xiàn)必須要按照happens-before關系指定的順序來執(zhí)行。如果重排序之后的執(zhí)行結果，與按happens-before關系來執(zhí)行的結果一致，那么這種重排序并不非法。

具體的規(guī)則有8條：

1、程序順序規(guī)則：一個線程中的每個操作，happens-before于該線程中的任意后續(xù)操作。

2、監(jiān)視器鎖規(guī)則：對一個鎖的解鎖，happens-before于隨后對這個鎖的加鎖。

3、volatile變量規(guī)則：對一個volatile域的寫，happens-before于任意后續(xù)對這個volatile域的讀。

4、傳遞性：如果A happens-before B，且B happens-before C，那么A happens-before C。

5、start()規(guī)則：如果線程A執(zhí)行操作ThreadB.start()（啟動線程B），那么A線程的ThreadB.start()操作happens-before于線程B中的任意操作。

6、Join()規(guī)則：如果線程A執(zhí)行操作ThreadB.join()并成功返回，那么線程B中的任意操作happens-before于線程A從ThreadB.join()操作成功返回。

7、程序中斷規(guī)則：對線程interrupted()方法的調(diào)用先行于被中斷線程的代碼檢測到中斷時間的發(fā)生。

8、對象finalize規(guī)則：一個對象的初始化完成（構造函數(shù)執(zhí)行結束）先行于發(fā)生它的finalize()方法的開始。