1.問題

1燃乍、什么是線程的交互方式唆樊？

2、如何區(qū)分線程的同步/異步刻蟹，阻塞/非阻塞逗旁？

3、什么是線程安全，如何做到線程安全片效？

4红伦、如何區(qū)分并發(fā)模型？

5淀衣、何謂響應(yīng)式編程昙读？

6、操作系統(tǒng)如何調(diào)度多線程膨桥？

2.關(guān)鍵詞

同步蛮浑，異步，阻塞只嚣，非阻塞沮稚，并行，并發(fā)册舞，臨界區(qū)蕴掏，競爭條件，指令重排调鲸，鎖盛杰，amdahl,gustafson

3.全文概要

上一篇我們介紹分布式系統(tǒng)的知識體系，由于單機的性能上限原因我們才不得不發(fā)展分布式技術(shù)藐石。那么話說回來即供，如果單機的性能沒能最大限度的榨取出來，就盲目的就建設(shè)分布式系統(tǒng)贯钩，那就有點本末倒置了募狂。而且上一篇我們給的忠告是如果有可能的話，不要用分布式角雷，意思是說如果單機性能滿足的話祸穷，就不要折騰復(fù)雜的分布式架構(gòu)。如果說分布式架構(gòu)是宏觀上的性能擴展勺三，那么高并發(fā)則是微觀上的性能調(diào)優(yōu)雷滚，這也是上一篇性能部分拆出來的大專題。本文將從線程的基礎(chǔ)理論談起，逐步探究線程的內(nèi)存模型，線程的交互乓搬，線程工具和并發(fā)模型的發(fā)展。掃除關(guān)于并發(fā)編程的諸多模糊概念车份，從新構(gòu)建并發(fā)編程的層次結(jié)構(gòu)。

4.基礎(chǔ)理論

4.1基本概念

開始學習并發(fā)編程前牡彻，我們需要熟悉一些理論概念扫沼。既然我們要研究的是并發(fā)編程，那首先應(yīng)該對并發(fā)這個概念有所理解才是，而說到并發(fā)我們肯定要要討論一些并行缎除。

并發(fā)：一個處理器同時處理多個任務(wù)

并行：多個處理器或者是多核的處理器同時處理多個不同的任務(wù)

然后我們需要再了解一下同步和異步的區(qū)別：

同步：執(zhí)行某個操作開始后就一直等著按部就班的直到操作結(jié)束

異步：執(zhí)行某個操作后立即離開严就，后面有響應(yīng)的話再來通知執(zhí)行者

接著我們再了解一個重要的概念：

臨界區(qū)：公共資源或者共享數(shù)據(jù)

由于共享數(shù)據(jù)的出現(xiàn)，必然會導(dǎo)致競爭器罐，所以我們需要再了解一下：

阻塞：某個操作需要的共享資源被占用了梢为，只能等待，稱為阻塞

非阻塞：某個操作需要的共享資源被占用了轰坊，不等待立即返回铸董，并攜帶錯誤信息回去，期待重試

如果兩個操作都在等待某個共享資源而且都互不退讓就會造成死鎖：

死鎖：參考著名的哲學家吃飯問題

饑餓：饑餓的哲學家等不齊筷子吃飯

活鎖：相互謙讓而導(dǎo)致阻塞無法進入下一步操作衰倦，跟死鎖相反袒炉，死鎖是相互競爭而導(dǎo)致的阻塞

4.2并發(fā)級別

理想情況下我們希望所有線程都一起并行飛起來。但是CPU數(shù)量有限樊零，線程源源不斷，總得有個先來后到孽文，不同場景需要的并發(fā)需求也不一樣驻襟，比如秒殺系統(tǒng)我們需要很高的并發(fā)程度，但是對于一些下載服務(wù)芋哭，我們需要的是更快的響應(yīng)沉衣，并發(fā)反而是其次的。所以我們也定義了并發(fā)的級別减牺，來應(yīng)對不同的需求場景豌习。

阻塞：阻塞是指一個線程進入臨界區(qū)后，其它線程就必須在臨界區(qū)外等待拔疚，待進去的線程執(zhí)行完任務(wù)離開臨界區(qū)后肥隆，其它線程才能再進去。

無饑餓：線程排隊先來后到稚失，不管優(yōu)先級大小栋艳，先來先執(zhí)行，就不會產(chǎn)生饑餓等待資源句各，也即公平鎖吸占；相反非公平鎖則是根據(jù)優(yōu)先級來執(zhí)行，有可能排在前面的低優(yōu)先級線程被后面的高優(yōu)先級線程插隊凿宾，就形成饑餓

無障礙：共享資源不加鎖矾屯，每個線程都可以自有讀寫，單監(jiān)測到被其他線程修改過則回滾操作初厚，重試直到單獨操作成功件蚕；風險就是如果多個線程發(fā)現(xiàn)彼此修改了，所有線程都需要回滾，就會導(dǎo)致死循環(huán)的回滾中骤坐，造成死鎖

無鎖：無鎖是無障礙的加強版绪杏，無鎖級別保證至少有一個線程在有限操作步驟內(nèi)成功退出，不管是否修改成功纽绍，這樣保證了多個線程回滾不至于導(dǎo)致死循環(huán)

無等待：無等待是無鎖的升級版蕾久，并發(fā)編程的最高境界，無鎖只保證有線程能成功退出拌夏，但存在低級別的線程一直處于饑餓狀態(tài)僧著，無等待則要求所有線程必須在有限步驟內(nèi)完成退出，讓低級別的線程有機會執(zhí)行障簿，從而保證所有線程都能運行盹愚，提高并發(fā)度。

4.3量化模型

首先站故，多線程不意味著并發(fā)皆怕，但并發(fā)肯定是多線程或者多進程。我們知道多線程存在的優(yōu)勢是能夠更好的利用資源西篓，有更快的請求響應(yīng)愈腾。但是我們也深知一旦進入多線程，附帶而來的是更高的編碼復(fù)雜度岂津，線程設(shè)計不當反而會帶來更高的切換成本和資源開銷虱黄。但是總體上我們肯定知道利大于弊，這不是廢話嗎吮成，不然誰還愿意去搞多線程并發(fā)程序橱乱，但是如何衡量多線程帶來的效率提升呢，我們需要借助兩個定律來衡量粱甫。

Amdahl

S=1/(1-a+a/n)

其中泳叠，a為并行計算部分所占比例，n為并行處理結(jié)點個數(shù)魔种。這樣析二，當1-a=0時，(即沒有串行节预，只有并行)最大加速比s=n叶摄；當a=0時（即只有串行，沒有并行）安拟，最小加速比s=1蛤吓；當n→∞時，極限加速比s→ 1/（1-a）糠赦，這也就是加速比的上限会傲。

Gustafson

系統(tǒng)優(yōu)化某部件所獲得的系統(tǒng)性能的改善程度锅棕，取決于該部件被使用的頻率，或所占總執(zhí)行時間的比例淌山。

兩面列舉了這兩個定律來衡量系統(tǒng)改善后提升效率的量化指標裸燎，具體的應(yīng)用我們在下文的線程調(diào)優(yōu)會再詳細介紹。

5.內(nèi)存模型

宏觀上分布式系統(tǒng)需要解決的首要問題是數(shù)據(jù)一致性泼疑，同樣德绿，微觀上并發(fā)編程要解決的首要問題也是數(shù)據(jù)一致性。貌似我們搞了這么多年的斗爭都是在公關(guān)一致性這個世界性難題退渗。既然并發(fā)編程要從微觀開始移稳，那么我們肯定要對CPU和內(nèi)存的工作機理有所了解，尤其是數(shù)據(jù)在CPU和內(nèi)存直接的傳輸機制会油。

5.1整體原則

探究內(nèi)存模型之前我們要拋出三個概念:

原子性

在32位的系統(tǒng)中个粱，對于4個字節(jié)32位的Integer的操作對應(yīng)的JVM指令集映射到匯編指令為一個原子操作，所以對Integer類型的數(shù)據(jù)操作是原子性翻翩，但是Long類型為8個字節(jié)64位都许，32位系統(tǒng)要分為兩條指令來操作，所以不是原子操作嫂冻。

對于32位操作系統(tǒng)來說梭稚，單次次操作能處理的最長長度為32bit，而long類型8字節(jié)64bit絮吵，所以對long的讀寫都要兩條指令才能完成（即每次讀寫64bit中的32bit）

可見性

線程修改變量對其他線程即時可見

有序性

串行指令順序唯一，并行線程直接指令可能出現(xiàn)不一致忱屑，也即是指令被重排了

而指令重排也是有一定原則(摘自《深入理解Java虛擬機第12章》)：

程序次序規(guī)則：一個線程內(nèi)蹬敲，按照代碼順序，書寫在前面的操作先行發(fā)生于書寫在后面的操作莺戒；

鎖定規(guī)則：一個unLock操作先行發(fā)生于后面對同一個鎖額lock操作伴嗡；

volatile變量規(guī)則：對一個變量的寫操作先行發(fā)生于后面對這個變量的讀操作；

傳遞規(guī)則：如果操作A先行發(fā)生于操作B从铲，而操作B又先行發(fā)生于操作C瘪校，則可以得出操作A先行發(fā)生于操作C；

線程啟動規(guī)則：Thread對象的start()方法先行發(fā)生于此線程的每個一個動作名段；

線程中斷規(guī)則：對線程interrupt()方法的調(diào)用先行發(fā)生于被中斷線程的代碼檢測到中斷事件的發(fā)生阱扬；

線程終結(jié)規(guī)則：線程中所有的操作都先行發(fā)生于線程的終止檢測，我們可以通過Thread.join()方法結(jié)束伸辟、Thread.isAlive()的返回值手段檢測到線程已經(jīng)終止執(zhí)行麻惶；

對象終結(jié)規(guī)則：一個對象的初始化完成先行發(fā)生于他的finalize()方法的開始；

5.2邏輯內(nèi)存

我們談的邏輯內(nèi)存也即是JVM的內(nèi)存格局信夫。JVM將操作系統(tǒng)提供的物理內(nèi)存和CPU緩存在邏輯分為堆窃蹋，棧卡啰，方法區(qū)，和程序計數(shù)器警没。在《從宏觀微觀角度淺析JVM虛擬機》 一文我們詳細介紹了JVM的內(nèi)存模型分布匈辱，并發(fā)編程我們主要關(guān)注的是堆棧的分配，因為線程都是寄生在棧里面的內(nèi)存段杀迹，把棧里面的方法邏輯讀取到CPU進行運算亡脸。

5.3物理內(nèi)存

而實際的物理內(nèi)存包含了主存和CPU的各級緩存還有寄存器，而為了計算效率佛南，CPU往往回就近從緩存里面讀取數(shù)據(jù)梗掰。在并發(fā)的情況下就會造成多個線程之間對共享數(shù)據(jù)的錯誤使用。

5.4內(nèi)存映射

由于可能發(fā)生對象的變量同時出現(xiàn)在主存和CPU緩存中嗅回，就可能導(dǎo)致了如下問題：

線程修改的變量對外可見

讀寫共享變量時出現(xiàn)競爭資源

由于線程內(nèi)的變量對棧外是不可見的及穗，但是成員變量等共享資源是競爭條件，所有線程可見绵载，就會出現(xiàn)如下當一個線程從主存拿了一個變量1修改后變成2存放在CPU緩存埂陆，還沒來得及同步回主存時，另外一個線程又直接從主存讀取變量為1娃豹，這樣就出現(xiàn)了臟讀焚虱。

現(xiàn)在我們弄清楚了線程同步過程數(shù)據(jù)不一致的原因，接下來要解決的目標就是如何避免這種情況的發(fā)生懂版，經(jīng)過大量的探索和實踐鹃栽，我們從概念上不斷的革新比如并發(fā)模型的流水線化和無狀態(tài)函數(shù)式化，而且也提供了大量的實用工具躯畴。接下來我們從無到有民鼓，先了解最簡單的單個線程的一些特點，弄清楚一個線程有多少能耐后蓬抄，才能深刻認識多個線程一起打交道會出現(xiàn)什么幺蛾子丰嘉。

6.線程單元

6.1狀態(tài)

我們知道應(yīng)用啟動體現(xiàn)的就是靜態(tài)指令加載進內(nèi)存，進而進入CPU運算嚷缭，操作系統(tǒng)在內(nèi)存開辟了一段棧內(nèi)存用來存放指令和變量值饮亏，從而形成了進程。而其實我們的JVM也就是一個進程而且阅爽，而線程是進程的最小單位路幸，也就是說進程是由很多個線程組成的。而由于進程的上下文關(guān)聯(lián)的變量优床，引用劝赔，計數(shù)器等現(xiàn)場數(shù)據(jù)占用了打段的內(nèi)存空間，所以頻繁切換進程需要整理一大段內(nèi)存空間來保存未執(zhí)行完的進程現(xiàn)場胆敞，等下次輪到CPU時間片再恢復(fù)現(xiàn)場進行運算着帽。這樣既耗費時間又浪費空間杂伟，所以我們才要研究多線程。畢竟由于線程干的活畢竟少仍翰，工作現(xiàn)場數(shù)據(jù)畢竟少赫粥，所以切換起來比較快而且暫用少量空間。而線程切換直接也需要遵守一定的法則予借，不然到時候把工作現(xiàn)場破壞了就無法恢復(fù)工作了越平。

線程狀態(tài)

我們先來研究線程的生命周期，看看Thread類里面對線程狀態(tài)的定義就知道

public enum State {? ? /**

? ? * Thread state for a thread which has not yet started.

? ? */

? ? NEW,? ? /**

? ? * Thread state for a runnable thread.? A thread in the runnable

? ? * state is executing in the Java virtual machine but it may

? ? * be waiting for other resources from the operating system

? ? * such as processor.

? ? */

? ? RUNNABLE,? ? /**

? ? * Thread state for a thread blocked waiting for a monitor lock.

? ? * A thread in the blocked state is waiting for a monitor lock

? ? * to enter a synchronized block/method or

? ? * reenter a synchronized block/method after calling

? ? * {@link Object#wait() Object.wait}.

? ? */

? ? BLOCKED,? ? /**

? ? * Thread state for a waiting thread.

? ? * A thread is in the waiting state due to calling one of the

? ? * following methods:

? ? * <ul>

? ? *? <li>{@link Object#wait() Object.wait} with no timeout</li>

? ? *? <li>{@link #join() Thread.join} with no timeout</li>

? ? *? <li>{@link LockSupport#park() LockSupport.park}</li>

? ? * </ul>

? ? *

? ? * <p>A thread in the waiting state is waiting for another thread to

? ? * perform a particular action.

? ? *

? ? * For example, a thread that has called <tt>Object.wait()</tt>

? ? * on an object is waiting for another thread to call

? ? * <tt>Object.notify()</tt> or <tt>Object.notifyAll()</tt> on

? ? * that object. A thread that has called <tt>Thread.join()</tt>

? ? * is waiting for a specified thread to terminate.

? ? */

? ? WAITING,? ? /**

? ? * Thread state for a waiting thread with a specified waiting time.

? ? * A thread is in the timed waiting state due to calling one of

? ? * the following methods with a specified positive waiting time:

? ? * <ul>

? ? *? <li>{@link #sleep Thread.sleep}</li>

? ? *? <li>{@link Object#wait(long) Object.wait} with timeout</li>

? ? *? <li>{@link #join(long) Thread.join} with timeout</li>

? ? *? <li>{@link LockSupport#parkNanos LockSupport.parkNanos}</li>

? ? *? <li>{@link LockSupport#parkUntil LockSupport.parkUntil}</li>

? ? * </ul>

? ? */

? ? TIMED_WAITING,? ? /**

? ? * Thread state for a terminated thread.

? ? * The thread has completed execution.

? ? */

? ? TERMINATED;

}

生命周期

線程的狀態(tài)：NEW灵迫，RUNNABLE秦叛，BLOCKED，WAITING瀑粥，TIMED_WAITING挣跋，TERMINATED。注釋也解釋得很清楚各個狀態(tài)的作用狞换，而各個狀態(tài)的轉(zhuǎn)換也有一定的規(guī)則需要遵循的避咆。

6.2動作

介紹完線程的狀態(tài)和生命周期，接下來我了解的線程具備哪些常用的操作修噪。首先線程也是一個普通的對象Thread查库，所有的線程都是Thread或者其子類的對象。那么這個內(nèi)存對象被創(chuàng)建出來后就會放在JVM的堆內(nèi)存空間黄琼，當我們執(zhí)行start()方法的時候樊销，對象的方法體在棧空間分配好對應(yīng)的棧幀來往執(zhí)行引擎輸送指令（也即是方法體翻譯成JVM的指令集）脏款。

線程操作

新建線程：new? Thread()现柠，新建一個線程對象，內(nèi)存為線程在棧上分配好內(nèi)存空間

啟動線程：start()弛矛，告訴系統(tǒng)系統(tǒng)準備就緒，只要資源允許隨時可以執(zhí)行我棧里面的指令了

執(zhí)行線程：run()比然，分配了CPU等計算資源丈氓，正在執(zhí)行棧里面的指令集

停止線程(過時)：stop()，把CPU和內(nèi)存資源回收强法，線程消亡万俗，由于太過粗暴，已經(jīng)被標記為過時

線程中斷：

interrupt()饮怯，中斷是對線程打上了中斷標簽闰歪，可供run()里面的方法體接收中斷信號，至于線程要不要中斷蓖墅，全靠業(yè)務(wù)邏輯設(shè)計库倘，而不是簡單粗暴的把線程直接停掉

isInterrupt()临扮，主要是run()方法體來判斷當前線程是否被置為中斷

interrupted()，靜態(tài)方法教翩，也是用戶判斷線程是否被置為中斷狀態(tài)杆勇，同時判斷完將線程中斷狀態(tài)復(fù)位

線程休眠：sleep()，靜態(tài)方法饱亿，線程休眠指定時間段蚜退，此間讓出CPU資源給其他線程，但是線程依然持有對象鎖彪笼，其他線程無法進入同步塊钻注，休眠完成后也未必立刻執(zhí)行，需要等到資源允許才能執(zhí)行

線程等待(對象方法)：wait()配猫，是Object的方法幅恋，也即是對象的內(nèi)置方法，在同步塊中線程執(zhí)行到該方法時章姓，也即讓出了該對象的鎖佳遣，所以無法繼續(xù)執(zhí)行

線程通知(對象方法)：notify(),notifyAll()，此時該對象持有一個或者多個線程的wait凡伊，調(diào)用notify()隨機的讓一個線程恢復(fù)對象的鎖零渐，調(diào)用notifyAll()則讓所有線程恢復(fù)對象鎖

線程掛起(過時)：suspend()，線程掛起并沒有釋放資源系忙，而是只能等到resume()才能繼續(xù)執(zhí)行

線程恢復(fù)(過時)：resume()诵盼，由于指令重排可能導(dǎo)致resume()先于suspend()執(zhí)行，導(dǎo)致線程永遠掛起银还，所以該方法被標為過時

線程加入：join()风宁，在一個線程調(diào)用另外一個線程的join()方法表明當前線程阻塞知道被調(diào)用線程執(zhí)行結(jié)束再進行，也即是被調(diào)用線程織入進來

線程讓步：yield()蛹疯，暫停當前線程進而執(zhí)行別的線程戒财，當前線程等待下一輪資源允許再進行，防止該線程一直霸占資源捺弦，而其他線程餓死

線程等待：park()饮寞，基于線程對象的操作，較對象鎖更為精準

線程恢復(fù)：unpark(Thread thread)列吼，對應(yīng)park()解鎖幽崩，為不可重入鎖

線程分組

為了管理線程，于是有了線程組的概念寞钥，業(yè)務(wù)上把類似的線程放在一個ThreadGroup里面統(tǒng)一管理慌申。線程組表示一組線程，此外理郑，線程組還可以包括其他線程組蹄溉。線程組形成一個樹咨油，其中除了初始線程組以外的每個線程組都有一個父線程。線程被允許訪問它自己的線程組信息类缤，但不能訪問線程組的父線程組或任何其他線程組的信息臼勉。

守護線程

通常情況下，線程運行到最后一條指令后則完成生命周期餐弱，結(jié)束線程宴霸，然后系統(tǒng)回收資源「囹荆或者單遇到異称靶唬或者return提前返回，但是如果我們想讓線程常駐內(nèi)存的話驮瞧，比如一些監(jiān)控類線程氓扛，需要24小時值班的，于是我們又創(chuàng)造了守護線程的概念论笔。

setDaemon()傳入true則會把線程一直保持在內(nèi)存里面采郎，除非JVM宕機否則不會退出。

線程優(yōu)先級

線程優(yōu)先級其實只是對線程打的一個標志狂魔，但并不意味這高優(yōu)先級的一定比低優(yōu)先級的先執(zhí)行蒜埋，具體還要看操作系統(tǒng)的資源調(diào)度情況。通常線程優(yōu)先級為5最楷，邊界為[1,10]整份。

/**

? * The minimum priority that a thread can have.

? */

public final static int MIN_PRIORITY = 1;/**

? * The default priority that is assigned to a thread.

? */

public final static int NORM_PRIORITY = 5; /**

? * The maximum priority that a thread can have.

? */

public final static int MAX_PRIORITY = 10;

本節(jié)介紹了線程單元的轉(zhuǎn)態(tài)切換和常用的一些操作方法。如果只是單線程的話籽孙，其他都沒必要研究這些烈评，重頭戲在于多線程直接的競爭配合操作，下一節(jié)則重點介紹多個線程的交互需要關(guān)注哪些問題犯建。

7.線程交互

其實上一節(jié)介紹的線程狀態(tài)切換和線程操作都是為線程交互做準備的讲冠。不然如果只是單線程完全沒必要搞什么通知，恢復(fù)适瓦，讓步之類的操作了沟启。

7.1交互方式

線程交互也就是線程直接的通信，最直接的辦法就是線程直接直接通信傳值犹菇，而間接方式則是通過共享變量來達到彼此的交互。

等待：釋放對象鎖芽卿，允許其他線程進入同步塊

通知：重新獲取對象鎖揭芍，繼續(xù)執(zhí)行

中斷：狀態(tài)交互，通知其他線程進入中斷

織入：合并線程卸例，多個線程合并為一個

7.2線程安全

我們最關(guān)注的還是通過共享變量來達到交互的方式称杨。線程如果都各自干活互不搭理的話自然相安無事肌毅，但多數(shù)情況下線程直接需要打交道，而且需要分享共享資源姑原，那么這個時候最核心的就是線程安全了悬而。

什么是線程安全？

當多個線程訪問同一個對象時锭汛，如果不用考慮這些線程在運行時環(huán)境下的調(diào)度和交替運行笨奠，也不需要進行額外的同步，或者在調(diào)用方進行任何其他的協(xié)調(diào)操作唤殴，調(diào)用這個對象的行為都可以獲取正確的結(jié)果般婆，那這個對象是線程安全的。（摘自《深入Java虛擬機》）

如何保證線程安全朵逝？

我們最早接觸線程安全可能是JDK提供的一些號稱線程安全的容器蔚袍，比如Vetor較ArrayList是線程安全，HashTable較HashMap是線程安全配名？其實線程安全類并不代表也不等同線程安全的程序啤咽，而線程不安全的類同樣可以完成線程安全的程序。我們關(guān)注的也就是寫出線程安全的程序渠脉，那么如何寫出線程安全的代碼呢宇整？下面列舉了線程安全的主要設(shè)計技術(shù)：

無狀態(tài)

這個有點函數(shù)式編程的味道，下文并發(fā)模式會介紹到连舍，總之就是線程只有入?yún)⒑途植孔兞棵欢福绻兞渴且玫脑挘_保變量的創(chuàng)建和調(diào)用生命周期都發(fā)生在線程棧內(nèi)索赏，就可以確保線程安全盼玄。

無共享狀態(tài)

完全要求線程無狀態(tài)比較難實現(xiàn)，必要的狀態(tài)是無法避免的潜腻，那么我們就必須維護不同線程之間的不同狀態(tài)，這可是個麻煩事融涣。幸好我們有ThreadLocal這個神器威鹿，該對象跟當前線程綁定剃斧，而且只對當前線程可見忽你，完美解決了無共享狀態(tài)的問題。

不可變狀態(tài)

最后實在沒辦法避免狀態(tài)共享，在線程之間共享狀態(tài)根蟹，最怕的就是無法確保能維護好正確的讀寫順序，而且多線程確實也無法正確維護好這個共享變量球散。那么我們索性粗暴點蕉堰，把共享的狀態(tài)定位不可變嘁灯，比如價格final修飾一下丑婿，這樣就達到安全狀態(tài)共享羹奉。

消息傳遞

一個線程通常也不是所有步驟都需要共享狀態(tài)诀拭，而是部分環(huán)節(jié)才需要的耕挨，那么我們把共享狀態(tài)的代碼拆開筒占，無共享狀態(tài)的那部分自然不用關(guān)心翰苫，而共享狀態(tài)的小段代碼这橙，則通過加入消息組件來傳遞狀態(tài)屈扎。這個設(shè)計到并發(fā)模式的流水線編程模式鹰晨，下文并發(fā)模式會重點介紹。

線程安全容器

JUC里面提供大量的并發(fā)容器，涉及到線程交互的時候棚潦，使用安全容器可以避免大部分的錯誤，而且大大降低了代碼的復(fù)雜度中剩。

通過synchronized給方法加上內(nèi)置鎖來實現(xiàn)線程安全的類如Vector，HashTable,StringBuffer

AtomicXXX如AtomicInteger

ConcurrentXXX如ConcurrentHashMap

BlockingQueue/BlockingDeque

CopyOnWriteArrayList/CopyOnWriteArraySet

ThreadPoolExecutor

synchronized同步

該關(guān)鍵字確保代碼塊同一時間只被一個線程執(zhí)行骄呼，在這個前提下再設(shè)計符合線程安全的邏輯

其作用域為

對象：對象加鎖，進入同步代碼塊之前獲取對象鎖

實例方法：對象加鎖澄峰，執(zhí)行實例方法前獲取對象實例鎖

類方法：類加鎖绸硕，執(zhí)行類方法前獲取類鎖

volatile約束

volatile確保每次操作都能強制同步CPU緩存和主存直接的變量玻佩。而且在編譯期間能阻止指令重排夺蛇。讀寫并發(fā)情況下volatile也不能確保線程安全刁赦，上文解析內(nèi)存模型的時候有提到過甚脉。

這節(jié)我們論述了編寫線程安全程序的指導(dǎo)思想牺氨，其中我們提到了JDK提供的JUC工具包猴凹，下一節(jié)將重點介紹并發(fā)編程常用的趁手工具郊霎。

8.線程工具

前文我們介紹了內(nèi)存理論和線程的一些特征书劝，大家都知道并發(fā)編程容易出錯购对，而且出了錯還不好調(diào)試排查骡苞，幸好JDK里面集成了大量實用的API工具烙如，我們能熟悉這些工具亚铁，寫起并發(fā)程序來也事半功倍徘溢。

工具篇其實就是對鎖的不斷變種站粟，適應(yīng)更多的開發(fā)場景奴烙，提高性能切诀，提供更方便的工具幅虑，從最粗暴的同步修飾符倒庵，到靈活的可重入鎖擎宝，到寬松的條件绍申，接著到允許多個線程訪問的信號量失晴，最后到讀寫分離鎖。

8.1同步控制

由于大多數(shù)的并發(fā)場景都是需要訪問到共享資源的拆又，為了保證線程安全帖族，我們不得已采用鎖的技術(shù)來做同步控制竖般，這節(jié)我們介紹的是適用不同場景各種鎖技術(shù)涣雕。

ReentrantLock

可重入互斥鎖具有與使用synchronized的隱式監(jiān)視器鎖具有相同的行為和語義挣郭，但具有更好擴展功能。

ReentrantLock由最后成功鎖定的線程擁有流译，而且還未解鎖先蒋。當鎖未被其他線程占有時竞漾，線程調(diào)用lock()將返回并且成功獲取鎖业岁。如果當前線程已擁有鎖棍好，則該方法將立即返回借笙。這可以使用方法isHeldByCurrentThread()和getHoldCount()來檢查业稼。

構(gòu)造函數(shù)接受可選的fairness參數(shù)低散。當設(shè)置為true時熔号，在競爭條件下，鎖定有利于賦予等待時間最長線程的訪問權(quán)限祠乃。否則亮瓷，鎖將不保證特定的訪問順序嘱支。在多線程訪問的情況，使用公平鎖比默認設(shè)置汛聚，有著更低的吞吐量倚舀，但是獲得鎖的時間比較小而且可以避免等待鎖導(dǎo)致的饑餓痕貌。但是超升，鎖的公平性并不能保證線程調(diào)度的公平性室琢。因此研乒，使用公平鎖的許多線程中的一個可以連續(xù)多次獲得它，而其他活動線程沒有進展并且當前沒有持有鎖。不定時的tryLock（）方法不遵循公平性設(shè)置继谚。即使其他線程正在等待花履，如果鎖可用，它也會成功妹卿。

任意指定鎖的起始位置

中斷響應(yīng)

鎖申請等待限時tryLock()

公平鎖

Condition

Condition從擁有監(jiān)控方法（wait,notify,notifyAll）的Object對象中抽離出來成為獨特的對象夺克，高效的讓每個對象擁有更多的等待線程。和鎖對比起來狡门，如果說用Lock代替synchronized融撞，那么Condition就是用來代替Object本身的監(jiān)控方法饶火。

Condition實例跟Object本身的監(jiān)控相似肤寝，同樣提供wait()方法讓調(diào)用的線程暫時掛起讓出資源鲤看，知道其他線程通知該對象轉(zhuǎn)態(tài)變化，才可能繼續(xù)執(zhí)行慷吊。Condition實例來源于Lock實例溉瓶，通過Lock調(diào)用newCondition()即可。Condition較Object原生監(jiān)控方法触创，可以保證通知順序嗅榕。

Semaphore

鎖和同步塊同時只能允許單個線程訪問共享資源，這個明顯有些單調(diào)帽蝶，部分場景其實可以允許多個線程訪問佃乘，這個時候信號量實例就派上用場了趣避。信號量邏輯上維持了一組許可證程帕， 線程調(diào)用acquire()阻塞直到許可證可用后才能執(zhí)行。 執(zhí)行release()意味著釋放許可證岭埠，實際上信號量并沒有真正的許可證，只是采用了計數(shù)功能來實現(xiàn)這個功能馆类。

ReadWriteLock

顧名思義讀寫鎖將讀寫分離技羔，細化了鎖的粒度藤滥，照顧到性能的優(yōu)化向图。

CountDownLatch

這個鎖有點“關(guān)門放狗”的意思榄攀，尤其在我們壓測的時候模擬實時并行請求，該實例將線程積累到指定數(shù)量后贞瞒，調(diào)用countDown()方法讓所有線程同時執(zhí)行军浆。

CyclicBarrier

CyclicBarrier是加強版的CountDownLatch掰盘，上面講的是一次性“關(guān)門放狗”，而循環(huán)柵欄則是集齊了指定數(shù)量的線程晃财，在資源都允許的情況下同時執(zhí)行，然后下一批同樣的操作钢猛，周而復(fù)始。

LockSupport

LockSupport是用來創(chuàng)建鎖和其他同步類的基本線程阻塞原語壶愤。 LockSupport中的park() 和 unpark() 的作用分別是阻塞線程和解除阻塞線程，而且park()和unpark()不會遇到“Thread.suspend 和 Thread.resume所可能引發(fā)的死鎖”問題勃救。因為park() 和 unpark()有許可的存在；調(diào)用 park() 的線程和另一個試圖將其 unpark() 的線程之間的競爭將保持活性税肪。

8.2線程池

線程池總覽

線程多起來的話就需要管理锻梳，不然就會亂成一鍋。我們知道線程在物理上對應(yīng)的就是棧里面的一段內(nèi)存荆永，存放著局部變量的空間和待執(zhí)行指令集。如果每次執(zhí)行都要從頭初始化這段內(nèi)存液兽，然后再交給CPU執(zhí)行骂删，效率就有點低了。假如我們知道該段棧內(nèi)存會被經(jīng)常用到四啰，那我們就不要回收宁玫，創(chuàng)建完就讓它在棧里面呆著，要用的時候取出來柑晒，用完換回去，是不是就省了初始化線程空間的時間匙赞，這樣是我們搞出線程池的初衷佛掖。

其實線程池很簡單，就是搞了個池子放了一堆線程涌庭。既然我們搞線程池是為了提高效率芥被，那就要考慮線程池放多少個線程比較合適，太多了或者太少了有什么問題脾猛，怎么拒絕多余的請求撕彤，除了異常怎么處理鱼鸠。首先我們來看跟線程池有關(guān)的一張類圖猛拴。

線程池歸結(jié)起來就是這幾個類的使用技巧了，重點關(guān)注ThreadPoolExecutor和Executors即可蚀狰。

創(chuàng)建線程池

萬變不離其宗愉昆，創(chuàng)建線程池的各種馬甲方法最后都是調(diào)用到這方法里面，包含核心線程數(shù)麻蹋，最大線程數(shù)跛溉，線程工廠，拒絕策略等參數(shù)。其中線程工廠則可以實現(xiàn)自定義創(chuàng)建線程的邏輯芳室。

public interface ThreadFactory {? ? Thread newThread(Runnable r);

}

創(chuàng)建的核心構(gòu)造方法ThreadPoolExecutor.java? 1301

/**

? ? * Creates a new {@code ThreadPoolExecutor} with the given initial

? ? * parameters.

? ? *

? ? * @param corePoolSize the number of threads to keep in the pool, even

? ? *? ? ? ? if they are idle, unless {@code allowCoreThreadTimeOut} is set

? ? * @param maximumPoolSize the maximum number of threads to allow in the

? ? *? ? ? ? pool

? ? * @param keepAliveTime when the number of threads is greater than

? ? *? ? ? ? the core, this is the maximum time that excess idle threads

? ? *? ? ? ? will wait for new tasks before terminating.

? ? * @param unit the time unit for the {@code keepAliveTime} argument

? ? * @param workQueue the queue to use for holding tasks before they are

? ? *? ? ? ? executed.? This queue will hold only the {@code Runnable}

? ? *? ? ? ? tasks submitted by the {@code execute} method.

? ? * @param threadFactory the factory to use when the executor

? ? *? ? ? ? creates a new thread

? ? * @param handler the handler to use when execution is blocked

? ? *? ? ? ? because the thread bounds and queue capacities are reached

? ? * @throws IllegalArgumentException if one of the following holds:<br>

? ? *? ? ? ? {@code corePoolSize < 0}<br>

? ? *? ? ? ? {@code keepAliveTime < 0}<br>

? ? *? ? ? ? {@code maximumPoolSize <= 0}<br>

? ? *? ? ? ? {@code maximumPoolSize < corePoolSize}

? ? * @throws NullPointerException if {@code workQueue}

? ? *? ? ? ? or {@code threadFactory} or {@code handler} is null

? ? */

? ? public ThreadPoolExecutor(int corePoolSize,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? int maximumPoolSize,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? long keepAliveTime,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TimeUnit unit,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BlockingQueue<Runnable> workQueue,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ThreadFactory threadFactory,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? RejectedExecutionHandler handler)

拒絕策略包含：

? ? /** 實際上并未真正丟棄任務(wù)专肪，但是線程池性能會下降

? ? * A handler for rejected tasks that runs the rejected task

? ? * directly in the calling thread of the {@code execute} method,

? ? * unless the executor has been shut down, in which case the task

? ? * is discarded.

? ? */

? ? public static class CallerRunsPolicy implements RejectedExecutionHandler

? ? /** 粗暴停止拋異常

? ? * A handler for rejected tasks that throws a

? ? * {@code RejectedExecutionException}.

? ? */? ? public static class AbortPolicy implements RejectedExecutionHandler

? ? /** 悄無聲息的丟棄拒絕的任務(wù)

? ? * A handler for rejected tasks that silently discards the

? ? * rejected task.

? ? */? ? public static class DiscardPolicy implements RejectedExecutionHandler

? ? /** 丟棄最老的請求

? ? * A handler for rejected tasks that discards the oldest unhandled

? ? * request and then retries {@code execute}, unless the executor

? ? * is shut down, in which case the task is discarded.

? ? */? ? public static class DiscardOldestPolicy implements RejectedExecutionHandler

包括Executors.java中的創(chuàng)建線程池的方法，具體實現(xiàn)也是通過ThreadPoolExecutor來創(chuàng)建的堪侯。

public static ExecutorService newCachedThreadPool() {

? ? return new ThreadPoolExecutor(0, Integer.MAX_VALUE,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 60L, TimeUnit.SECONDS,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new SynchronousQueue<Runnable>());

}

public static ExecutorService newFixedThreadPool(int nThreads) {

? ? return new ThreadPoolExecutor(nThreads, nThreads,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0L, TimeUnit.MILLISECONDS,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new LinkedBlockingQueue<Runnable>());

}

public static ScheduledExecutorService newScheduledThreadPool(int corePoolSize) {

? ? return new ScheduledThreadPoolExecutor(corePoolSize);

}

public static ExecutorService newSingleThreadExecutor() {

? ? return new FinalizableDelegatedExecutorService

? ? ? ? ? ? (new ThreadPoolExecutor(1, 1,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0L, TimeUnit.MILLISECONDS,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? new LinkedBlockingQueue<Runnable>()));

}

調(diào)用線程池

ThreadPoolExecutor.java 1342

/** 同步執(zhí)行線程嚎尤，出現(xiàn)異常打印堆棧信息

* Executes the given task sometime in the future.? The task

* may execute in a new thread or in an existing pooled thread.

*

* If the task cannot be submitted for execution, either because this

* executor has been shutdown or because its capacity has been reached,

* the task is handled by the current {@code RejectedExecutionHandler}.

*

* @param command the task to execute

* @throws RejectedExecutionException at discretion of

*? ? ? ? {@code RejectedExecutionHandler}, if the task

*? ? ? ? cannot be accepted for execution

* @throws NullPointerException if {@code command} is null

*/public void execute(Runnable command)/**

* 異步提交線程任務(wù)，出現(xiàn)異常無法同步追蹤堆棧,本質(zhì)上也是調(diào)用execute()方法

*/public <T> Future<T> submit(Runnable task, T result) {? ? if (task == null) throw new NullPointerException();

? ? RunnableFuture<T> ftask = newTaskFor(task, result);

? ? execute(ftask);? ? return ftask;

}

線程池優(yōu)化

線程池已經(jīng)是我們使用線程的一個優(yōu)化成果了伍宦，而線程池本身的優(yōu)化其實就是根據(jù)實際業(yè)務(wù)選擇好不同類型的線程池芽死，預(yù)估并發(fā)線程數(shù)量，控制好線程池預(yù)留線程數(shù)（最大線程數(shù)一般設(shè)為2N+1最好次洼，N是CPU核數(shù)）关贵，這些涉及CPU數(shù)量，核數(shù)還有具體業(yè)務(wù)卖毁。

另外我們還注意到ForkJoinPool繼承了AbstractExecutorService揖曾，這是在JDK7才加上去的，目的就是提高任務(wù)派生出來更多任務(wù)的執(zhí)行效率势篡，由上圖的繼承關(guān)系我們可以知道跟普通線程池最大的差異是執(zhí)行的任務(wù)類型不同翩肌。

public void execute(ForkJoinTask<?> task) {? ? if (task == null)? ? ? ? throw new NullPointerException();

? ? externalPush(task);

}public void execute(Runnable task) {? ? ? ? if (task == null)? ? ? ? ? ? throw new NullPointerException();

? ? ? ? ForkJoinTask<?> job;? ? ? ? if (task instanceof ForkJoinTask<?>) // avoid re-wrap

? ? ? ? ? ? job = (ForkJoinTask<?>) task;? ? ? ? else

? ? ? ? ? ? job = new ForkJoinTask.RunnableExecuteAction(task);

? ? ? ? externalPush(job);

}

8.3并發(fā)容器

其實我們?nèi)粘ｉ_發(fā)大多數(shù)并發(fā)場景直接用JDK 提供的線程安全數(shù)據(jù)結(jié)構(gòu)足矣，下面列舉了常用的列表禁悠，集合等容器念祭，具體就不展開講，相信大家都用得很熟悉了碍侦。

ConcurrentHashMap

CopyOnWriteArrayList

ConcurrentLinkedQueue

BlockingQueue

ConcurrentSkipListMap

Vector

HashTable

…

9.線程調(diào)優(yōu)

9.1性能指標

回想一下粱坤，當我們在談性能優(yōu)化的時候，我們可能指的是數(shù)據(jù)庫的讀寫次數(shù)瓷产，也可能指網(wǎng)站的響應(yīng)時間站玄。通常我們會用QPS，TPS濒旦，RT株旷，并發(fā)數(shù)，吞吐量尔邓，更進一步的還會對比CPU負載來衡量一個系統(tǒng)的性能晾剖。

當然我們知道一個系統(tǒng)的吞吐量和響應(yīng)時間跟外部網(wǎng)絡(luò)，分布式架構(gòu)等都存在強關(guān)聯(lián)梯嗽，性能優(yōu)化也跟各級緩存設(shè)計齿尽，數(shù)據(jù)冗余等架構(gòu)有很大關(guān)系，假設(shè)其他方面我們都已經(jīng)完成了灯节，聚焦到本文我們暫時關(guān)心的是單節(jié)點的性能優(yōu)化循头。畢竟一屋不掃何以掃天下绵估，整體系統(tǒng)的優(yōu)化也有賴于各個節(jié)點的調(diào)優(yōu)。從感官上來談卡骂，當請求量很少的時候国裳，我們可以很輕松的通過各種緩存優(yōu)化來提高響應(yīng)時間。但是隨著用戶激增全跨，請求次數(shù)的增加躏救，我們的服務(wù)也對應(yīng)著需要并發(fā)模型來支撐。但是一個節(jié)點的并發(fā)量有個上限螟蒸，當達到這個上限后盒使，響應(yīng)時間就會變長，所以我們需要探索并發(fā)到什么程度才是最優(yōu)的七嫌，才能保證最高的并發(fā)數(shù)少办，同時響應(yīng)時間又能保持在理想情況。由于我們暫時不關(guān)注節(jié)點以外的網(wǎng)絡(luò)情況诵原，那么下文我們特指的RT是指服務(wù)接收到請求后英妓，完成計算，返回計算結(jié)果經(jīng)歷的時間绍赛。

單線程

單線程情況下蔓纠，服務(wù)接收到請求后開始初始化，資源準備吗蚌，計算腿倚，返回結(jié)果，時間主要花在CPU計算和CPU外的IO等待時間蚯妇，多個請求來也只能排隊一個一個來敷燎，那么RT計算如下

RT = T(cpu) + T(io)

QPS = 1000ms / RT

多線程

單線程情況很好計算，多線程情況就復(fù)雜了箩言，我們目標是計算出最佳并發(fā)量硬贯，也就是線程數(shù)N

單核情況：N = [T(cpu) + T(io)] / T(cpu)

M核情況：N = [T(cpu) + T(io)] / T(cpu) * M

由于多核情況CPU未必能全部使用，存在一個資源利用百分比P

那么并發(fā)的最佳線程數(shù) N = [T(cpu) + T(io)] / T(cpu) M P

吞吐量

我們知道單線程的QPS很容易算出來陨收，那么多線程的QPS

QPS = 1000ms / RT N = 1000ms / T(cpu) + T(io) [T(cpu) + T(io)] / T(cpu) M P= 1000ms / T(cpu) M P

在機器核數(shù)固定情況下饭豹，也即是并發(fā)模式下最大的吞吐量跟服務(wù)的CPU處理時間和CPU利用率有關(guān)。CPU利用率不高务漩，就是通常我們聽到最多的抱怨拄衰，壓測時候qps都打滿了，但是cpu的load就是上不去菲饼。并發(fā)模型中多半個共享資源有關(guān)肾砂，而共享資源又跟鎖息息相關(guān)列赎，那么大部分時候我們想對節(jié)點服務(wù)做性能調(diào)優(yōu)時就是對鎖的優(yōu)化宏悦，這個下一節(jié)會提到镐确。

前面我們是假設(shè)機器核數(shù)固定的情況下做優(yōu)化的，那假如我們把緩存饼煞，IO源葫，鎖都優(yōu)化了，剩下的還有啥空間去突破呢砖瞧？回想一下我們談基礎(chǔ)理論的時候提到的Amdahl定律息堂，公式之前已經(jīng)給出，該定律想表達的結(jié)論是隨著核數(shù)或者處理器個數(shù)的增加块促，可以增加優(yōu)化加速比荣堰，但是會達到上限，而且增加趨勢愈發(fā)不明顯竭翠。

9.2鎖優(yōu)化

說真的振坚，我們并不喜歡鎖的，只不過由于臨界資源的存在不得已為之斋扰。如果業(yè)務(wù)上設(shè)計能避免出現(xiàn)臨界資源渡八，那就沒有鎖優(yōu)化什么事了。但是传货，鎖優(yōu)化的一些原則還是要說一說的屎鳍。

時間

既然我們并不喜歡鎖，那么就按需索取问裕，只在核心的同步塊加鎖逮壁，用完立馬釋放，減少鎖定臨界區(qū)的時間粮宛，這樣就可以把資源競爭的風險降到最低貌踏。

粒度

進一步看，有時候我們核心同步塊可以進一步分離窟勃，比如只讀的情況下并不需要加鎖祖乳，這時候就可以用讀寫鎖各自的讀寫功能。

還有一種情況秉氧，有時候我們反而會小心翼翼的到處加鎖來防止意外出現(xiàn)眷昆，可能出現(xiàn)三個同步塊加了三個鎖，這也造成CPU的過多停頓汁咏，根據(jù)業(yè)務(wù)其實可以把相關(guān)邏輯合并起來亚斋，也就是鎖粗化。

鎖的分離和粗化具體還得看業(yè)務(wù)如何操作攘滩。

尺度

除了鎖暫用時間和粒度外帅刊，還有就是鎖的尺度，還是根據(jù)業(yè)務(wù)來漂问，能用共享鎖定的情況就不要用獨享鎖赖瞒。

死鎖

這個不用說都知道女揭，死鎖防不勝防，我們前面也介紹很多現(xiàn)成的工具栏饮，比如可重入鎖吧兔，還有線程本地變量等方式，都可以一定程度避免死鎖袍嬉。

9.3JVM鎖機制

我們在代碼層面把鎖的應(yīng)用都按照安全法則做到最好了境蔼，那接下來要做的就是下鉆到JVM級別的鎖優(yōu)化。具體實現(xiàn)原理我們暫不展開伺通，后續(xù)有機會再搞個專題寫寫JVM鎖實現(xiàn)箍土。

自旋鎖(Spin Lock)

自旋鎖的原理非常簡單。如果持有鎖的線程可以在短時間內(nèi)釋放鎖資源罐监，那么等待競爭鎖的那些線程不需要在內(nèi)核狀態(tài)和用戶狀態(tài)之間進行切換涮帘。 它只需要等待，并且鎖可以在釋放鎖之后立即獲得鎖笑诅。這可以避免消耗用戶線程和內(nèi)核切換调缨。

但是，自旋鎖讓CPU空等著什么也不干也是一種浪費吆你。 如果自旋鎖的對象一直無法獲得臨界資源弦叶，則線程也無法在沒有執(zhí)行實際計算的情況下一致進行CPU空轉(zhuǎn)，因此需要設(shè)置自旋鎖的最大等待時間妇多。如果持有鎖的線程在旋轉(zhuǎn)等待的最大時間沒有釋放鎖伤哺，則自旋鎖線程將停止旋轉(zhuǎn)進入阻塞狀態(tài)。

JDK1.6開啟自旋鎖? -XX:+UseSpinning者祖，1.7之后控制器收回到JVM自主控制

偏向鎖(Biased Lock)

偏向鎖偏向于第一個訪問鎖的線程立莉，如果在運行過程中，同步鎖只有一個線程訪問七问，不存在多線程爭用的情況蜓耻，則線程是不需要觸發(fā)同步的，這種情況下械巡，就會給線程加一個偏向鎖刹淌。如果在運行過程中，遇到了其他線程搶占鎖讥耗，則持有偏向鎖的線程會被掛起有勾，JVM會消除它身上的偏向鎖，將鎖恢復(fù)到標準的輕量級鎖古程。

JDK1.6開啟自旋鎖? -XX:+UseBiasedLocking蔼卡，1.7之后控制器收回到JVM自主控制

輕量級鎖(Lightweight Lock)

輕量級鎖是由偏向鎖升級來的，偏向鎖運行在一個線程進入同步塊的情況下挣磨，當?shù)诙€線程加入鎖競爭的時候雇逞，偏向鎖就會升級為輕量級鎖荤懂。

重量級鎖(Heavyweight Lock)

如果鎖檢測到與另一個線程的爭用，則鎖定會膨脹至重量級鎖喝峦。也就是我們常規(guī)用的同步修飾產(chǎn)生的同步作用。

9.4無鎖

最后其實我想說的是呜达，雖然鎖很符合我們?nèi)祟惖倪壿嬎季S谣蠢，設(shè)計起來也相對簡單，但是擺脫不了臨界區(qū)的限制查近。那么我們不妨換個思路眉踱，進入無鎖的時間，也就是我們可能會增加業(yè)務(wù)復(fù)雜度的情況下霜威，來消除鎖的存在谈喳。

CAS策略

著名的CAS(Compare And Swap)，是多線程中用于實現(xiàn)同步的原子指令戈泼。 它將內(nèi)存位置的內(nèi)容與給定值進行比較婿禽，并且只有它們相同時，才將該內(nèi)存位置的內(nèi)容修改為新的給定值大猛。 這是作為單個原子操作完成的扭倾。 原子性保證了新值是根據(jù)最新信息計算出來的; 如果在此期間該值已被另一個線程更新，則寫入將失敗挽绩。 操作的結(jié)果必須表明它是否進行了替換; 這可以通過簡單的Boolean來響應(yīng)膛壹，或通過返回從內(nèi)存位置讀取的值（而不是寫入它的值）來完成。

也就是一個原子操作包含了要操作的數(shù)據(jù)和給定認為正確的值進行對比唉堪，一致的話就繼續(xù)模聋，不一致則會重試。這樣就在沒有鎖的情況下完成并發(fā)操作唠亚。

我們知道原子類 AtomicInteger內(nèi)部實現(xiàn)的原理就是采用了CAS策略來完成的链方。

AtomicInteger.java? 132

/**

* Atomically sets the value to the given updated value

* if the current value {@code ==} the expected value.

*

* @param expect the expected value

* @param update the new value

* @return {@code true} if successful. False return indicates that

* the actual value was not equal to the expected value.

*/public final boolean compareAndSet(int expect, int update) {? ? return unsafe.compareAndSwapInt(this, valueOffset, expect, update);

}

類似的還有AtomicReference.java? 115

/**

* Atomically sets the value to the given updated value

* if the current value {@code ==} the expected value.

* @param expect the expected value

* @param update the new value

* @return {@code true} if successful. False return indicates that

* the actual value was not equal to the expected value.

*/public final boolean compareAndSet(V expect, V update) {? ? return unsafe.compareAndSwapObject(this, valueOffset, expect, update);

}

有興趣的同學可以再了解一下Unsafe的實現(xiàn)，進一步可以了解Distuptor無鎖框架灶搜。

10.并發(fā)模型

前面我們大費周章的從并發(fā)的基礎(chǔ)概念到多線程的使用方法和優(yōu)化技巧侄柔。但都是戰(zhàn)術(shù)層面的，本節(jié)我們試著從戰(zhàn)略的高度來擴展一下并發(fā)編程的世界占调≡萏猓可能大多數(shù)情況下我們談并發(fā)都會想到多線程，但是本節(jié)我們要打破這種思維究珊，在完全不用搞多線程那一套的情況下實現(xiàn)并發(fā)薪者。

首先我們用”多線程模式“來回顧前文所講的所有關(guān)于Thread衍生出來的定義，開發(fā)和優(yōu)化的技術(shù)剿涮。

多線程模式

單位線程完成完整的任務(wù)言津，也即是一條龍服務(wù)線程攻人。

優(yōu)勢：

映射現(xiàn)實單一任務(wù)，便于理解和編碼

劣勢：

有狀態(tài)多線程共享資源悬槽，導(dǎo)致資源競爭怀吻，死鎖問題，線程等待阻塞初婆，失去并發(fā)意義

有狀態(tài)多線程非阻塞算法蓬坡，有利減少競爭，提升性能磅叛，但難以實現(xiàn)

多線程執(zhí)行順序無法預(yù)知

流水線模型

介紹完傳統(tǒng)多線程工作模式后屑咳，我們來學習另外一種并發(fā)模式，傳統(tǒng)的多線程工作模式弊琴，理解起來很直觀兆龙，接下來我們要介紹的另外一種并發(fā)模式看起來就不那么直觀了。

流水線模型敲董，特點是無狀態(tài)線程紫皇，無狀態(tài)也意味著無需競爭共享資源，無需等待腋寨，也就是非阻塞模型坝橡。流水線模型顧名思義就是流水線上有多個環(huán)節(jié)，每個環(huán)節(jié)完成自己的工作后就交給下一個環(huán)節(jié)精置，無需等待上游计寇，周而復(fù)始的完成自己崗位上的一畝三分地就行。各個環(huán)節(jié)之間交付無需等待脂倦，完成即可交付番宁。

而工廠的流水線也不止一條，所以有多條流水線同時工作赖阻。

不同崗位的生產(chǎn)效率是不一樣的蝶押，所以不同流水線之間也可以發(fā)生協(xié)同。

我們說流水線模型也稱為響應(yīng)式模型或者事件驅(qū)動模型火欧，其實就是流水線上上游崗位完成生產(chǎn)就通知下游崗位棋电，所以完成了一個事件的通知，每完成一次就通知一下苇侵，就是響應(yīng)式的意思赶盔。

流水線模型總體的思想就是縱向切分任務(wù)，把任務(wù)里面耗時過久的環(huán)節(jié)單獨隔離出來榆浓，避免完成一個任務(wù)需要耗費等待的時間于未。在實現(xiàn)上又分為Actors和Channels模型

Actors

該模型跟我們講述的流水線模型基本一致，可以理解為響應(yīng)式模型

Channels

由于各個環(huán)節(jié)直接不直接交互，所以上下游之間并不知道對方是誰烘浦，好比不同環(huán)節(jié)直接用的是幾條公共的傳送帶來接收物品抖坪，各自只需要把完成后的半成品扔到傳送帶，即使后面流水線優(yōu)化了闷叉，去掉中間的環(huán)節(jié)擦俐，對于個體崗位來說也是無感知的，它只是周而復(fù)始的從傳送帶拿物品來加工握侧。

流水線的優(yōu)缺點：

優(yōu)勢：

無共享狀態(tài)：無需考慮資源搶占蚯瞧，死鎖等問題

獨享內(nèi)存：worker可以持有內(nèi)存，合并多次操作到內(nèi)存后再持久化藕咏，提升效率

貼合底層：單線程模式貼合硬件運行流程状知，便于代碼維護

任務(wù)順序可預(yù)知

劣勢：

不夠直觀：一個任務(wù)被拆分為流水線上多個環(huán)節(jié)秽五，代碼層面難以直觀理解業(yè)務(wù)邏輯

由于流水線模式跟人類的順序執(zhí)行思維不一樣孽查，比較費解宙地，那么有沒有辦法讓我們編碼的時候像寫傳統(tǒng)的多線程代碼一樣逗鸣，而運行起來又是流水線模式呢？答案是肯定的棍鳖，比如基于Java的Akka/Reator/Vert.x/Play/Qbit框架瓣铣，或者golang就是為流水線模式而生的并發(fā)語言答朋，還有nodeJS等等。

流水線模型的開發(fā)實踐可以參考流水線模型實踐棠笑。

其實流水線模型背后用的也還是多線程來實現(xiàn)梦碗，只不過對于傳統(tǒng)多線程模式下我們需要小心翼翼來處理跟蹤資源共享問題，而流水線模式把以前一個線程做的事情拆成多個蓖救，每一個環(huán)節(jié)再用一條線程來完成洪规，避免共享，線程直接通過管道傳輸消息循捺。

這一塊展開也是一個專題斩例，主要設(shè)計NIO，Netty和Akka的編程實踐从橘，先占坑后面補上念赶。

函數(shù)式模型

函數(shù)式并行模型類似流水線模型，單一的函數(shù)是無狀態(tài)的恰力，所以避免了資源競爭的復(fù)雜度叉谜，同時每個函數(shù)類似流水線里面的單一環(huán)境，彼此直接通過函數(shù)調(diào)用傳遞參數(shù)副本踩萎，函數(shù)之外的數(shù)據(jù)不會被修改正罢。函數(shù)式模式跟流水線模式相輔相成逐漸成為更為主流的并發(fā)架構(gòu)。具體的思想和編程實踐也是個大專題，篇幅限制本文就先不展開翻具，擬在下個專題中詳細介紹《函數(shù)式編程演化》履怯。

11.總結(jié)

由于CPU和I/O天然存在的矛盾，傳統(tǒng)順序的同步工作模式導(dǎo)致任務(wù)阻塞裆泳，CPU空等著沒有執(zhí)行叹洲，浪費資源。多線程為突破了同步工作模式的情況下浪費CPU資源工禾，即使單核情況下也能將時間片拆分成單位給更多的線程來輪詢享用运提。多線程在不同享狀態(tài)的情況下非常高效，不管協(xié)同式還是搶占式都能在單位時間內(nèi)執(zhí)行更多的任務(wù)闻葵，從而更好的榨取CPU資源民泵。

但是多數(shù)情況下線程之間是需要通信的，這一核心場景導(dǎo)致了一系列的問題槽畔，也就是線程安全栈妆。內(nèi)存被共享的單位由于被不同線程輪番讀取寫入操作，這種操作帶來的后果往往是寫代碼的人類沒想到的厢钧，也就是并發(fā)帶來的臟數(shù)據(jù)等問題鳞尔。解決了資源使用效率問題，又帶來了新的安全問題早直，如何解決寥假？悲觀方式就是對于存在共享內(nèi)存的場景，無論如何只同意同一時刻一個線程操作霞扬，也就是同步操作方法或者代碼段或者顯示加鎖糕韧。或者volatile來使共享的主存跟每條線程的工作內(nèi)存同步（每次讀都從主存刷新喻圃，每次寫完都刷到主存）

要保證線程安全：

1萤彩、不要使用多線程，

2级及、多線程各干各的不要共享內(nèi)存乒疏，

3、共享的內(nèi)存空間是不可變的（常量饮焦，final）怕吴，

4、實在要變每次變完要同步到主存volatile（依賴當前值的邏輯除外）县踢，

5转绷、原子變量，

6硼啤、根據(jù)具體業(yè)務(wù)议经，避免臟數(shù)據(jù)（這塊就是多線程最容易犯錯的地方）

線程安全后，要考慮的就是效率問題，如果不解決效率問題煞肾，那還干嘛要多線程咧织。。籍救。

如果所有線程都很自覺习绢，快速執(zhí)行完就跑路，那就是我們的理想情況了蝙昙。但是闪萄，部分線程又臭又長（I/O阻塞），不能讓一直賴在CPU不走奇颠，就把他上下文（線程號败去，變量，執(zhí)行到哪等數(shù)值的快照）保存到內(nèi)存烈拒，然后讓它滾蛋下一個線程來圆裕。但是切換太快的話也不合適，畢竟每次保存線程的作案現(xiàn)場也要花不少時間的缺菌，單位時間執(zhí)行線程數(shù)要控制在一個適當?shù)膫€數(shù)葫辐。創(chuàng)建線程也是一項很吃力的工作搜锰，一個線程就是在棧內(nèi)存里面開辟一段內(nèi)存空間伴郁，根據(jù)字節(jié)碼分配臨時變量空間，不同操作系統(tǒng)通常不一樣蛋叼。不能頻繁的創(chuàng)建銷毀線程焊傅。那就搞個線程池出來，用的時候拿出來狈涮，用完扔回去狐胎，簡單省事。但是線程池的創(chuàng)建也有門道歌馍，不能無限創(chuàng)建不然就失去意義了握巢。操作系統(tǒng)有一定上限，線程池太多線程內(nèi)存爆了松却，系統(tǒng)奔潰暴浦，所以需要一個機制。容納1024個線程晓锻，多了排隊再多了扔掉歌焦。回到線程切換砚哆，由于創(chuàng)建線程耗費資源独撇，切換也花費，有時候切換線程的時間甚至比讓線程待在cpu無所事事更長，那就給加個自旋鎖纷铣，就是讓它自己再cpu打滾啥事不干卵史，一會兒輪到它里面就能干活。

既然多線程同步又得加鎖耗資源搜立，不同步又有共享安全問題程腹。那能不能把這些鎖，共享儒拂，同步寸潦，要注意的問題封裝起來。搞出一個異步的工作機制社痛，不用管底層的同步問題见转，只管業(yè)務(wù)問題。傳統(tǒng)是工匠干活一根筋干完蒜哀，事件驅(qū)動是流水線斩箫，把一件事拆分成多個環(huán)節(jié)，每個環(huán)節(jié)有唯一標識撵儿，各個環(huán)節(jié)批量生產(chǎn)乘客，在流水線對接。這樣在CPU單獨干淀歇，不共享易核，不阻塞，干完自己的通知管工浪默，高效封裝了內(nèi)部線程的運行規(guī)則牡直，把業(yè)務(wù)關(guān)系暴露給管理者。

本文主要將的數(shù)基于JAVA的傳統(tǒng)多線程并發(fā)模型纳决，下面例牌給出知識體系圖碰逸。