1. 線程基礎(chǔ)先搞清楚線程到底是什么線程這塊內(nèi)容可以說是Java面試里出場率最高的知識點沒有之一。不管是校招還是社招只要是后端方向幾乎必問線程相關(guān)的概念。我這些年面試別人也被別人面試發(fā)現(xiàn)線程八股問來問去核心就那么幾個方向線程的創(chuàng)建方式、生命周期、狀態(tài)流轉(zhuǎn)、線程池、鎖機制、并發(fā)工具類。把這些吃透了基本就能應(yīng)對絕大部分面試場景。先聊線程的本質(zhì)。線程是操作系統(tǒng)能夠進行運算調(diào)度的最小單位它被包含在進程之中是進程中的實際運作單位。一條線程指的是進程中一個單一順序的控制流一個進程中可以并發(fā)多個線程每條線程并行執(zhí)行不同的任務(wù)。打個比方進程就像一家餐廳線程就像餐廳里的服務(wù)員一個餐廳可以有多個服務(wù)員同時服務(wù)不同的顧客。Java天生支持多線程編程這也是Java能成為企業(yè)級開發(fā)主流語言的重要原因之一。很多初學(xué)者對線程和進程的關(guān)系搞不清楚這里我多說一句。進程是資源分配的基本單位線程是CPU調(diào)度的基本單位。進程之間相互獨立各有獨立的地址空間同一個進程內(nèi)的線程共享進程的地址空間和資源。所以多線程編程最大的優(yōu)勢就是可以共享數(shù)據(jù)、節(jié)省資源但同時也帶來了并發(fā)安全問題這也是后面所有鎖機制存在的根本原因。從面試角度來說線程基礎(chǔ)這塊經(jīng)常被問到的一個問題是Java里創(chuàng)建線程有哪幾種方式這個問題看起來簡單但其實有很多細節(jié)可以深挖。我遇到過很多候選人能說出繼承Thread類和實現(xiàn)Runnable接口但對Callable和FutureTask、以及線程池創(chuàng)建這幾種方式理解不夠深入。下面具體展開說。1.1 線程創(chuàng)建方式的演進與對比Java創(chuàng)建線程的方式從最初的繼承Thread類到實現(xiàn)Runnable接口再到JDK 5引入的Callable和FutureTask以及最終的線程池經(jīng)歷了一個逐步演進的過程。這個演進過程本質(zhì)上是在解決如何更好地管理和復(fù)用線程這個問題。繼承Thread類是最傳統(tǒng)的方式直接new一個Thread的子類重寫run方法。這種方式代碼簡單但缺點很明顯Java是單繼承的一旦繼承了Thread類就不能再繼承其他類了擴展性差。而且這種方式把任務(wù)和線程耦合在一起不符合任務(wù)與執(zhí)行分離的設(shè)計思想。實現(xiàn)Runnable接口是更推薦的方式它把任務(wù)邏輯和線程本身解耦了。Runnable接口只有一個run方法里面寫的是任務(wù)要執(zhí)行的內(nèi)容。使用時還是需要創(chuàng)建Thread對象把Runnable實現(xiàn)類傳進去調(diào)用start方法。這種方式的好處是任務(wù)類還可以繼承其他類也更符合面向接口編程的思想。到了JDK 5引入了Callable接口和Runnable相比最大的區(qū)別是Callable的call方法有返回值而且可以拋出異常。但Callable不能直接傳給Thread使用需要配合FutureTask來包裝一下。FutureTask實現(xiàn)了Runnable接口所以可以傳給Thread同時又實現(xiàn)了Future接口可以獲取異步計算結(jié)果。線程池是JDK 5同時推出的也是目前生產(chǎn)環(huán)境用的最多的方式。核心思想是復(fù)用線程避免頻繁創(chuàng)建和銷毀線程帶來的性能開銷。阿里開發(fā)手冊明確禁止使用Executors工具類創(chuàng)建線程池而是要求通過ThreadPoolExecutor的方式手動創(chuàng)建這樣可以更明確地控制線程池的運行規(guī)則避免資源耗盡的風(fēng)險。我個人的經(jīng)驗是面試中回答創(chuàng)建方式時不要只是干巴巴地羅列幾種方式可以主動說一下各自的適用場景和優(yōu)缺點對比這會讓面試官覺得你是有真實項目經(jīng)驗的而不是背八股。1.2 線程生命周期與狀態(tài)流轉(zhuǎn)線程的生命周期是所有線程知識的基石理解不透徹后面學(xué)什么都不順暢。Java線程在運行過程中有六種狀態(tài)定義在Thread.State這個枚舉類里。NEW狀態(tài)是線程被創(chuàng)建但還沒調(diào)用start方法時的狀態(tài)。RUNNABLE是調(diào)用了start方法之后的狀態(tài)這里要注意Java的RUNNABLE狀態(tài)其實包含了操作系統(tǒng)層面的運行中和就緒兩種狀態(tài)也就是線程可能正在CPU上執(zhí)行也可能在等待CPU時間片。BLOCKED是線程在等待獲取監(jiān)視器鎖也就是synchronized的鎖時的狀態(tài)比如一個線程進入了synchronized代碼塊另一個線程也想進入就會進入BLOCKED狀態(tài)。WAITING是線程正在等待另一個線程執(zhí)行特定動作時的狀態(tài)比如調(diào)用了Object.wait()、Thread.join()、LockSupport.park()都會進入這個狀態(tài)。TIMED_WAITING是帶超時時間的等待狀態(tài)比如Thread.sleep、Object.wait(long timeout)、Thread.join(long millis)等。TERMINATED是線程執(zhí)行完run方法后的最終狀態(tài)。狀態(tài)流轉(zhuǎn)是面試的重點尤其容易被問到sleep和wait有什么區(qū)別這里一定要說清楚。sleep是Thread類的靜態(tài)方法調(diào)用后線程進入TIMED_WAITING狀態(tài)但不會釋放任何鎖資源wait是Object類的方法調(diào)用后線程進入WAITING狀態(tài)并且會釋放持有的鎖。這也是為什么wait方法必須在synchronized代碼塊中調(diào)用因為它需要先持有鎖然后釋放鎖讓其他線程有機會獲取鎖。sleep則沒有這個限制任何地方都能調(diào)用。還有一個高頻考點是線程的start方法和run方法有什么區(qū)別很多新手會犯直接調(diào)用run方法的錯誤。start方法會啟動一個新線程由新線程去執(zhí)行run方法里的邏輯直接調(diào)用run方法就只是在當(dāng)前線程執(zhí)行一個普通的方法調(diào)用根本沒有創(chuàng)建新線程。判斷一個線程是否啟動過可以看thread.getState()是否不等于NEW。關(guān)于狀態(tài)流轉(zhuǎn)我建議畫一張狀態(tài)轉(zhuǎn)換圖幫助記憶。我自己當(dāng)年學(xué)的時候把六種狀態(tài)的觸發(fā)條件和轉(zhuǎn)換關(guān)系整理成了一張表格貼在電腦旁邊天天看很快就記住了。后面排查線上問題的時候用jstack工具查看線程棧信息看到線程停在什么狀態(tài)、等在哪把鎖上這都是一眼就能看出來的基本功。2. 線程安全的核心機制synchronized與volatile線程安全問題本質(zhì)上是因為多線程同時訪問共享數(shù)據(jù)時發(fā)生了競爭。Java解決線程安全的手段很多但synchronized和volatile是最基礎(chǔ)、最核心的兩個關(guān)鍵詞。面試中幾乎必問這兩個關(guān)鍵字的原理和區(qū)別所以這塊一定要深入理解。先理解什么是臨界區(qū)和競態(tài)條件。臨界區(qū)是訪問共享資源的代碼段同一時刻只允許一個線程進入。競態(tài)條件是指多個線程同時讀寫共享數(shù)據(jù)時最終結(jié)果取決于線程執(zhí)行的相對時序可能導(dǎo)致數(shù)據(jù)不一致。解決競態(tài)條件的思路就是讓臨界區(qū)的代碼原子執(zhí)行即不可分割要么全部執(zhí)行完要么不執(zhí)行。synchronized關(guān)鍵字就是Java提供的解決并發(fā)安全的經(jīng)典機制。它有三種用法修飾實例方法、修飾靜態(tài)方法、修飾代碼塊。修飾實例方法時鎖的是當(dāng)前實例對象修飾靜態(tài)方法時鎖的是類的Class對象修飾代碼塊時鎖的是括號里指定的對象。這里有一個細節(jié)很多人會搞混synchronized修飾靜態(tài)方法和修飾實例方法它們鎖的對象是不同的所以兩者之間并不會互斥。2.1 synchronized的底層實現(xiàn)與鎖升級synchronized在JDK 6之前是一把重量級鎖性能表現(xiàn)不佳因為它的底層依賴于操作系統(tǒng)的互斥量mutex線程阻塞和喚醒都需要從用戶態(tài)切換到內(nèi)核態(tài)這個切換代價很大。所以在早期很多高并發(fā)場景下會刻意避免使用synchronized轉(zhuǎn)而使用JDK 5推出的Lock接口。但JDK 6引入了鎖升級機制之后synchronized的性能得到了大幅提升很多場景下性能已經(jīng)和ReentrantLock相差無幾。鎖升級的方向是無鎖 - 偏向鎖 - 輕量級鎖 - 重量級鎖。這個升級方向是單向的不會降級。偏向鎖是鎖升級的第一級。它的設(shè)計思想是大多數(shù)情況下鎖不僅不存在多線程競爭而且總是由同一個線程多次獲得。所以當(dāng)一個線程第一次訪問同步代碼塊時會在對象頭中記錄持有鎖的線程ID后續(xù)這個線程再次進入時就不需要再做任何同步操作了。如果有其他線程來競爭這把鎖偏向鎖就會撤銷升級為輕量級鎖。輕量級鎖的獲取方式是CAS自旋。多個線程在無競爭的情況下交替執(zhí)行同步代碼塊時通過CAS操作嘗試把對象頭中的鎖標(biāo)記替換為自己的線程記錄。如果替換成功就獲得了鎖如果失敗說明有競爭就會自旋等待。自旋是占用CPU的所以如果競爭激烈、自旋次數(shù)過多就會升級為重量級鎖。JDK 6之后自旋是自適應(yīng)的JVM會根據(jù)上次自旋的結(jié)果動態(tài)調(diào)整自旋次數(shù)。重量級鎖就是傳統(tǒng)的互斥鎖依賴操作系統(tǒng)的mutex實現(xiàn)。當(dāng)競爭非常激烈時沒有獲取到鎖的線程會進入阻塞狀態(tài)由用戶態(tài)切換到內(nèi)核態(tài)這個切換涉及上下文切換開銷很大。理解了鎖升級機制之后再回頭分析synchronized的適用場景就清楚了鎖競爭不激烈的情況下用synchronized完全沒問題但是一旦高并發(fā)下競爭激烈synchronized會膨脹為重量級鎖性能急劇下降這時候就要考慮ReentrantLock或者讀寫鎖了。2.2 volatile的可見性與有序性volatile是Java提供的最輕量級的同步機制它有兩個核心作用保證可見性和有序性但不能保證原子性。可見性是指當(dāng)一個線程修改了volatile變量的值該值會立即被刷新到主內(nèi)存中其他線程讀取該變量時會從主內(nèi)存中重新讀取最新的值而不是使用自己工作內(nèi)存中的副本。這解決的是多線程之間的數(shù)據(jù)透明問題。有序性是指volatile會禁止指令重排序。編譯器和CPU為了優(yōu)化執(zhí)行效率可能會對代碼指令進行重排這在單線程環(huán)境下沒有問題但在多線程環(huán)境下可能導(dǎo)致意想不到的結(jié)果。volatile通過在讀寫操作前后插入內(nèi)存屏障阻止指令重排到屏障的另一側(cè)從而保證了程序執(zhí)行的順序符合編寫時的預(yù)期。但是volatile不保證原子性這也是面試中最容易考到的一個點。經(jīng)典的場景是i操作雖然i被聲明為volatile但i實際上是讀-改-寫三步操作不是一個原子操作。多個線程同時執(zhí)行i時還是可能出現(xiàn)數(shù)據(jù)覆蓋的問題。所以volatile適合修飾那些多個線程都會讀取、但只有少數(shù)線程會寫入、且寫入不依賴當(dāng)前值的場景典型的就是作為狀態(tài)標(biāo)志位。在并發(fā)編程中還有一個著名的happens-before原則需要了解。這個原則定義了多線程操作之間的內(nèi)存可見性規(guī)則是JMMJava內(nèi)存模型的核心內(nèi)容。happens-before規(guī)則包括程序順序規(guī)則、鎖規(guī)則、volatile變量規(guī)則、傳遞性規(guī)則等。其中volatile變量規(guī)則說的是對一個volatile變量的寫操作happens-before于后續(xù)對該變量的讀操作。理解這些規(guī)則能幫你判斷到底能不能用volatile解決當(dāng)前的問題。我面試時喜歡問一個問題synchronized和volatile有什么區(qū)別這個問題考察的是對并發(fā)基礎(chǔ)的理解深度。標(biāo)準(zhǔn)的回答應(yīng)該圍繞三方面一是volatile本質(zhì)是告訴JVM這個變量是共享且不穩(wěn)定的每次都要從主內(nèi)存中讀取synchronized則是讓多個線程互斥訪問臨界區(qū)。二是volatile只能修飾變量不能修飾方法synchronized可以修飾方法和代碼塊。三是volatile不保證原子性synchronized保證原子性volatile不會阻塞線程synchronized會讓未獲取鎖的線程阻塞。3. 線程通信wait/notify與LockSupport多線程之間除了互斥訪問共享資源還經(jīng)常需要互相協(xié)作配合。比如生產(chǎn)者-消費者模式中消費者要等生產(chǎn)者生產(chǎn)出數(shù)據(jù)之后才能消費這時候就需要線程通信機制。Java中線程通信最經(jīng)典的方式是wait/notify機制使用Object類的wait、notify、notifyAll方法。這三個方法都必須在synchronized代碼塊或者synchronized方法中調(diào)用因為它們操作的對象的監(jiān)視器鎖。調(diào)用wait方法后當(dāng)前線程會釋放持有的鎖并進入WAITING狀態(tài)直到其他線程調(diào)用同一個對象上的notify或notifyAll方法將它喚醒。這里有個非常重要的細節(jié)notify方法是隨機喚醒一個正在等待該對象鎖的線程notifyAll是喚醒所有等待的線程。如果需要精確喚醒某個特定的線程那就要用后面引入的Lock和Condition機制了。JDK 5之后引入了Lock接口和Condition接口Condition提供了await、signal、signalAll方法功能類似wait、notify、notifyAll但更加靈活。一個Lock可以創(chuàng)建多個Condition每個Condition維護一個獨立的等待隊列這樣就能實現(xiàn)精確喚醒某個或某類線程而不是像synchronized那樣只能使用一個隱式條件隊列。舉個例子在實現(xiàn)一個有界阻塞隊列時如果用synchronized實現(xiàn)只有一個等待隊列生產(chǎn)者生產(chǎn)滿時等待消費者消費空時等待notify時無法區(qū)分喚醒的是生產(chǎn)者還是消費者。而有了Condition之后可以創(chuàng)建兩個ConditionnotEmpty和notFull消費者等待notEmpty條件生產(chǎn)者等待notFull條件這樣就能精準(zhǔn)喚醒對應(yīng)類型的線程效率更高且邏輯更清晰。LockSupport是更底層的線程阻塞工具類基于Unsafe類的park和unpark方法實現(xiàn)。它的核心優(yōu)勢是不需要持有鎖就能使用且unpark可以先于park調(diào)用也就是許可機制使得線程可以先被叫醒再等待。AQS框架中大量使用了LockSupport來管理線程的阻塞與喚醒。我在實際項目中用Condition的場景還是蠻多的比如實現(xiàn)限流器、實現(xiàn)任務(wù)隊列的消費者調(diào)度。這套機制比單純用synchronized加wait/notify要優(yōu)雅得多代碼可讀性也更好。線程通信的常見面試題還包括wait方法為什么要放在while循環(huán)中答案是為了防止虛假喚醒。有些情況下線程被喚醒時等待的條件并不一定已經(jīng)滿足可能是被其他原因喚醒的所以被喚醒后要再次檢查條件是否滿足不滿足就繼續(xù)等待。這也是《Effective Java》里面明確的建議總是使用while循環(huán)來包圍wait方法調(diào)用。3.1 生產(chǎn)者消費者模型的兩種實現(xiàn)生產(chǎn)者-消費者模型是線程通信最經(jīng)典的應(yīng)用場景面試中經(jīng)常要求手寫實現(xiàn)。我用synchronized和Lock兩種方式各自實現(xiàn)了一遍這里分享下核心代碼和思路差異。用synchronized實現(xiàn)的核心邏輯是定義一個緩沖區(qū)列表和一個最大容量生產(chǎn)者和消費者都在synchronized代碼塊內(nèi)操作。緩沖區(qū)滿了就調(diào)用wait等待緩沖區(qū)空了也調(diào)用wait等待。每次生產(chǎn)或消費完一個數(shù)據(jù)后都調(diào)用notifyAll喚醒其他線程。class Buffer { private final ListInteger list new ArrayList(); private final int capacity 10; public synchronized void put(int value) throws InterruptedException { while (list.size() capacity) { wait(); } list.add(value); notifyAll(); } public synchronized int take() throws InterruptedException { while (list.isEmpty()) { wait(); } int value list.remove(0); notifyAll(); return value; } }用Lock和Condition實現(xiàn)的方式類似但可以區(qū)分生產(chǎn)者和消費者的喚醒。代碼結(jié)構(gòu)上synchronized是隱式獲取和釋放鎖Lock則要求手動加鎖和釋放鎖必須在finally中釋放鎖避免死鎖。class Buffer { private final ReentrantLock lock new ReentrantLock(); private final Condition notFull lock.newCondition(); private final Condition notEmpty lock.newCondition(); private final ListInteger list new ArrayList(); private final int capacity 10; public void put(int value) throws InterruptedException { lock.lock(); try { while (list.size() capacity) { notFull.await(); } list.add(value); notEmpty.signal(); } finally { lock.unlock(); } } public int take() throws InterruptedException { lock.lock(); try { while (list.isEmpty()) { notEmpty.await(); } int value list.remove(0); notFull.signal(); return value; } finally { lock.unlock(); } } }這兩種實現(xiàn)的性能差異在并發(fā)量不大的時候幾乎感覺不到但Lock版本的可擴展性明顯更好。面試時如果能同時寫出兩種實現(xiàn)并且分析出各自的特點這是一個加分項。4. 鎖的進階ReentrantLock、讀寫鎖與AQS前面反復(fù)提到Lock接口和AQS這一節(jié)重點展開講。JDK 5引入的java.util.concurrent并發(fā)包是Java并發(fā)編程的里程碑而AQSAbstractQueuedSynchronizer是這個并發(fā)包的靈魂。ReentrantLock是最常用的Lock實現(xiàn)類它和synchronized相比有以下幾個核心優(yōu)勢。一是支持公平鎖和非公平鎖兩種模式synchronized只能是非公平的。公平鎖按照線程請求鎖的順序來獲取鎖保證先來先得但吞吐量會低一些非公平鎖允許線程插隊吞吐量高但可能出現(xiàn)線程饑餓。二是支持可中斷獲取鎖調(diào)用lockInterruptibly方法后等待鎖的過程中可以被其他線程中斷而synchronized等待鎖時是不能響應(yīng)中斷的。三是支持超時獲取鎖調(diào)用tryLock(long timeout, TimeUnit unit)方法在指定時間內(nèi)獲取不到鎖就會返回false可以避免無限期等待。四是支持多個條件變量通過newCondition可以創(chuàng)建多個Condition實例。這里說一個面試高頻題ReentrantLock和synchronized的區(qū)別是什么除了上面說的四點還要補充底層的區(qū)別synchronized是JVM層面實現(xiàn)的基于監(jiān)視器鎖ReentrantLock是JDK層面實現(xiàn)的基于AQSsynchronized在JDK 6之后有鎖升級機制ReentrantLock從誕生起就使用CAS加自旋的方式實現(xiàn)。4.1 AQS的實現(xiàn)原理AQS是Java并發(fā)包的核心抽象它維護了一個volatile int類型的state變量和一個FIFO的等待隊列。state的含義由具體的子類去定義比如在ReentrantLock中state表示獲取鎖的次數(shù)在Semaphore中state表示剩余許可證的數(shù)量在CountDownLatch中state表示還需要等待的計數(shù)個數(shù)。AQS的基本思想是當(dāng)線程請求資源時通過CAS嘗試將state從期望值更新為新值如果成功就表示獲取資源成功如果失敗則將該線程封裝成Node節(jié)點插入到等待隊列的尾部然后通過LockSupport.park阻塞自己。當(dāng)前驅(qū)節(jié)點的線程釋放資源時會喚醒隊列中下一個節(jié)點對應(yīng)的線程。這里有幾個細節(jié)值得注意等待隊列中的Node節(jié)點每個節(jié)點都保存著線程引用和等待狀態(tài)。AQS在釋放資源時會從隊列頭部開始找第一個狀態(tài)有效的節(jié)點來喚醒。這個喚醒過程也是需要循環(huán)判斷的因為節(jié)點的等待狀態(tài)可能會有變化。ReentrantLock的加鎖過程本質(zhì)上就是通過CAS把state從0改成1。如果當(dāng)前線程已經(jīng)持有鎖了再次獲取鎖時state會繼續(xù)累加這就是可重入的含義。釋放鎖時state遞減直到state變?yōu)?鎖才真正被釋放。公平鎖和非公平鎖的區(qū)別在于非公平鎖在加鎖時會先嘗試一次CAS搶鎖搶不到再進入等待隊列公平鎖則直接進入等待隊列排隊。4.2 讀寫鎖與StampedLockReadWriteLock讀寫鎖是一種特殊類型的鎖它維護了一對鎖一個讀鎖和一個寫鎖。讀鎖之間可以共享多個線程可以同時持有讀鎖寫鎖是排他的一個線程持有寫鎖時其他線程既不能讀也不能寫。這種設(shè)計非常適用于讀多寫少的場景比如緩存系統(tǒng)、配置加載等。ReentrantReadWriteLock是ReadWriteLock的實現(xiàn)類但也存在一些問題。比如讀鎖和寫鎖之間會互相阻塞也就是所謂的寫?zhàn)囸I問題如果有大量線程在持續(xù)讀寫線程可能會長時間得不到執(zhí)行。它也不是完全公平的在非公平模式下寫線程插隊的機會是有限的。JDK 8引入了StampedLock它提供了一種更先進的鎖模型。StampedLock有三種模式寫鎖、讀鎖、樂觀讀。樂觀讀是一種完全不加鎖的讀操作它先獲取一個stamp標(biāo)記然后讀數(shù)據(jù)讀完后再次檢查stamp是否發(fā)生了變化。如果沒變說明讀的過程中沒有寫操作這次讀是可靠的如果變了則升級為普通的讀鎖重讀。樂觀讀非常適合讀多寫少的場景能夠大幅提升吞吐量。需要注意StampedLock不是可重入的而且不支持條件變量。使用樂觀讀時必須小心驗證stamp的有效性這個驗證過程要放在讀數(shù)據(jù)之后。5. 線程池參數(shù)配置與運行機制線程池是Java并發(fā)編程中應(yīng)用最廣的組件也是面試中的重頭戲。幾乎所有的Java后端服務(wù)都離不開線程池從Tomcat處理請求到RPC框架的異步調(diào)用都在使用線程池。理解線程池的運作機制不只是應(yīng)付面試更是日常開發(fā)的基本功。使用線程池的好處不需要多講降低資源消耗、提高響應(yīng)速度、提高線程的可管理性。JDK的線程池實現(xiàn)核心是ThreadPoolExecutor類它提供了非常豐富的構(gòu)造參數(shù)和靈活的擴展點。面試中考察線程池時幾乎必問的問題是ThreadPoolExecutor的核心參數(shù)有哪些分別代表什么含義核心參數(shù)包括corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。corePoolSize是核心線程數(shù)核心線程即使空閑也不會被銷毀maximumPoolSize是線程池允許的最大線程數(shù)keepAliveTime是非核心線程空閑存活時間超過這個時間就會被回收workQueue是任務(wù)隊列存儲等待執(zhí)行的任務(wù)threadFactory是線程工廠可以自定義線程命名等屬性handler是拒絕策略當(dāng)線程池和隊列都滿時如何處理新提交的任務(wù)。5.1 任務(wù)提交與執(zhí)行流程線程池執(zhí)行任務(wù)的流程是面試中必須掌握的。當(dāng)調(diào)用execute提交一個任務(wù)時ThreadPoolExecutor的執(zhí)行策略如下如果當(dāng)前線程數(shù)小于核心線程數(shù)corePoolSize則創(chuàng)建新線程來執(zhí)行任務(wù)如果當(dāng)前線程數(shù)大于等于核心線程數(shù)且隊列未滿則把任務(wù)放入隊列中等待執(zhí)行如果隊列已滿且當(dāng)前線程數(shù)小于最大線程數(shù)maximumPoolSize則創(chuàng)建非核心線程來執(zhí)行任務(wù)如果隊列已滿且線程數(shù)已達到最大線程數(shù)則根據(jù)拒絕策略執(zhí)行拒絕處理。這個流程可以用一句話總結(jié)先看核心線程是否夠用再看隊列是否能容納最后看最大線程數(shù)是否到頂。有一點要注意很多框架實際使用的線程池配置比如Dubbo這類RPC框架為了降低任務(wù)處理延遲會設(shè)置足夠大的核心線程數(shù)讓線程池不會因為隊列堆積而產(chǎn)生大量等待。這是典型的空間換時間的取舍。拒絕策略有四種實現(xiàn)分別是AbortPolicy拋出RejectedExecutionException異常阻止任務(wù)提交、CallerRunsPolicy調(diào)用提交任務(wù)的線程直接執(zhí)行被拒絕的任務(wù)、DiscardPolicy默默丟棄任務(wù)、DiscardOldestPolicy丟棄隊列中最早的任務(wù)然后嘗試重新提交。生產(chǎn)環(huán)境最常用的還是AbortPolicy和CallerRunsPolicy前者快速失敗后者能將壓力回傳給提交方起到背壓效果。如果一個系統(tǒng)對任務(wù)丟失不能接受那就要自定義拒絕策略比如把任務(wù)持久化到數(shù)據(jù)庫或消息隊列里。5.2 線程池參數(shù)配置的經(jīng)驗公式線程池參數(shù)并沒有一個萬能的配置公式具體要結(jié)合業(yè)務(wù)場景來定。但從經(jīng)驗來看可以根據(jù)任務(wù)類型是CPU密集型還是IO密集型來做初步估算。CPU密集型任務(wù)指的是計算量大、很少有IO等待的任務(wù)比如大量數(shù)學(xué)運算、圖像渲染。這類任務(wù)的瓶頸在CPU線程數(shù)和CPU核心數(shù)相當(dāng)即可。一般配置為CPU核心數(shù)1公式是Ncpu1。加1是為了避免CPU空轉(zhuǎn)當(dāng)某個線程因為缺頁或其他原因被暫停時多出的線程可以頂上。IO密集型任務(wù)指的是大量時間在等待IO操作的任務(wù)比如網(wǎng)絡(luò)請求、數(shù)據(jù)庫讀寫、文件操作。這類任務(wù)等待時間長CPU占用率低所以可以配置更多的線程。一般配置為CPU核心數(shù)的兩倍公式是2*Ncpu。更精細的估算方法是線程數(shù) CPU核心數(shù) * (1 平均等待時間 / 平均計算時間)。但這個公式對時間比的估計很難精確實踐中通常直接用2倍核數(shù)起步再通過壓測調(diào)整。拒絕策略的選擇和隊列類型也要配套考慮。比如使用有界隊列時隊列容量可以這樣估算期望的排隊等待時間乘以請求速率。如果平均請求速率為1000個每秒期望最大排隊時間為2秒那么隊列容量就可以設(shè)置為2000。當(dāng)然這只是理論參考實際還是以壓測為準(zhǔn)。我自己習(xí)慣的配置方法是先把核心線程數(shù)設(shè)置為系統(tǒng)的常駐請求并發(fā)數(shù)最大線程數(shù)設(shè)置為峰值并發(fā)數(shù)隊列容量設(shè)置為峰值和均值之間的緩沖量然后通過壓測逐步微調(diào)。線程池參數(shù)永遠不是一次配置就完成的而是在運行過程中持續(xù)監(jiān)控和調(diào)整的。5.3 手動創(chuàng)建線程池的正確姿勢前文提到阿里開發(fā)手冊禁止使用Executors創(chuàng)建線程池原因是Executors提供的幾個工廠方法都有隱患。newFixedThreadPool和newSingleThreadExecutor使用了無界隊列LinkedBlockingQueue當(dāng)任務(wù)提交速度超過處理速度時隊列會無限增長最終可能導(dǎo)致內(nèi)存溢出。newCachedThreadPool的最大線程數(shù)是Integer.MAX_VALUE如果任務(wù)提交過快而處理速度跟不上會創(chuàng)建大量線程耗盡系統(tǒng)資源。newScheduledThreadPool同樣存在隊列無界的問題。正確的方式是使用ThreadPoolExecutor的構(gòu)造方法手動創(chuàng)建。下面給一個參考配置ThreadPoolExecutor executor new ThreadPoolExecutor( corePoolSize, // 核心線程數(shù) maximumPoolSize, // 最大線程數(shù) keepAliveTime, // 非核心線程空閑存活時間 TimeUnit.SECONDS, // 時間單位 new ArrayBlockingQueue(queueCapacity), // 有界任務(wù)隊列 new ThreadFactory() { private final AtomicInteger counter new AtomicInteger(); Override public Thread newThread(Runnable r) { Thread thread new Thread(r, business-thread- counter.incrementAndGet()); thread.setDaemon(false); return thread; } }, new ThreadPoolExecutor.AbortPolicy() // 拒絕策略 );給線程命名是一個容易被忽視但很重要的細節(jié)。線上排查問題時如果線程名都是有業(yè)務(wù)含義的比如order-service-thread-1、mq-consumer-thread-2jstack輸出一眼就能看出是哪個業(yè)務(wù)模塊的線程出了問題。如果所有線程都叫pool-1-thread-1排查效率會低很多。線程池還需要關(guān)注動態(tài)調(diào)整。ThreadPoolExecutor提供了setCorePoolSize和setMaximumPoolSize方法可以在運行期調(diào)整參數(shù)。比較常見的做法是通過監(jiān)控系統(tǒng)度量指標(biāo)根據(jù)當(dāng)前的隊列長度和活躍線程數(shù)動態(tài)調(diào)整線程池參數(shù)來應(yīng)對流量波動。這在秒殺、大促這類場景特別有用。最后必須強調(diào)線程池在Spring容器中要作為單例Bean管理不要在每個業(yè)務(wù)方法里new一個線程池。我見過有同事在循環(huán)內(nèi)創(chuàng)建線程池直接把內(nèi)存打爆了。線程池是重資源必須復(fù)用量級實例。6. ThreadLocal與內(nèi)存泄漏陷阱ThreadLocal是一個很有意思的類它提供線程局部變量每個線程都有自己獨立的變量副本互不干擾。ThreadLocal的典型應(yīng)用場景包括存儲用戶會話信息、數(shù)據(jù)庫連接管理、SimpleDateFormat日期格式化工具的線程安全替換方案。ThreadLocal的原理說復(fù)雜也復(fù)雜說簡單也簡單。每個Thread對象內(nèi)部都有一個ThreadLocalMap這個Map的key是ThreadLocal對象本身的弱引用value是線程持有的變量值。當(dāng)線程訪問ThreadLocal時ThreadLocal內(nèi)部類會先從當(dāng)前線程中獲取ThreadLocalMap然后以自身為key去查找對應(yīng)的value。這里就引出了ThreadLocal最著名的內(nèi)存泄漏問題。ThreadLocalMap的key是弱引用WeakReferencevalue是強引用。當(dāng)外部沒有對ThreadLocal的強引用時GC回收時就會把key清掉但value仍然是強引用鏈Thread - ThreadLocalMap - Entry - value。如果線程生命周期很長而value一直不被清除就會造成內(nèi)存泄漏。規(guī)避這個問題的方法已經(jīng)成為一個共識使用完ThreadLocal后必須調(diào)用remove方法清除。尤其是在線程池場景下線程復(fù)用次數(shù)很多如果不顯式remove同一個線程處理不同請求時可能會讀取到上一個請求殘留的ThreadLocal值造成數(shù)據(jù)混亂。這個坑非常隱蔽線上偶發(fā)出現(xiàn)用戶串號這類問題很多就是ThreadLocal沒清理導(dǎo)致的。我習(xí)慣在finally塊里調(diào)用remove保證異常情況下也能清除。示例代碼如下try { threadLocal.set(userInfo); // 業(yè)務(wù)邏輯 } finally { threadLocal.remove(); }另外要提醒的是不要在靜態(tài)方法中跨線程使用ThreadLocal也不要把ThreadLocal的value設(shè)計成可變的共享對象。ThreadLocal解決的是線程間的變量隔離問題如果value本身是被多個線程共享的引用類型那線程隔離的效果就大打折扣了。6.1 子線程如何繼承父線程的ThreadLocal如果我們希望主線程設(shè)置的ThreadLocal值能被子線程讀取到直接使用ThreadLocal是做不到的因為子線程是獨立的新線程有自己的ThreadLocalMap。這時候可以使用InheritableThreadLocal。InheritableThreadLocal繼承了ThreadLocal它在線程創(chuàng)建時會把父線程的ThreadLocalMap中的值復(fù)制一份到子線程中。這樣子在子線程中就能讀取到父線程設(shè)置的值了。但是這里也有坑如果主線程在創(chuàng)建子線程之后修改了ThreadLocal的值子線程中的副本并不會自動更新。它只是創(chuàng)建時的一份快照之后兩者互不影響。如果需要實現(xiàn)父子線程間的全量傳遞比如鏈路追蹤需要把traceId傳遞到異步線程池中那就需要更強大的方案了。目前業(yè)內(nèi)常用的做法是使用TransmittableThreadLocalTTL這是阿里開源的一個庫能在線程池場景下實現(xiàn)上下文的無損傳遞。TTL會在任務(wù)提交時捕獲當(dāng)前線程的ThreadLocal值并在任務(wù)執(zhí)行時重新設(shè)置到執(zhí)行線程中執(zhí)行完再恢復(fù)原值。這個工具在分布式鏈路追蹤和異步并發(fā)場景中很有用如果簡歷上寫到了相關(guān)項目面試時提到TTL是一個不錯的加分項。7. 并發(fā)工具類CountDownLatch、CyclicBarrier、SemaphoreJDK 5在并發(fā)包中提供了幾個非常實用的同步工具類CountDownLatch、CyclicBarrier、Semaphore、Exchanger。它們基于AQS實現(xiàn)面試中考察概率很高尤其喜歡考CountDownLatch和CyclicBarrier的區(qū)別。CountDownLatch是一個倒計時器它允許一個或多個線程等待其他線程完成一組操作后再繼續(xù)執(zhí)行。典型場景是主線程啟動多個子線程并行執(zhí)行任務(wù)等所有子任務(wù)都完成后主線程再匯總結(jié)果。使用方法是先new CountDownLatch(n)指定計數(shù)數(shù)量每個子線程執(zhí)行完任務(wù)后調(diào)用countDown方法將計數(shù)減一主線程調(diào)用await方法阻塞等待直到計數(shù)變?yōu)?。CountDownLatch的計數(shù)是單向的減到0之后就無法重置了所以它只能使用一次。如果需要重復(fù)使用的場景應(yīng)該用CyclicBarrier。CyclicBarrier是循環(huán)屏障它允許多個線程在某個屏障點互相等待直到所有線程都到達該屏障點才繼續(xù)執(zhí)行。和CountDownLatch相比CyclicBarrier是所有線程互相等待而不是一個線程等待其他線程。它的計數(shù)可以重置所以可以循環(huán)使用。CyclicBarrier還支持一個可選的Runnable參數(shù)當(dāng)所有線程到達屏障點時會先執(zhí)行這個Runnable中的代碼。Semaphore是信號量它維護一組許可證線程在執(zhí)行前必須先acquire獲取許可證執(zhí)行完release歸還許可證。Semaphore常用于控制同時訪問特定資源的線程數(shù)比如連接池的連接數(shù)限制、限流控制。公平模式的Semaphore能保證先獲取許可證的線程先執(zhí)行避免饑餓問題。這三種工具類的適用場景很容易混淆我整理一個對比幫助記憶工具類核心用途使用次數(shù)等待關(guān)系CountDownLatch一個線程等待多個線程完成只能使用一次單向等待CyclicBarrier多個線程互相等待到達屏障可循環(huán)使用互相等待Semaphore控制同時執(zhí)行任務(wù)的最大線程數(shù)可重復(fù)使用獲取/釋放許可證它們?nèi)齻€在AQS中的實現(xiàn)方式也不同。CountDownLatch和Semaphore都是通過state字段來記錄計數(shù)或許可證數(shù)量獲取資源就是CAS遞減state釋放資源就是CAS遞增state。CyclicBarrier的實現(xiàn)更復(fù)雜一些它內(nèi)部使用了一個ReentrantLock和Condition來協(xié)調(diào)所有線程的等待和喚醒。7.1 實際項目中如何選用并發(fā)工具我做一個具體案例來演示這三個工具的實際選型思路。假設(shè)有一個數(shù)據(jù)統(tǒng)計任務(wù)要把10份數(shù)據(jù)文件分別統(tǒng)計再合并匯總出總結(jié)果。這個問題用CountDownLatch就很合適主線程開著10個子線程分別統(tǒng)計每個統(tǒng)計完countDown一次主線程await后做合并匯總。用CyclicBarrier也可以做但語義上不如CountDownLatch直接。再假設(shè)有這樣一個場景一個小組里的5個成員需要同時開始進行一個事務(wù)流程的各階段處理每個成員處理完自己的本階段工作后需要等所有成員都完成當(dāng)前階段才能進入下一階段。這個場景就是CyclicBarrier的經(jīng)典用例每輪階段結(jié)束就自動進入下一輪循環(huán)使用。而控制某個服務(wù)的最大并發(fā)調(diào)用數(shù)比如限定對第三方接口的調(diào)用并發(fā)不超過20則會用Semaphore。每次調(diào)用前acquire調(diào)用完release超出的請求就會阻塞等待。在真實的高并發(fā)項目中這三個工具經(jīng)常組合使用。比如用Semaphore限流用CountDownLatch做任務(wù)編排用CyclicBarrier做分階段并行計算。理解了每個工具的設(shè)計目標(biāo)和適用場景寫起來就自然順暢。8. 多線程問題排查與實戰(zhàn)技巧理論講了這么多最終還是要落到實戰(zhàn)。多線程開發(fā)中代碼層面的問題往往是隱蔽且難以復(fù)現(xiàn)的死鎖、線程泄漏、CPU飆高、內(nèi)存溢出每一類都讓人頭疼。這節(jié)分享一下我在實際項目中排查多線程問題的思路和方法。死鎖是最經(jīng)典的多線程問題。產(chǎn)生死鎖的四個條件是互斥條件、持有并等待條件、不可剝奪條件、循環(huán)等待條件。排查死鎖時最快的方式是使用jstack命令獲取當(dāng)前Java進程的線程快照它會自動檢測死鎖并打印出死鎖的線程和鎖的持有情況。先通過jps找到Java進程的PID然后執(zhí)行jstack PID輸出信息中如果包含F(xiàn)ound one Java-level deadlock這樣的字樣就說明死鎖了。隨后信息中會詳細展示兩個線程分別持有什么鎖、在等待什么鎖。根據(jù)這些信息就能定位到是哪段代碼導(dǎo)致的死鎖。線上遇到CPU飆高的問題排查思路是先通過top -H -p PID找到CPU占用率最高的線程ID把它轉(zhuǎn)成十六進制然后jstack PID | grep -A 20 nid0x十六進制值就能定位到具體線程的堆棧。如果堆棧停留在線程池的任務(wù)執(zhí)行方法上那大概率是某個業(yè)務(wù)方法出現(xiàn)了死循環(huán)或者大量的無效計算。對于線程池線程數(shù)量異常增長的問題多半是任務(wù)隊列容量設(shè)置不合理或者拒絕策略配置不當(dāng)。優(yōu)先檢查ThreadPoolExecutor的四個關(guān)鍵指標(biāo)當(dāng)前活躍線程數(shù)、核心線程數(shù)、最大線程數(shù)、隊列剩余容量?？梢酝ㄟ^暴露metrics接口來定期采集這些狀態(tài)配合監(jiān)控告警在問題擴大前及時介入。我曾經(jīng)排查過一個典型的線程泄漏問題線上服務(wù)運行幾天后線程數(shù)線性增長最終內(nèi)存溢出。jstack后發(fā)現(xiàn)大量線程阻塞在數(shù)據(jù)庫連接獲取處。究其原因是某個線程池中的任務(wù)里調(diào)用了數(shù)據(jù)庫操作但因為事務(wù)配置錯誤導(dǎo)致連接沒有釋放后續(xù)任務(wù)全部積壓在等待連接的隊列中線程池不斷創(chuàng)建新的線程來承接新任務(wù)。最終定位到的是連接泄漏問題而不是線程池配置問題。所以排查線程問題時要跳出線程本身去看它依賴的資源和下游系統(tǒng)。多線程的調(diào)試也很特殊斷點調(diào)試多線程時往往會改變線程的執(zhí)行時序原來能復(fù)現(xiàn)的并發(fā)Bug可能一下子就不出現(xiàn)了。我建議多用日志來輔助排查在關(guān)鍵節(jié)點打印線程名、時間戳、關(guān)鍵數(shù)據(jù)狀態(tài)。給線程起好名字在這里就顯得特別重要了打印出來的日志里如果能直接看到是哪個業(yè)務(wù)的線程在活動排查效率能提升一大截。還有一個小技巧在開發(fā)階段可以通過設(shè)置JVM參數(shù)-XX:PrintConcurrentLocks來打印并發(fā)鎖的信息結(jié)合jstack使用能更清楚地看到鎖的競爭情況。另外如果項目用了Caffeine或者Redisson這類第三方庫它們在日志里也會有關(guān)鍵線索比如阻塞隊列深度、鎖等待時間等。9. 面試答題技巧與高頻八股速查最后這部分我結(jié)合自己面試和被面的經(jīng)驗整理一份高頻Java線程八股的快問快答順便聊一下怎么答才能從海量候選人中脫穎而出。先說答題思路。八股文的答案大多有個標(biāo)準(zhǔn)范式但面試官真正想看的是你有沒有自己的理解。所以回答任何概念題我建議按照是什么-為什么-怎么用-有什么坑的四段式結(jié)構(gòu)來展開。比如被問到synchronized鎖升級不要只背偏向鎖、輕量級鎖、重量級鎖三個名詞而要說清楚為什么需要鎖升級、JDK 6之前性能差的原因是什么、升級條件是什么、什么場景下會出現(xiàn)什么問題。這樣的回答會讓面試官覺得你是真的用過在真實項目中踩過坑有思考深度。常見問題速查如下線程創(chuàng)建方式有幾種四種繼承Thread、實現(xiàn)Runnable、實現(xiàn)Callable配合FutureTask、線程池。線程有哪些狀態(tài)六種NEW、RUNNABLE、BLOCKED、WAITING、TIMED_WAITING、TERMINATED。注意RUNNABLE是Java層概念實際可能處于運行中或者等待CPU調(diào)度。sleep和wait區(qū)別sleep不釋放鎖wait釋放鎖sleep是Thread方法wait是Object方法sleep需要指定時間wait可以不指定也可以指定時間sleep用于暫停執(zhí)行wait用于線程間通信。synchronized和ReentrantLock區(qū)別是否自動釋放鎖、是否可重入都可重入、是否支持公平鎖、是否可中斷、是否支持多個條件變量、底層實現(xiàn)JVM層面 vs JDK層面。volatile和synchronized的區(qū)別volatile不保證原子性、只能修飾變量、不會阻塞線程synchronized保證原子性、可修飾方法和代碼塊、未獲取鎖的線程會阻塞。ThreadLocal內(nèi)存泄漏的解決方案使用完調(diào)用remove或者在ThreadLocal的Entry中通過弱引用來輔助回收。線程池的拒絕策略有哪些AbortPolicy拋異常、CallerRunsPolicy調(diào)用者執(zhí)行、DiscardPolicy丟棄、DiscardOldestPolicy丟棄最老的。生產(chǎn)環(huán)境最常用AbortPolicy和CallerRunsPolicy。CountDownLatch和CyclicBarrier區(qū)別方向不同CountDownLatch是一個/多個線程等待其他線程CyclicBarrier是多個線程互相等待CountDownLatch只能使用一次CyclicBarrier可以循環(huán)使用CountDownLatch基于AQSCyclicBarrier基于ReentrantLock和Condition。CAS的優(yōu)缺點優(yōu)點是非阻塞、無需鎖和上下文切換缺點是只能保證一個變量的原子操作、循環(huán)時間長開銷大、存在ABA問題。ABA問題可以通過AtomicStampedReference加版本號解決。什么是線程安全多個線程訪問共享數(shù)據(jù)時無論線程如何交替執(zhí)行最終結(jié)果都符合預(yù)期且不產(chǎn)生數(shù)據(jù)破壞。有一個問題值得特別說一下為什么阿里規(guī)范強調(diào)不用Executors創(chuàng)建線程池除了前面說的無界隊列和最大線程數(shù)問題還有一個隱性問題Executors里創(chuàng)建的線程工廠基本都是默認的線程名毫無辨識度出問題排查起來很麻煩。使用自定義ThreadPoolExecutor加自定義ThreadFactory是最佳的實踐路徑。最后的最后想跟準(zhǔn)備面試的朋友說一句線程八股的知識點再多歸根結(jié)底是幫助你建立對并發(fā)編程的完整認知框架。不要只是死記硬背建議把文中的代碼都動手跑一遍改一改參數(shù)觀察現(xiàn)象遇到問題再回頭看理論印象會深刻得多。并發(fā)編程是一門實踐性很強的學(xué)問理論只是地圖真正踏過一遍坑才能成為自己手頭的能力。