40個Java多執行緒問題總結

前言

Java多線程分類中寫了21篇多線程的文章，21篇文章的內容很多，個人認為，學習，內容越多、越雜的知識，越需要進行深刻的總結，這樣才能記憶深刻，將知識變成自己的。這篇文章主要是對多線程的問題進行總結的，因此羅列了40個多線程的問題。

這些多執行緒的問題，有些來自各大網站、有些來自自己的思考。或許有些問題網上有、可能有些問題對應的答案也有、也可能有些各位網友也都看過，但是本文寫作的重心就是所有的問題都會按照自己的理解回答一遍，不會去看網上的答案，因此可能有些問題講的不對，能指正的希望大家不吝指教。

# 40個問題總結

1、多執行緒有什麼用？

# 一個可能在很多人看來很扯淡的一個問題：我會用多執行緒就好了，還管它有什麼用？在我看來，這個回答更扯淡。所謂"知其然知其所以然"，"會用"只是"知其然"，"為什麼用"才是"知其所以然"，只有達到"知其然知其所以然"的程度才可以說是把一個知識點運用自如。 OK，下面說說我對這個問題的看法：

（1）發揮多核心CPU的優勢

# 隨著工業的進步，現在的筆記本、桌上型電腦乃至商用的應用伺服器至少也都是雙核心的，4核心、8核心甚至16核心的也都不少見，如果是單線程的程序，那麼在雙核心CPU上就浪費了50%，在4核心CPU上就浪費了75%。單核心CPU上所謂的"多線程"那是假的多線程，同一時間處理器只會處理一段邏輯，只不過線程之間切換得比較快，看著像多個線程"同時"運行罷了。多核心CPU上的多線程才是真正的多線程，它能讓你的多段邏輯同時運作，多線程，可以真正發揮出多核心CPU的優勢來，達到充分利用CPU的目的。

（2）防止阻塞

從程式運作效率的角度來看，單核心CPU不但不會發揮出多執行緒的優勢，反而會因為在單核心CPU上執行多執行緒導致執行緒上下文的切換，而降低程式整體的效率。但是單核心CPU我們還是要應用多線程，就是為了防止阻塞。試想，如果單核心CPU使用單線程，那麼只要這個線程阻塞了，比方說遠程讀取某個數據吧，對端遲遲未返回又沒有設置超時時間，那麼你的整個程序在數據返回回來之前就停止運行了。多執行緒可以防止這個問題，多條執行緒同時運行，即使一條執行緒的程式碼執行讀取資料阻塞，也不會影響其它任務的執行。

（3）便於建模

這是另外一個沒有這麼明顯的優點了。假設有一個大的任務A，單執行緒編程，那麼就要考慮很多，建立整個程式模型比較麻煩。但如果把這個大的任務A分解成幾個小任務，任務B、任務C、任務D，分別建立程式模型，並透過多執行緒分別執行這幾個任務，那就簡單很多了。

 

# 2、建立執行緒的方式

比較常見的一個問題了，一般就是兩種：

（1）繼承Thread類別

（2）實作Runnable介面

# 至於哪個好，不用說肯定是後者好，因為實現介面的方式比繼承類別的方式更靈活，也能減少程式之間的耦合度，面向介面程式設計也是設計模式6大原則的核心。

 

# 3、start()方法和run()方法的差異

# 只有呼叫了start()方法，才會表現出多執行緒的特性，不同執行緒的run()方法裡面的程式碼交替執行。如果只是呼叫run()方法，那麼程式碼還是同步執行的，必須等待一個執行緒的run()方法裡面的程式碼全部執行完畢之後，另外一個執行緒才可以執行其run()方法裡面的程式碼。

 

# 4、Runnable介面與Callable介面的差異

# 有點深的問題了，也看出一個Java程式設計師學習知識的廣度。

Runnable介面中的run()方法的回傳值是void，它所做的事情只是純粹地去執行run()方法中的程式碼而已；Callable介面中的call()方法是有回傳值的，是一個泛型，和Future、FutureTask配合可以用來得到非同步執行的結果。

這其實是很有用的一個特性，因為多執行緒相比單執行緒更難、更複雜的一個重要原因就是因為多執行緒充滿著未知性，某條執行緒是否執行了？某條線程執行多久了？某條執行緒執行的時候我們期望的資料是否已經賦值完畢？無法得知，我們能做的只是等待這條多執行緒的任務執行完畢而已。而Callable+Future/FutureTask卻可以取得多執行緒運行的結果，可以在等待時間太長沒取得到需要的資料的情況下取消該執行緒的任務，真的是非常有用。

 

# 5、CyclicBarrier與CountDownLatch的差異

兩個看起來有點像的類，都在java.util.concurrent下，都可以用來表示程式碼運行到某個點上，二者的差別在於：

（1）CyclicBarrier的某個執行緒運行到某個點上之後，該執行緒即停止運行，直到所有的執行緒都到達了這個點，所有執行緒才重新運行；CountDownLatch則不是，某執行緒運行到某個點上之後，只是給某個數值-1而已，該執行緒繼續運行

（2）CyclicBarrier只能喚起一個任務，CountDownLatch可以喚起多個任務

# （3）CyclicBarrier可重複使用，CountDownLatch不可重用，計數值為0該CountDownLatch就不可再用了

 

# 6、volatile關鍵字的作用

一個非常重要的問題，是每個學習、應用多執行緒的Java程式設計師都必須掌握的。理解volatile關鍵字的作用的前提是要理解Java記憶體模型，這裡就不講Java記憶體模型了，可以參考第31點，volatile關鍵字的作用主要有兩個：

# （1）多線程主要圍繞可見性和原子性兩個特性而展開，使用volatile關鍵字修飾的變量，保證了其在多線程之間的可見性，即每次讀取到volatile變量，一定是最新的數據

（2）程式碼底層執行不像我們看到的高階語言----Java程式這麼簡單，它的執行是Java程式碼-->字節碼-->根據字節碼執行對應的C/C++程式碼-->C/C++程式碼被編譯成彙編語言-->和硬體電路交互，現實中，為了取得更好的效能JVM可能會對指令進行重排序，多執行緒下可能會出現一些意想不到的問題。使用volatile則會對禁止語意重排序，當然這也一定程度上降低了程式碼執行效率

從實作角度而言，volatile的一個重要作用就是和CAS結合，保證了原子性，詳細的可以參考java.util.concurrent.atomic包下的類，例如AtomicInteger。

 

# 7、什麼是執行緒安全性

又是一個理論的問題，各式各樣的答案有很多，我給出一個個人認為解釋地最好的：如果你的程式碼在多執行緒下執行和在單執行緒下執行永遠都能獲得一樣的結果，那你的程式碼就是線程安全的。

這個問題有值得一提的地方，就是線程安全也是有幾個等級的：

# （1）不可變

像String、Integer、Long這些，都是final類型的類，任何一個執行緒都改變不了它們的值，要改變除非新建立一個，因此這些不可變物件不需要任何同步手段就可以直接在多執行緒環境下使用

（2）絕對線程安全

不管運行時環境如何，呼叫者都不需要額外的同步措施。要做到這一點通常需要付出許多額外的代價，Java中標註自己是線程安全的類，實際上絕大多數都不是線程安全的，不過絕對線程安全的類，Java中也有，比方說CopyOnWriteArrayList、CopyOnWriteArraySet

（3）相對線程安全性

相對線程安全也就是我們通常意義上所說的線程安全，像Vector這種，add、remove方法都是原子操作，不會被打斷，但也僅限於此，如果有個線程在遍歷某個Vector 、有個執行緒同時在add這個Vector，99%的情況下都會出現ConcurrentModificationException，也就是fail-fast機制。

（4）線程非安全性

這個就沒什麼好說的了，ArrayList、LinkedList、HashMap等都是線程非安全的類別

#  

# 8、Java中如何取得到執行緒dump檔

# 死循環、死鎖、阻塞、頁面開啟慢等問題，打線程dump是最好的解決問題的方法。所謂執行緒dump也就是執行緒堆疊，取得到執行緒堆疊有兩步：

# （1）取得到執行緒的pid，可以透過使用jps指令，在Linux環境下也可以使用ps -ef | grep java

# （2）列印線程堆疊，可以透過使用jstack pid命令，在Linux環境下還可以使用kill -3 pid

另外提一點，Thread類別提供了一個getStackTrace()方法也可以用來取得線程堆疊。這是一個實例方法，因此此方法是和具體線程實例綁定的，每次獲取獲取到的是具體某個線程當前運行的堆疊，

 

9、一個執行緒如果出現了執行時期異常會怎麼樣

# 如果這個異常沒有被捕獲的話，這個線程就停止執行了。另外重要的一點是：如果這個執行緒持有某個某個物件的監視器，那麼這個物件監視器會被立即釋放

#  

# 10、如何在兩個執行緒之間共享資料

透過在線程之間共享物件就可以了，然後透過wait/notify/notifyAll、await/signal/signalAll進行喚起和等待，比方說阻塞隊列BlockingQueue就是為線程之間共享資料而設計的

 

# 11、sleep方法和wait方法有什麼差別

# 這個問題常問，sleep方法和wait方法都可以用來放棄CPU一定的時間，不同點在於如果執行緒持有某個物件的監視器，sleep方法不會放棄這個物件的監視器，wait方法會放棄這個物件的監視器

 

# 12、生產者消費者模式的作用是什麼

# 這個問題很理論，但是很重要：

（1）透過平衡生產者的生產能力和消費者的消費能力來提升整個系統的運作效率，這是生產者消費者模型最重要的角色

# （2）解耦，這是生產者消費者模型附帶的作用，解耦意味著生產者和消費者之間的聯繫少，聯繫越少越可以獨自發展而不需要收到相互的限制

 

# 13、ThreadLocal有什麼用

# 簡單說ThreadLocal就是一種以空間換時間的做法，在每個Thread裡面維護了一個以開地址法實現的ThreadLocal.ThreadLocalMap，把資料隔離，資料不共享，自然就沒有線程安全方面的問題了

 

# 14、為什麼wait()方法和notify()/notifyAll()方法要在同步區塊中被呼叫

這是JDK強制的，wait()方法和notify()/notifyAll()方法在呼叫前都必須先取得物件的鎖定

#  

# 15、wait()方法和notify()/notifyAll()方法在放棄物件監視器時有什麼區別

# wait()方法和notify()/notifyAll()方法在放棄物件監視器的時候的差別在於：wait()方法立即釋放物件監視器，notify()/notifyAll()方法則會等待執行緒剩餘程式碼執行完畢才會放棄對象監視器。

 

# 16、為什麼要使用執行緒池

避免頻繁地建立和銷毀線程，達到線程物件的重複使用。另外，使用線程池還可以根據項目靈活地控制並發的數目。

 

# 17、怎麼偵測一個執行緒是否持有物件監視器

# 我也是在網路上看到多執行緒面試題才知道有方法可以判斷某個執行緒是否持有物件監視器：Thread類別提供了一個holdsLock(Object obj)方法，當且僅當物件obj的監視器被某條線程持有的時候才會回傳true，注意這是一個static方法，這表示"某條線程"指的是當前線程。

 

# 18、synchronized和ReentrantLock的差異

synchronized是和if、else、for、while一樣的關鍵字，ReentrantLock是類，這是二者的本質差異。既然ReentrantLock是類，那麼它就提供了比synchronized更多更靈活的特性，可以被繼承、可以有方法、可以有各種各樣的類變量，ReentrantLock比synchronized的擴展性體現在幾點上：

（1）ReentrantLock可以對獲取鎖的等待時間進行設置，這樣就避免了死鎖

# （2）ReentrantLock可以取得各種鎖的資訊

（3）ReentrantLock可以靈活地實現多路通知

另外，二者的鎖機制其實也是不一樣的。 ReentrantLock底層呼叫的是Unsafe的park方法加鎖，synchronized操作的應該是物件頭中mark word，這點我不能確定。

 

# 19、ConcurrentHashMap的並發度是什麼

ConcurrentHashMap的並發度就是segment的大小，預設為16，這表示最多同時可以有16個執行緒操作ConcurrentHashMap，也是ConcurrentHashMap對Hashtable的最大優勢，任何情況下，Hashtable能同時有兩條執行緒取得Hashtable中的數據嗎？

 

# 20、ReadWriteLock是什麼

# 首先明確一下，不是說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、怎麼喚醒一個阻塞的執行緒

如果執行緒是因為呼叫了w​​ait()、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）。最後，業務執行時間長的問題，也可能需要分析一下，看看能不能使用中間件對任務進行分割和解耦。

以上是40個Java多執行緒問題總結的詳細內容。更多資訊請關注PHP中文網其他相關文章！