新鮮出爐！面試90%會被問到的Java多線程面試題，史上最全系列！

時間 2020-06-03

原文原文鏈接

前言

最近不少粉絲朋友私聊我說能不能給整理出一份多線程面試題出來，說本身在最近的面試中總是被問到這一塊的問題被問的很煩躁，前一段時間比較忙沒時間回私信，前兩天看到私信我也是趕忙花了兩天給你們整理出這一塊的面試題庫出來讓你們看看，話很少說都給你們總結在下面了！java

一、多線程有什麼用？

一個可能在不少人看來很扯淡的一個問題：我會用多線程就行了，還管它有什麼用？在我看來，這個回答更扯淡。所謂知其然知其因此然，會用只是知其然，爲何用纔是知其因此然，只有達到知其然知其因此然的程度才能夠說是把一個知識點運用自如。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，分別創建程序模型，並經過多線程分別運行這幾個任務，那就簡單不少了。安全

二、建立線程的方式

比較常見的一個問題了，通常就是兩種：服務器

（1）繼承 Thread 類多線程

（2）實現 Runnable 接口

至於哪一個好，不用說確定是後者好，由於實現接口的方式比繼承類的方式更靈活，也能減小程序之間的耦合度，面向接口編程也是設計模式 6 大原則的核心。

三、start() 方法和 run() 方法的區別

只有調用了 start() 方法，纔會表現出多線程的特性，不一樣線程的 run() 方法裏面的代碼交替執行。若是隻是調用run() 方法，那麼代碼仍是同步執行的，必須等待一個線程的 run() 方法裏面的代碼所有執行完畢以後，另一個線程才能夠執行其run()方法裏面的代碼。

四、Runnable 接口和 Callable 接口的區別

有點深的問題了，也看出一個 Java 程序員學習知識的廣度。

Runnable 接口中的 run() 方法的返回值是 void，它作的事情只是純粹地去執行 run() 方法中的代碼而已；Callable接口中的 call() 方法是有返回值的，是一個泛型，和 Future、FutureTask 配合能夠用來獲取異步執行的結果。

這實際上是頗有用的一個特性，由於多線程相比單線程更難、更復雜的一個重要緣由就是由於多線程充滿着未知性，某條線程是否執行了？某條線程執行了多久？某條線程執行的時候咱們指望的數據是否已經賦值完畢？沒法得知，咱們能作的只是等待這條多線程的任務執行完畢而已。而 Callable+Future/FutureTask 卻能夠獲取多線程運行的結果，能夠在等待時間太長沒獲取到須要的數據的狀況下取消該線程的任務，真的是很是有用。

五、CyclicBarrier 和 CountDownLatch 的區別

兩個看上去有點像的類，都在 java.util.concurrent 下，均可以用來表示代碼運行到某個點上，兩者的區別在於：

（1）CyclicBarrier 的某個線程運行到某個點上以後，該線程即中止運行，直到全部的線程都到達了這個點，全部線程才從新運行；CountDownLatch 則不是，某線程運行到某個點上以後，只是給某個數值 -1 而已，該線程繼續運行

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

（3）CyclicBarrier 可重用，CountDownLatch 不可重用，計數值爲 0 該 CountDownLatch 就不可再用了

六、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。

七、什麼是線程安全

又是一個理論的問題，各式各樣的答案有不少，我給出一個我的認爲解釋的最好的：若是你的代碼在多線程下執行和在單線程下執行永遠都能得到同樣的結果，那麼你的代碼就是線程安全的。

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

（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 等都是線程非安全的類

八、Java中如何獲取到線程 dump 文件

死循環、死鎖、阻塞、頁面打開慢等問題，打線程 dump 是最好的解決問題的途徑。所謂線程 dump 也就是線程堆棧，獲取到線程堆棧有兩步：

（1）獲取到線程的 pid，能夠經過使用 jps 命令，在 Linux 環境下還可使用 ps -ef | grep java

（2）打印線程堆棧，能夠經過使用 jstack pid 命令，在Linux環境下還可使用 kill -3 pid

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

九、一個線程若是出現了運行時異常會怎麼樣

若是這個異常沒有被捕獲的話，這個線程就中止執行了。另外重要的一點是：若是這個線程持有某個某個對象的監視器，那麼這個對象監視器會被當即釋放

十、如何在兩個線程之間共享數據

經過在線程之間共享對象就能夠了，而後經過 wait/notify/notifyAll、await/signal/signalAll 進行喚起和等待，比方說阻塞隊列 BlockingQueue 就是爲線程之間共享數據而設計的

十一、sleep方法和wait方法有什麼區別

這個問題常問，sleep 方法和 wait 方法均可以用來放棄 CPU 必定的時間，不一樣點在於若是線程持有某個對象的監視器，sleep 方法不會放棄這個對象的監視器，wait 方法會放棄這個對象的監視器

十二、生產者消費者模型的做用是什麼

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

（1）經過平衡生產者的生產能力和消費者的消費能力來提高整個系統的運行效率，這是生產者消費者模型最重要的做用

（2）解耦，這是生產者消費者模型附帶的做用，解耦意味着生產者和消費者之間的聯繫少，聯繫越少越能夠獨自發展而不須要收到相互的制約

1三、ThreadLocal有什麼用

簡單說 ThreadLocal 就是一種以空間換時間的作法，在每一個 Thread 裏面維護了一個以開地址法實現的ThreadLocal.ThreadLocalMap，把數據進行隔離，數據不共享，天然就沒有線程安全方面的問題了

1四、爲何 wait() 方法和 notify()/notifyAll() 方法要在同步塊中被調用

這是 JDK 強制的，wait() 方法和 notify()/notifyAll() 方法在調用前都必須先得到對象的鎖

1五、wait() 方法和 notify()/notifyAll() 方法在放棄對象監視器時有什麼區別

wait() 方法和 notify()/notifyAll() 方法在放棄對象監視器的時候的區別在於：wait() 方法當即釋放對象監視器，notify()/notifyAll() 方法則會等待線程剩餘代碼執行完畢纔會放棄對象監視器。

1六、爲何要使用線程池

避免頻繁地建立和銷燬線程，達到線程對象的重用。另外，使用線程池還能夠根據項目靈活地控制併發的數目。

1七、怎麼檢測一個線程是否持有對象監視器

我也是在網上看到一道多線程面試題才知道有方法能夠判斷某個線程是否持有對象監視器：Thread 類提供了一個holdsLock(Object obj) 方法，當且僅當對象 obj 的監視器被某條線程持有的時候纔會返回 true，注意這是一個static 方法，這意味着某條線程指的是當前線程。

1八、synchronized 和 ReentrantLock 的區別

synchronized 是和 if、else、for、while 同樣的關鍵字，ReentrantLock 是類，這是兩者的本質區別。既然ReentrantLock 是類，那麼它就提供了比 synchronized 更多更靈活的特性，能夠被繼承、能夠有方法、能夠有各類各樣的類變量，ReentrantLock比 synchronized 的擴展性體如今幾點上：

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

（2）ReentrantLock 能夠獲取各類鎖的信息

（3）ReentrantLock 能夠靈活地實現多路通知

另外，兩者的鎖機制其實也是不同的。ReentrantLock 底層調用的是 Unsafe 的 park 方法加鎖，synchronized操做的應該是對象頭中mark word，這點我不能肯定。

1九、ConcurrentHashMap的併發度是什麼

ConcurrentHashMap 的併發度就是 segment 的大小，默認爲 16，這意味着最多同時能夠有 16 條線程操做ConcurrentHashMap，這也是 ConcurrentHashMap 對 Hashtable 的最大優點，任何狀況下，Hashtable 能同時有兩條線程獲取 Hashtable 中的數據嗎？

20、ReadWriteLock 是什麼

首先明確一下，不是說 ReentrantLock 很差，只是 ReentrantLock 某些時候有侷限。若是使用 ReentrantLock，可能自己是爲了防止線程 A 在寫數據、線程 B 在讀數據形成的數據不一致，但這樣，若是線程 C 在讀數據、線程 D 也在讀數據，讀數據是不會改變數據的，沒有必要加鎖，可是仍是加鎖了，下降了程序的性能。

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

2一、FutureTask 是什麼

這個其實前面有提到過，FutureTask 表示一個異步運算的任務。FutureTask 裏面能夠傳入一個 Callable 的具體實現類，能夠對這個異步運算的任務的結果進行等待獲取、判斷是否已經完成、取消任務等操做。固然，因爲FutureTask 也是 Runnable 接口的實現類，因此 FutureTask 也能夠放入線程池中。

2二、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高的線程的當前線程堆棧了。

2三、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：死鎖這篇文章裏面有，就是上面步驟的代碼實現。

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

若是線程是由於調用了 wait()、sleep() 或者 join() 方法而致使的阻塞，能夠中斷線程，而且經過拋出InterruptedException 來喚醒它；若是線程遇到了 IO 阻塞，無能爲力，由於 IO 是操做系統實現的，Java 代碼並無辦法直接接觸到操做系統。

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

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

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

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

2七、若是你提交任務時，線程池隊列已滿，這時會發生什麼

這裏區分一下：

若是使用的是無界隊列 LinkedBlockingQueue，也就是無界隊列的話，不要緊，繼續添加任務到阻塞隊列中等待執行，由於 LinkedBlockingQueue 能夠近乎認爲是一個無窮大的隊列，能夠無限存聽任務

若是使用的是有界隊列好比 ArrayBlockingQueue，任務首先會被添加到 ArrayBlockingQueue 中，ArrayBlockingQueue 滿了，會根據 maximumPoolSize 的值增長線程數量，若是增長了線程數量仍是處理不過來，ArrayBlockingQueue 繼續滿，那麼則會使用拒絕策略 RejectedExecutionHandler 處理滿了的任務，默認是 AbortPolicy

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

搶佔式。一個線程用完 CPU 以後，操做系統會根據線程優先級、線程飢餓狀況等數據算出一個總的優先級並分配下一個時間片給某個線程執行。

2九、Thread.sleep(0) 的做用是什麼

這個問題和上面那個問題是相關的，我就連在一塊兒了。因爲 Java 採用搶佔式的線程調度算法，所以可能會出現某條線程經常獲取到 CPU 控制權的狀況，爲了讓某些優先級比較低的線程也能獲取到 CPU 控制權，可使用Thread.sleep(0) 手動觸發一次操做系統分配時間片的操做，這也是平衡 CPU 控制權的一種操做。

30、什麼是自旋

不少 synchronized 裏面的代碼只是一些很簡單的代碼，執行時間很是快，此時等待的線程都加鎖多是一種不太值得的操做，由於線程阻塞涉及到用戶態和內核態切換的問題。既然 synchronized 裏面的代碼執行得很是快，不妨讓等待鎖的線程不要被阻塞，而是在 synchronized 的邊界作忙循環，這就是自旋。若是作了屢次忙循環發現尚未得到鎖，再阻塞，這樣多是一種更好的策略。

3一、什麼是 Java 內存模型

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

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

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

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

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

3二、什麼是 CAS

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

3三、什麼是樂觀鎖和悲觀鎖

（1）樂觀鎖：就像它的名字同樣，對於併發間操做產生的線程安全問題持樂觀狀態，樂觀鎖認爲競爭不老是會發生，所以它不須要持有鎖，將比較-替換這兩個動做做爲一個原子操做嘗試去修改內存中的變量，若是失敗則表示發生衝突，那麼就應該有相應的重試邏輯。

（2）悲觀鎖：仍是像它的名字同樣，對於併發間操做產生的線程安全問題持悲觀狀態，悲觀鎖認爲競爭老是會發生，所以每次對某資源進行操做時，都會持有一個獨佔的鎖，就像 synchronized，無論三七二十一，直接上了鎖就操做資源了。

3四、什麼是 AQS

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

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

AQS 定義了對雙向隊列全部的操做，而只開放了 tryLock 和 tryRelease 方法給開發者使用，開發者能夠根據本身的實現重寫 tryLock 和 tryRelease 方法，以實現本身的併發功能。

3五、單例模式的線程安全性

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

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

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

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

3六、Semaphore 有什麼做用

Semaphore 就是一個信號量，它的做用是限制某段代碼塊的併發數。Semaphore 有一個構造函數，能夠傳入一個 int 型整數 n，表示某段代碼最多隻有 n 個線程能夠訪問，若是超出了 n，那麼請等待，等到某個線程執行完畢這段代碼塊，下一個線程再進入。由此能夠看出若是 Semaphore 構造函數中傳入的 int 型整數 n=1，至關於變成了一個 synchronized 了。

3七、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 假設被翻譯成了三句彙編語句執行，一句彙編語句和其機器碼作對應，徹底可能執行完第一句，線程就切換了。

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

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

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

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

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

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

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

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