Java多線程問題總結（下）

首先明確一下，不是說ReentrantLock不好，隻是ReentrantLock某些時候有局限。如果使用ReentrantLock，可能本身是為了防止線程A在寫數據、線程B在讀數據造成的數據不一致，但這樣，如果線程C在讀數據、線程D也在讀數據，讀數據是不會改變數據的，沒有必要加鎖，但是還是加鎖了，降低了程序的性能。

因為這個，才誕生了讀寫鎖ReadWriteLock。ReadWriteLock是一個讀寫鎖接口，ReentrantReadWriteLock是ReadWriteLock接口的一個具體實現，實現了讀寫的分離，讀鎖是共享的，寫鎖是獨占的，讀和讀之間不會互斥，讀和寫、寫和讀、寫和寫之間才會互斥，提升了讀寫的性能。

21、FutureTask是什麼

這個其實前麵有提到過，FutureTask表示一個異步運算的任務。FutureTask裏麵可以傳入一個Callable的具體實現類，可以對這個異步運算的任務的結果進行等待獲取、判斷是否已經完成、取消任務等操作。當然，由於FutureTask也是Runnable接口的實現類，所以FutureTask也可以放入線程池中。

22、Linux環境下如何查找哪個線程使用CPU最長

這是一個比較偏實踐的問題，這種問題我覺得挺有意義的。可以這麼做：

（1）獲取項目的pid，jps或者ps -ef | grep java，這個前麵有講過

（2）top -H -p pid，順序不能改變

這樣就可以打印出當前的項目，每條線程占用CPU時間的百分比。注意這裏打出的是LWP，也就是操作係統原生線程的線程號，我筆記本山沒有部署Linux環境下的Java工程，因此沒有辦法截圖演示，網友朋友們如果公司是使用Linux環境部署項目的話，可以嚐試一下。

使用"top -H -p pid"+"jps pid"可以很容易地找到某條占用CPU高的線程的線程堆棧，從而定位占用CPU高的原因，一般是因為不當的代碼操作導致了死循環。

最後提一點，"top -H -p pid"打出來的LWP是十進製的，"jps pid"打出來的本地線程號是十六進製的，轉換一下，就能定位到占用CPU高的線程的當前線程堆棧了。

23、Java編程寫一個會導致死鎖的程序

第一次看到這個題目，覺得這是一個非常好的問題。很多人都知道死鎖是怎麼一回事兒：線程A和線程B相互等待對方持有的鎖導致程序無限死循環下去。當然也僅限於此了，問一下怎麼寫一個死鎖的程序就不知道了，這種情況說白了就是不懂什麼是死鎖，懂一個理論就完事兒了，實踐中碰到死鎖的問題基本上是看不出來的。

真正理解什麼是死鎖，這個問題其實不難，幾個步驟：

（1）兩個線程裏麵分別持有兩個Object對象：lock1和lock2。這兩個lock作為同步代碼塊的鎖；

（2）線程1的run()方法中同步代碼塊先獲取lock1的對象鎖，Thread.sleep(xxx)，時間不需要太多，50毫秒差不多了，然後接著獲取lock2的對象鎖。這麼做主要是為了防止線程1啟動一下子就連續獲得了lock1和lock2兩個對象的對象鎖

（3）線程2的run)(方法中同步代碼塊先獲取lock2的對象鎖，接著獲取lock1的對象鎖，當然這時lock1的對象鎖已經被線程1鎖持有，線程2肯定是要等待線程1釋放lock1的對象鎖的

這樣，線程1"睡覺"睡完，線程2已經獲取了lock2的對象鎖了，線程1此時嚐試獲取lock2的對象鎖，便被阻塞，此時一個死鎖就形成了。代碼就不寫了，占的篇幅有點多，Java多線程7：死鎖這篇文章裏麵有，就是上麵步驟的代碼實現。

24、怎麼喚醒一個阻塞的線程

如果線程是因為調用了wait()、sleep()或者join()方法而導致的阻塞，可以中斷線程，並且通過拋出InterruptedException來喚醒它；如果線程遇到了IO阻塞，無能為力，因為IO是操作係統實現的，Java代碼並沒有辦法直接接觸到操作係統。

25、不可變對象對多線程有什麼幫助

前麵有提到過的一個問題，不可變對象保證了對象的內存可見性，對不可變對象的讀取不需要進行額外的同步手段，提升了代碼執行效率。

26、什麼是多線程的上下文切換

多線程的上下文切換是指CPU控製權由一個已經正在運行的線程切換到另外一個就緒並等待獲取CPU執行權的線程的過程。

27、如果你提交任務時，線程池隊列已滿，這時會發生什麼

如果你使用的LinkedBlockingQueue，也就是無界隊列的話，沒關係，繼續添加任務到阻塞隊列中等待執行，因為LinkedBlockingQueue可以近乎認為是一個無窮大的隊列，可以無限存放任務；如果你使用的是有界隊列比方說ArrayBlockingQueue的話，任務首先會被添加到ArrayBlockingQueue中，ArrayBlockingQueue滿了，則會使用拒絕策略RejectedExecutionHandler處理滿了的任務，默認是AbortPolicy。

28、Java中用到的線程調度算法是什麼

搶占式。一個線程用完CPU之後，操作係統會根據線程優先級、線程饑餓情況等數據算出一個總的優先級並分配下一個時間片給某個線程執行。

29、Thread.sleep(0)的作用是什麼

這個問題和上麵那個問題是相關的，我就連在一起了。由於Java采用搶占式的線程調度算法，因此可能會出現某條線程常常獲取到CPU控製權的情況，為了讓某些優先級比較低的線程也能獲取到CPU控製權，可以使用Thread.sleep(0)手動觸發一次操作係統分配時間片的操作，這也是平衡CPU控製權的一種操作。

30、什麼是自旋

很多synchronized裏麵的代碼隻是一些很簡單的代碼，執行時間非常快，此時等待的線程都加鎖可能是一種不太值得的操作，因為線程阻塞涉及到用戶態和內核態切換的問題。既然synchronized裏麵的代碼執行得非常快，不妨讓等待鎖的線程不要被阻塞，而是在synchronized的邊界做忙循環，這就是自旋。如果做了多次忙循環發現還沒有獲得鎖，再阻塞，這樣可能是一種更好的策略。

31、什麼是Java內存模型

Java內存模型定義了一種多線程訪問Java內存的規範。Java內存模型要完整講不是這裏幾句話能說清楚的，我簡單總結一下Java內存模型的幾部分內容：

（1）Java內存模型將內存分為了主內存和工作內存。類的狀態，也就是類之間共享的變量，是存儲在主內存中的，每次Java線程用到這些主內存中的變量的時候，會讀一次主內存中的變量，並讓這些內存在自己的工作內存中有一份拷貝，運行自己線程代碼的時候，用到這些變量，操作的都是自己工作內存中的那一份。在線程代碼執行完畢之後，會將最新的值更新到主內存中去

（2）定義了幾個原子操作，用於操作主內存和工作內存中的變量

（3）定義了volatile變量的使用規則

（4）happens-before，即先行發生原則，定義了操作A必然先行發生於操作B的一些規則，比如在同一個線程內控製流前麵的代碼一定先行發生於控製流後麵的代碼、一個釋放鎖unlock的動作一定先行發生於後麵對於同一個鎖進行鎖定lock的動作等等，隻要符合這些規則，則不需要額外做同步措施，如果某段代碼不符合所有的happens-before規則，則這段代碼一定是線程非安全的

32、什麼是CAS

CAS，全稱為Compare and Swap，即比較-替換。假設有三個操作數：內存值V、舊的預期值A、要修改的值B，當且僅當預期值A和內存值V相同時，才會將內存值修改為B並返回true，否則什麼都不做並返回false。當然CAS一定要volatile變量配合，這樣才能保證每次拿到的變量是主內存中最新的那個值，否則舊的預期值A對某條線程來說，永遠是一個不會變的值A，隻要某次CAS操作失敗，永遠都不可能成功。

33、什麼是樂觀鎖和悲觀鎖

（1）樂觀鎖：就像它的名字一樣，對於並發間操作產生的線程安全問題持樂觀狀態，樂觀鎖認為競爭不總是會發生，因此它不需要持有鎖，將比較-替換這兩個動作作為一個原子操作嚐試去修改內存中的變量，如果失敗則表示發生衝突，那麼就應該有相應的重試邏輯。

（2）悲觀鎖：還是像它的名字一樣，對於並發間操作產生的線程安全問題持悲觀狀態，悲觀鎖認為競爭總是會發生，因此每次對某資源進行操作時，都會持有一個獨占的鎖，就像synchronized，不管三七二十一，直接上了鎖就操作資源了。

34、什麼是AQS

簡單說一下AQS，AQS全稱為AbstractQueuedSychronizer，翻譯過來應該是抽象隊列同步器。

如果說java.util.concurrent的基礎是CAS的話，那麼AQS就是整個Java並發包的核心了，ReentrantLock、CountDownLatch、Semaphore等等都用到了它。AQS實際上以雙向隊列的形式連接所有的Entry，比方說ReentrantLock，所有等待的線程都被放在一個Entry中並連成雙向隊列，前麵一個線程使用ReentrantLock好了，則雙向隊列實際上的第一個Entry開始運行。

AQS定義了對雙向隊列所有的操作，而隻開放了tryLock和tryRelease方法給開發者使用，開發者可以根據自己的實現重寫tryLock和tryRelease方法，以實現自己的並發功能。

35、單例模式的線程安全性

老生常談的問題了，首先要說的是單例模式的線程安全意味著：某個類的實例在多線程環境下隻會被創建一次出來。單例模式有很多種的寫法，我總結一下：

（1）餓漢式單例模式的寫法：線程安全

（2）懶漢式單例模式的寫法：非線程安全

（3）雙檢鎖單例模式的寫法：線程安全

36、Semaphore有什麼作用

Semaphore就是一個信號量，它的作用是限製某段代碼塊的並發數。Semaphore有一個構造函數，可以傳入一個int型整數n，表示某段代碼最多隻有n個線程可以訪問，如果超出了n，那麼請等待，等到某個線程執行完畢這段代碼塊，下一個線程再進入。由此可以看出如果Semaphore構造函數中傳入的int型整數n=1，相當於變成了一個synchronized了。

37、Hashtable的size()方法中明明隻有一條語句"return count"，為什麼還要做同步？

這是我之前的一個困惑，不知道大家有沒有想過這個問題。某個方法中如果有多條語句，並且都在操作同一個類變量，那麼在多線程環境下不加鎖，勢必會引發線程安全問題，這很好理解，但是size()方法明明隻有一條語句，為什麼還要加鎖？

關於這個問題，在慢慢地工作、學習中，有了理解，主要原因有兩點：

（1）同一時間隻能有一條線程執行固定類的同步方法，但是對於類的非同步方法，可以多條線程同時訪問。所以，這樣就有問題了，可能線程A在執行Hashtable的put方法添加數據，線程B則可以正常調用size()方法讀取Hashtable中當前元素的個數，那讀取到的值可能不是最新的，可能線程A添加了完了數據，但是沒有對size++，線程B就已經讀取size了，那麼對於線程B來說讀取到的size一定是不準確的。而給size()方法加了同步之後，意味著線程B調用size()方法隻有在線程A調用put方法完畢之後才可以調用，這樣就保證了線程安全性

（2）CPU執行代碼，執行的不是Java代碼，這點很關鍵，一定得記住。Java代碼最終是被翻譯成匯編代碼執行的，匯編代碼才是真正可以和硬件電路交互的代碼。即使你看到Java代碼隻有一行，甚至你看到Java代碼編譯之後生成的字節碼也隻有一行，也不意味著對於底層來說這句語句的操作隻有一個。一句"return count"假設被翻譯成了三句匯編語句執行，完全可能執行完第一句，線程就切換了。

38、線程類的構造方法、靜態塊是被哪個線程調用的

這是一個非常刁鑽和狡猾的問題。請記住：線程類的構造方法、靜態塊是被new這個線程類所在的線程所調用的，而run方法裏麵的代碼才是被線程自身所調用的。

如果說上麵的說法讓你感到困惑，那麼我舉個例子，假設Thread2中new了Thread1，main函數中new了Thread2，那麼：

（1）Thread2的構造方法、靜態塊是main線程調用的，Thread2的run()方法是Thread2自己調用的

（2）Thread1的構造方法、靜態塊是Thread2調用的，Thread1的run()方法是Thread1自己調用的

39、同步方法和同步塊，哪個是更好的選擇

同步塊，這意味著同步塊之外的代碼是異步執行的，這比同步整個方法更提升代碼的效率。請知道一條原則：同步的範圍越小越好。

借著這一條，我額外提一點，雖說同步的範圍越少越好，但是在Java虛擬機中還是存在著一種叫做鎖粗化的優化方法，這種方法就是把同步範圍變大。這是有用的，比方說StringBuffer，它是一個線程安全的類，自然最常用的append()方法是一個同步方法，我們寫代碼的時候會反複append字符串，這意味著要進行反複的加鎖->解鎖，這對性能不利，因為這意味著Java虛擬機在這條線程上要反複地在內核態和用戶態之間進行切換，因此Java虛擬機會將多次append方法調用的代碼進行一個鎖粗化的操作，將多次的append的操作擴展到append方法的頭尾，變成一個大的同步塊，這樣就減少了加鎖-->解鎖的次數，有效地提升了代碼執行的效率。

40、高並發、任務執行時間短的業務怎樣使用線程池？並發不高、任務執行時間長的業務怎樣使用線程池？並發高、業務執行時間長的業務怎樣使用線程池？

這是我在並發編程網上看到的一個問題，把這個問題放在最後一個，希望每個人都能看到並且思考一下，因為這個問題非常好、非常實際、非常專業。關於這個問題，個人看法是：

（1）高並發、任務執行時間短的業務，線程池線程數可以設置為CPU核數+1，減少線程上下文的切換

（2）並發不高、任務執行時間長的業務要區分開看：

　　a）假如是業務時間長集中在IO操作上，也就是IO密集型的任務，因為IO操作並不占用CPU，所以不要讓所有的CPU閑下來，可以加大線程池中的線程數目，讓CPU處理更多的業務

　　b）假如是業務時間長集中在計算操作上，也就是計算密集型任務，這個就沒辦法了，和（1）一樣吧，線程池中的線程數設置得少一些，減少線程上下文的切換

（3）並發高、業務執行時間長，解決這種類型任務的關鍵不在於線程池而在於整體架構的設計，看看這些業務裏麵某些數據是否能做緩存是第一步，增加服務器是第二步，至於線程池的設置，設置參考（2）。最後，業務執行時間長的問題，也可能需要分析一下，看看能不能使用中間件對任務進行拆分和解耦。