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

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

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

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

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

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

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

看來同學(xué)對(duì)于底層的知識(shí)理解還湊合，那你有沒有看過HotSpot的源碼？能不能簡單說說看Java的線程是怎么運(yùn)行的？

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

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

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

3、start0()在VM中對(duì)應(yīng)的是JVM_StartThread，也就是，在VM中，實(shí)際運(yùn)行的是JVM_StartThread方法(宏),在這個(gè)方法中，創(chuàng)建了一個(gè)JavaThread對(duì)象；

4、在JavaThread對(duì)象的創(chuàng)建過程中，會(huì)根據(jù)運(yùn)行平臺(tái)創(chuàng)建一個(gè)對(duì)應(yīng)的OSThread對(duì)象，且JavaThread保持這個(gè)OSThread對(duì)象的引用；

5、在OSThread對(duì)象的創(chuàng)建過程中，創(chuàng)建一個(gè)平臺(tái)相關(guān)的底層級(jí)線程，如果這個(gè)底層級(jí)線程失敗，那么就拋出異常；

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

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

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

大概就是以上這么個(gè)步驟吧。

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

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

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

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

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

頻繁切換上下文會(huì)有什么問題？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當(dāng)然，這個(gè)概念在今天來看，就會(huì)顯得很讓人混淆了。因?yàn)榈降啄男祛愃闶荗S本機(jī)的庫類，哪些算是第三方庫類？這和1960年的時(shí)候已經(jīng)有絕大的區(qū)別了！所以大家認(rèn)為這兩者是一個(gè)東西，其實(shí)也不能說他說的不對(duì)，只能說可能對(duì)這個(gè)思想本身背后代表的東西不明白。

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

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

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

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

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

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

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

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

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

可見性：一個(gè)線程對(duì)主內(nèi)存的修改可以及時(shí)地被其他線程看到，在Java中使用了synchronized和volatile這兩個(gè)關(guān)鍵字確保可見性；

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

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

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

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

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

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

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

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

這就是as-if-serial語義。

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

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

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

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

具體的定義為：

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

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

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

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

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

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

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

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

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

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

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