當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

面试-多线程进阶篇

發布時間：2023/12/18 编程问答 23 豆豆

生活随笔收集整理的這篇文章主要介紹了面试-多线程进阶篇小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

文章目錄

1、說說synchronized關鍵字的底層原理是什么
- - - synchronized 同步語句塊的情況
    - synchronized 修飾方法的的情況
    - 總結
2、什么是可重入性，為什么說 Synchronized 是可重入鎖？
3、說說自己是怎么使用 synchronized 關鍵字
4、構造方法可以使用 synchronized 關鍵字修飾么？
5、說說 JDK1.6 之后的 synchronized 關鍵字底層做了哪些優化，可以詳細介紹一下這些優化嗎
- - 談談 synchronized 和 ReentrantLock 的區別
  - - 兩者都是可重入鎖
    - synchronized 依賴于 JVM 而 ReentrantLock 依賴于 API
    - ReentrantLock 比 synchronized 增加了一些高級功能
6、volatile 關鍵字
- - CPU 緩存模型
  - 講一下 JMM(Java 內存模型)
  - 并發編程的三個重要特性
  - 說說 synchronized 關鍵字和 volatile 關鍵字的區別
7、ThreadLocal
- - ThreadLocal 簡介
  - ThreadLocal 示例
  - ThreadLocal 原理
  - ThreadLocal 內存泄露問題
8、線程池
- - 為什么要用線程池？
  - 實現 Runnable 接口和 Callable 接口的區別
  - 執行 execute()方法和 submit()方法的區別是什么呢？
  - 如何創建線程池
  - ThreadPoolExecutor 類分析
  - - `ThreadPoolExecutor`構造函數重要參數分析
    - `ThreadPoolExecutor` 飽和策略
  - 一個簡單的線程池 Demo
  - 線程池原理分析
9、Atomic 原子類
- - 介紹一下 Atomic 原子類
  - JUC 包中的原子類是哪 4 類?
  - 講講 AtomicInteger 的使用
  - 能不能給我簡單介紹一下 AtomicInteger 類的原理
10、AQS
- - AQS 介紹
  - AQS 原理分析
  - - AQS 原理概覽
    - AQS 對資源的共享方式
    - AQS 底層使用了模板方法模式
  - AQS 組件總結
11、用過 CountDownLatch 么？什么場景下用的？

1、說說synchronized關鍵字的底層原理是什么

synchronized 關鍵字解決的是多個線程之間訪問資源的同步性，synchronized關鍵字可以保證被它修飾的方法或者代碼塊在任意時刻只能有一個線程執行。

JDK1.6 對鎖的實現引入了大量的優化，如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減少鎖操作的開銷。

所以，你會發現目前的話，不論是各種開源框架還是 JDK 源碼都大量使用了 synchronized 關鍵字。

synchronized 關鍵字底層原理屬于 JVM 層面。

synchronized 同步語句塊的情況

public class SynchronizedDemo {public void method() {synchronized (this) {System.out.println("synchronized 代碼塊");}} }

通過 JDK 自帶的 javap 命令查看 SynchronizedDemo 類的相關字節碼信息：首先切換到類的對應目錄執行 javac SynchronizedDemo.java 命令生成編譯后的 .class 文件，然后執行javap -c -s -v -l SynchronizedDemo.class。

從上面我們可以看出：

synchronized 同步語句塊的實現使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代碼塊的開始位置，monitorexit 指令則指明同步代碼塊的結束位置。

當執行 monitorenter 指令時，線程試圖獲取鎖也就是獲取對象監視器 monitor 的持有權。

在 Java 虛擬機(HotSpot)中，Monitor 是基于 C++實現的，由ObjectMonitor (opens new window)實現的。每個對象中都內置了一個 ObjectMonitor對象。

另外，wait/notify等方法也依賴于monitor對象，這就是為什么只有在同步的塊或者方法中才能調用wait/notify等方法，否則會拋出java.lang.IllegalMonitorStateException的異常的原因。

在執行monitorenter時，會嘗試獲取對象的鎖，如果鎖的計數器為 0 則表示鎖可以被獲取，獲取后將鎖計數器設為 1 也就是加 1。

在執行 monitorexit 指令后，將鎖計數器設為 0，表明鎖被釋放。如果獲取對象鎖失敗，那當前線程就要阻塞等待，直到鎖被另外一個線程釋放為止。

synchronized 修飾方法的的情況

public class SynchronizedDemo2 {public synchronized void method() {System.out.println("synchronized 方法");} }

synchronized 修飾的方法并沒有 monitorenter 指令和 monitorexit 指令，取得代之的確實是 ACC_SYNCHRONIZED 標識，該標識指明了該方法是一個同步方法。JVM 通過該 ACC_SYNCHRONIZED 訪問標志來辨別一個方法是否聲明為同步方法，從而執行相應的同步調用。

總結

synchronized 修飾的方法并沒有 monitorenter 指令和 monitorexit 指令，取得代之的確實是 ACC_SYNCHRONIZED 標識，該標識指明了該方法是一個同步方法。

不過兩者的本質都是對對象監視器 monitor 的獲取。

2、什么是可重入性，為什么說 Synchronized 是可重入鎖？

可重入性是鎖的一個基本要求，是為了解決自己鎖死自己的情況。比如一個類中的同步方法調用另一個同步方法，假如 Synchronized 不支持重入，進入 method2 方法時當前線程獲得鎖， method2 方法里面執行 method1 時當前線程又要去嘗試獲取鎖，這時如果不支持重入，它就要等釋放，把自己阻塞，導致自己鎖死自己。

對 Synchronized 來說，可重入性是顯而易見的，剛才提到，在執行 monitorenter 指令時，如果這個對象沒有鎖定，或者當前線程已經擁有了這個對象的鎖（而不是已擁有了鎖則不能繼續獲取），就把鎖的計數器 +1，其實本質上就通過這種方式實現了可重入性。

3、說說自己是怎么使用 synchronized 關鍵字

synchronized 關鍵字最主要的三種使用方式：

1.修飾實例方法: 作用于當前對象實例加鎖，進入同步代碼前要獲得 當前對象實例的鎖

synchronized void method() {//業務代碼 }

2.修飾靜態方法: 也就是給當前類加鎖，會作用于類的所有對象實例，進入同步代碼前要獲得 當前 class 的鎖。因為靜態成員不屬于任何一個實例對象，是類成員（ static 表明這是該類的一個靜態資源，不管 new 了多少個對象，只有一份）。所以，如果一個線程 A 調用一個實例對象的非靜態 synchronized 方法，而線程 B 需要調用這個實例對象所屬類的靜態 synchronized 方法，是允許的，不會發生互斥現象，因為訪問靜態 synchronized 方法占用的鎖是當前類的鎖，而訪問非靜態 synchronized 方法占用的鎖是當前實例對象鎖。

synchronized static void method() {//業務代碼 }

3.修飾代碼塊 ：指定加鎖對象，對給定對象/類加鎖。synchronized(this|object) 表示進入同步代碼庫前要獲得給定對象的鎖。synchronized(類.class) 表示進入同步代碼前要獲得 當前 class 的鎖

synchronized(this) {//業務代碼 }

總結：

synchronized 關鍵字加到 static 靜態方法和 synchronized(class) 代碼塊上都是是給 Class 類上鎖。
synchronized 關鍵字加到實例方法上是給對象實例上鎖。
盡量不要使用 synchronized(String a) 因為 JVM 中，字符串常量池具有緩存功能！

下面我以一個常見的面試題為例講解一下 synchronized 關鍵字的具體使用。

面試中面試官經常會說：“單例模式了解嗎？來給我手寫一下！給我解釋一下雙重檢驗鎖方式實現單例模式的原理唄！”

雙重校驗鎖實現對象單例（線程安全）

public class Singleton {private volatile static Singleton uniqueInstance;private Singleton() {}public static Singleton getUniqueInstance() {//先判斷對象是否已經實例過，沒有實例化過才進入加鎖代碼if (uniqueInstance == null) {//類對象加鎖synchronized (Singleton.class) {if (uniqueInstance == null) {uniqueInstance = new Singleton();}}}return uniqueInstance;} }

另外，需要注意 uniqueInstance 采用 volatile 關鍵字修飾也是很有必要。

uniqueInstance 采用 volatile 關鍵字修飾也是很有必要的， uniqueInstance = new Singleton(); 這段代碼其實是分為三步執行：

為 uniqueInstance 分配內存空間

初始化 uniqueInstance

將 uniqueInstance 指向分配的內存地址

但是由于 JVM 具有指令重排的特性，執行順序有可能變成 1->3->2。指令重排在單線程環境下不會出現問題，但是在多線程環境下會導致一個線程獲得還沒有初始化的實例。例如，線程 T1 執行了 1 和 3，此時 T2 調用 getUniqueInstance() 后發現 uniqueInstance 不為空，因此返回 uniqueInstance，但此時 uniqueInstance 還未被初始化。

使用 volatile 可以禁止 JVM 的指令重排，保證在多線程環境下也能正常運行。

4、構造方法可以使用 synchronized 關鍵字修飾么？

先說結論：構造方法不能使用 synchronized 關鍵字修飾。

構造方法本身就屬于線程安全的，不存在同步的構造方法一說。

5、說說 JDK1.6 之后的 synchronized 關鍵字底層做了哪些優化，可以詳細介紹一下這些優化嗎

JDK1.6 對鎖的實現引入了大量的優化，如偏向鎖、輕量級鎖、自旋鎖、適應性自旋鎖、鎖消除、鎖粗化等技術來減少鎖操作的開銷。

鎖主要存在四種狀態，依次是：無鎖狀態、偏向鎖狀態、輕量級鎖狀態、重量級鎖狀態，他們會隨著競爭的激烈而逐漸升級。注意鎖可以升級不可降級，這種策略是為了提高獲得鎖和釋放鎖的效率。

關于這幾種優化的詳細信息可以查看下面這篇文章：Java6 及以上版本對 synchronized 的優化

談談 synchronized 和 ReentrantLock 的區別

兩者都是可重入鎖

“可重入鎖” 指的是自己可以再次獲取自己的內部鎖。比如一個線程獲得了某個對象的鎖，此時這個對象鎖還沒有釋放，當其再次想要獲取這個對象的鎖的時候還是可以獲取的，如果不可鎖重入的話，就會造成死鎖。同一個線程每次獲取鎖，鎖的計數器都自增 1，所以要等到鎖的計數器下降為 0 時才能釋放鎖。

synchronized 依賴于 JVM 而 ReentrantLock 依賴于 API

synchronized 是依賴于 JVM 實現的，前面我們也講到了虛擬機團隊在 JDK1.6 為 synchronized 關鍵字進行了很多優化，但是這些優化都是在虛擬機層面實現的，并沒有直接暴露給我們。ReentrantLock 是 JDK 層面實現的（也就是 API 層面，需要 lock() 和 unlock() 方法配合 try/finally 語句塊來完成），所以我們可以通過查看它的源代碼，來看它是如何實現的。

ReentrantLock 比 synchronized 增加了一些高級功能

相比synchronized，ReentrantLock增加了一些高級功能。主要來說主要有三點：

等待可中斷 : ReentrantLock提供了一種能夠中斷等待鎖的線程的機制，通過 lock.lockInterruptibly() 來實現這個機制。也就是說正在等待的線程可以選擇放棄等待，改為處理其他事情。
可實現公平鎖 : ReentrantLock可以指定是公平鎖還是非公平鎖。而synchronized只能是非公平鎖。所謂的公平鎖就是先等待的線程先獲得鎖。ReentrantLock默認情況是非公平的，可以通過 ReentrantLock類的ReentrantLock(boolean fair)構造方法來制定是否是公平的。
可實現選擇性通知（鎖可以綁定多個條件）: synchronized關鍵字與wait()和notify()/notifyAll()方法相結合可以實現等待/通知機制。ReentrantLock類當然也可以實現，但是需要借助于Condition接口與newCondition()方法。

Condition是 JDK1.5 之后才有的，它具有很好的靈活性，比如可以實現多路通知功能也就是在一個Lock對象中可以創建多個Condition實例（即對象監視器），線程對象可以注冊在指定的Condition中，從而可以有選擇性的進行線程通知，在調度線程上更加靈活。在使用notify()/notifyAll()方法進行通知時，被通知的線程是由 JVM 選擇的，用ReentrantLock類結合Condition實例可以實現“選擇性通知” ，這個功能非常重要，而且是 Condition 接口默認提供的。而synchronized關鍵字就相當于整個 Lock 對象中只有一個Condition實例，所有的線程都注冊在它一個身上。如果執行notifyAll()方法的話就會通知所有處于等待狀態的線程這樣會造成很大的效率問題，而Condition實例的signalAll()方法只會喚醒注冊在該Condition實例中的所有等待線程。

如果你想使用上述功能，那么選擇 ReentrantLock 是一個不錯的選擇。性能已不是選擇標準

6、volatile 關鍵字

我們先要從 CPU 緩存模型 說起！

CPU 緩存模型

為什么要弄一個 CPU 高速緩存呢？

類比我們開發網站后臺系統使用的緩存（比如 Redis）是為了解決程序處理速度和訪問常規關系型數據庫速度不對等的問題。 CPU 緩存則是為了解決 CPU 處理速度和內存處理速度不對等的問題。

我們甚至可以把 內存可以看作外存的高速緩存，程序運行的時候我們把外存的數據復制到內存，由于內存的處理速度遠遠高于外存，這樣提高了處理速度。

總結：CPU Cache 緩存的是內存數據用于解決 CPU 處理速度和內存不匹配的問題，內存緩存的是硬盤數據用于解決硬盤訪問速度過慢的問題。

為了更好地理解，我畫了一個簡單的 CPU Cache 示意圖如下（實際上，現代的 CPU Cache 通常分為三層，分別叫 L1,L2,L3 Cache）:

CPU Cache 的工作方式：

先復制一份數據到 CPU Cache 中，當 CPU 需要用到的時候就可以直接從 CPU Cache 中讀取數據，當運算完成后，再將運算得到的數據寫回 Main Memory 中。但是，這樣存在 內存緩存不一致性的問題 ！比如我執行一個 i++操作的話，如果兩個線程同時執行的話，假設兩個線程從 CPU Cache 中讀取的 i=1，兩個線程做了 1++運算完之后再寫回 Main Memory 之后 i=2，而正確結果應該是 i=3。

CPU 為了解決內存緩存不一致性問題可以通過制定緩存一致協議或者其他手段來解決。

講一下 JMM(Java 內存模型)

在 JDK1.2 之前，Java 的內存模型實現總是從主存（即共享內存）讀取變量，是不需要進行特別的注意的。而在當前的 Java 內存模型下，線程可以把變量保存本地內存（比如機器的寄存器）中，而不是直接在主存中進行讀寫。這就可能造成一個線程在主存中修改了一個變量的值，而另外一個線程還繼續使用它在寄存器中的變量值的拷貝，造成數據的不一致。

要解決這個問題，就需要把變量聲明為 volatile ，這就指示 JVM，這個變量是共享且不穩定的，每次使用它都到主存中進行讀取。

所以，volatile 關鍵字除了防止 JVM 的指令重排，還有一個重要的作用就是保證變量的可見性。

并發編程的三個重要特性

原子性 : 一個的操作或者多次操作，要么所有的操作全部都得到執行并且不會收到任何因素的干擾而中斷，要么所有的操作都執行，要么都不執行。synchronized 可以保證代碼片段的原子性。

可見性 ：當一個線程對共享變量進行了修改，那么另外的線程都是立即可以看到修改后的最新值。volatile 關鍵字可以保證共享變量的可見性。

有序性 ：代碼在執行的過程中的先后順序，Java 在編譯器以及運行期間的優化，代碼的執行順序未必就是編寫代碼時候的順序。volatile 關鍵字可以禁止指令進行重排序優化。

說說 synchronized 關鍵字和 volatile 關鍵字的區別

synchronized 關鍵字和 volatile 關鍵字是兩個互補的存在，而不是對立的存在！

volatile 關鍵字是線程同步的輕量級實現，所以 volatile性能肯定比synchronized關鍵字要好 。但是 volatile 關鍵字只能用于變量而 synchronized 關鍵字可以修飾方法以及代碼塊 。
volatile 關鍵字能保證數據的可見性，但不能保證數據的原子性。synchronized 關鍵字兩者都能保證。
volatile關鍵字主要用于解決變量在多個線程之間的可見性，而 synchronized 關鍵字解決的是多個線程之間訪問資源的同步性。

7、ThreadLocal

ThreadLocal 簡介

通常情況下，我們創建的變量是可以被任何一個線程訪問并修改的。如果想實現每一個線程都有自己的專屬本地變量該如何解決呢？ JDK 中提供的ThreadLocal類正是為了解決這樣的問題。 ThreadLocal類主要解決的就是讓每個線程綁定自己的值，可以將ThreadLocal類形象的比喻成存放數據的盒子，盒子中可以存儲每個線程的私有數據。

如果你創建了一個ThreadLocal變量，那么訪問這個變量的每個線程都會有這個變量的本地副本，這也是ThreadLocal變量名的由來。他們可以使用 get（）和 set（）方法來獲取默認值或將其值更改為當前線程所存的副本的值，從而避免了線程安全問題。

再舉個簡單的例子：

比如有兩個人去寶屋收集寶物，這兩個共用一個袋子的話肯定會產生爭執，但是給他們兩個人每個人分配一個袋子的話就不會出現這樣的問題。如果把這兩個人比作線程的話，那么 ThreadLocal 就是用來避免這兩個線程競爭的。

ThreadLocal 示例

相信看了上面的解釋，大家已經搞懂 ThreadLocal 類是個什么東西了。

import java.text.SimpleDateFormat; import java.util.Random;public class ThreadLocalExample implements Runnable{// SimpleDateFormat 不是線程安全的，所以每個線程都要有自己獨立的副本private static final ThreadLocal<SimpleDateFormat> formatter = ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyyMMdd HHmm"));public static void main(String[] args) throws InterruptedException {ThreadLocalExample obj = new ThreadLocalExample();for(int i=0 ; i<10; i++){Thread t = new Thread(obj, ""+i);Thread.sleep(new Random().nextInt(1000));t.start();}}@Overridepublic void run() {System.out.println("Thread Name= "+Thread.currentThread().getName()+" default Formatter = "+formatter.get().toPattern());try {Thread.sleep(new Random().nextInt(1000));} catch (InterruptedException e) {e.printStackTrace();}//formatter pattern is changed here by thread, but it won't reflect to other threadsformatter.set(new SimpleDateFormat());System.out.println("Thread Name= "+Thread.currentThread().getName()+" formatter = "+formatter.get().toPattern());}}

Output:

Thread Name= 0 default Formatter = yyyyMMdd HHmm Thread Name= 0 formatter = yy-M-d ah:mm Thread Name= 1 default Formatter = yyyyMMdd HHmm Thread Name= 2 default Formatter = yyyyMMdd HHmm Thread Name= 1 formatter = yy-M-d ah:mm Thread Name= 3 default Formatter = yyyyMMdd HHmm Thread Name= 2 formatter = yy-M-d ah:mm Thread Name= 4 default Formatter = yyyyMMdd HHmm Thread Name= 3 formatter = yy-M-d ah:mm Thread Name= 4 formatter = yy-M-d ah:mm Thread Name= 5 default Formatter = yyyyMMdd HHmm Thread Name= 5 formatter = yy-M-d ah:mm Thread Name= 6 default Formatter = yyyyMMdd HHmm Thread Name= 6 formatter = yy-M-d ah:mm Thread Name= 7 default Formatter = yyyyMMdd HHmm Thread Name= 7 formatter = yy-M-d ah:mm Thread Name= 8 default Formatter = yyyyMMdd HHmm Thread Name= 9 default Formatter = yyyyMMdd HHmm Thread Name= 8 formatter = yy-M-d ah:mm Thread Name= 9 formatter = yy-M-d ah:mm

從輸出中可以看出，Thread-0 已經改變了 formatter 的值，但仍然是 thread-2 默認格式化程序與初始化值相同，其他線程也一樣。

上面有一段代碼用到了創建 ThreadLocal 變量的那段代碼用到了 Java8 的知識，它等于下面這段代碼，如果你寫了下面這段代碼的話，IDEA 會提示你轉換為 Java8 的格式(IDEA 真的不錯！)。因為 ThreadLocal 類在 Java 8 中擴展，使用一個新的方法withInitial()，將 Supplier 功能接口作為參數。

private static final ThreadLocal<SimpleDateFormat> formatter = new ThreadLocal<SimpleDateFormat>(){@Overrideprotected SimpleDateFormat initialValue(){return new SimpleDateFormat("yyyyMMdd HHmm");} };

ThreadLocal 原理

從 Thread類源代碼入手。

public class Thread implements Runnable {//......//與此線程有關的ThreadLocal值。由ThreadLocal類維護ThreadLocal.ThreadLocalMap threadLocals = null;//與此線程有關的InheritableThreadLocal值。由InheritableThreadLocal類維護ThreadLocal.ThreadLocalMap inheritableThreadLocals = null;//...... }

從上面Thread類源代碼可以看出Thread 類中有一個 threadLocals 和一個 inheritableThreadLocals 變量，它們都是 ThreadLocalMap 類型的變量,我們可以把 ThreadLocalMap 理解為ThreadLocal 類實現的定制化的 HashMap。默認情況下這兩個變量都是 null，只有當前線程調用 ThreadLocal 類的 set或get方法時才創建它們，實際上調用這兩個方法的時候，我們調用的是ThreadLocalMap類對應的 get()、set()方法。

ThreadLocal類的set()方法

public void set(T value) {Thread t = Thread.currentThread();ThreadLocalMap map = getMap(t);if (map != null)map.set(this, value);elsecreateMap(t, value); } ThreadLocalMap getMap(Thread t) {return t.threadLocals; }

通過上面這些內容，我們足以通過猜測得出結論：最終的變量是放在了當前線程的 ThreadLocalMap 中，并不是存在 ThreadLocal 上，ThreadLocal 可以理解為只是ThreadLocalMap的封裝，傳遞了變量值。 ThrealLocal 類中可以通過Thread.currentThread()獲取到當前線程對象后，直接通過getMap(Thread t)可以訪問到該線程的ThreadLocalMap對象。

每個Thread中都具備一個ThreadLocalMap，而ThreadLocalMap可以存儲以ThreadLocal為 key ，Object 對象為 value 的鍵值對。

ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {//...... }

比如我們在同一個線程中聲明了兩個 ThreadLocal 對象的話，會使用 Thread內部都是使用僅有那個ThreadLocalMap 存放數據的，ThreadLocalMap的 key 就是 ThreadLocal對象，value 就是 ThreadLocal 對象調用set方法設置的值。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-2iDNv9rp-1638524593733)(/assets/img/threadlocal數據結構.8dacaa3c.png)]

ThreadLocalMap是ThreadLocal的靜態內部類。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-6Da8kdxe-1638524593734)(/assets/img/ThreadLocal內部類.2f07220b.png)]

ThreadLocal 內存泄露問題

ThreadLocalMap 中使用的 key 為 ThreadLocal 的弱引用,而 value 是強引用。所以，如果 ThreadLocal 沒有被外部強引用的情況下，在垃圾回收的時候，key 會被清理掉，而 value 不會被清理掉。這樣一來，ThreadLocalMap 中就會出現 key 為 null 的 Entry。假如我們不做任何措施的話，value 永遠無法被 GC 回收，這個時候就可能會產生內存泄露。ThreadLocalMap 實現中已經考慮了這種情況，在調用 set()、get()、remove() 方法的時候，會清理掉 key 為 null 的記錄。使用完 ThreadLocal方法后最好手動調用remove()方法

static class Entry extends WeakReference<ThreadLocal<?>> {/** The value associated with this ThreadLocal. */Object value;Entry(ThreadLocal<?> k, Object v) {super(k);value = v;} }

弱引用介紹：

如果一個對象只具有弱引用，那就類似于可有可無的生活用品。弱引用與軟引用的區別在于：只具有弱引用的對象擁有更短暫的生命周期。在垃圾回收器線程掃描它所管轄的內存區域的過程中，一旦發現了只具有弱引用的對象，不管當前內存空間足夠與否，都會回收它的內存。不過，由于垃圾回收器是一個優先級很低的線程，因此不一定會很快發現那些只具有弱引用的對象。

弱引用可以和一個引用隊列（ReferenceQueue）聯合使用，如果弱引用所引用的對象被垃圾回收，Java 虛擬機就會把這個弱引用加入到與之關聯的引用隊列中。

8、線程池

為什么要用線程池？

池化技術想必大家已經屢見不鮮了，線程池、數據庫連接池、Http 連接池等等都是對這個思想的應用。池化技術的思想主要是為了減少每次獲取資源的消耗，提高對資源的利用率。

線程池提供了一種限制和管理資源（包括執行一個任務）。每個線程池還維護一些基本統計信息，例如已完成任務的數量。

這里借用《Java 并發編程的藝術》提到的來說一下使用線程池的好處：

降低資源消耗。通過重復利用已創建的線程降低線程創建和銷毀造成的消耗。
提高響應速度。當任務到達時，任務可以不需要等到線程創建就能立即執行。
提高線程的可管理性。線程是稀缺資源，如果無限制的創建，不僅會消耗系統資源，還會降低系統的穩定性，使用線程池可以進行統一的分配，調優和監控。

實現 Runnable 接口和 Callable 接口的區別

Runnable自 Java 1.0 以來一直存在，但Callable僅在 Java 1.5 中引入,目的就是為了來處理Runnable不支持的用例。**Callable 會返回結果或拋出檢查異常，所以，如果任務不需要返回結果或拋出異常推薦使用 Runnable 接口 ，這樣代碼看起來會更加簡潔。

工具類 Executors 可以實現將 Runnable 對象轉換成 Callable 對象。（Executors.callable(Runnable task) 或 Executors.callable(Runnable task, Object result)）。

Runnable.java @FunctionalInterface public interface Runnable {/*** 被線程執行，沒有返回值也無法拋出異常*/public abstract void run(); } Callable.java @FunctionalInterface public interface Callable<V> {/*** 計算結果，或在無法這樣做時拋出異常。* @return 計算得出的結果* @throws 如果無法計算結果，則拋出異常*/V call() throws Exception; }

執行 execute()方法和 submit()方法的區別是什么呢？

execute()方法用于提交不需要返回值的任務，所以無法判斷任務是否被線程池執行成功與否；

submit()方法用于提交需要返回值的任務。線程池會返回一個 Future 類型的對象，通過這個 Future 對象可以判斷任務是否執行成功，并且可以通過 Future 的 get()方法來獲取返回值，get()方法會阻塞當前線程直到任務完成，而使用 get(long timeout，TimeUnit unit)方法則會阻塞當前線程一段時間后立即返回，這時候有可能任務沒有執行完。

我們以 AbstractExecutorService 接口 中的一個 submit 方法為例子來看看源代碼：

public Future<?> submit(Runnable task) {if (task == null) throw new NullPointerException();RunnableFuture<Void> ftask = newTaskFor(task, null);execute(ftask);return ftask; }

上面方法調用的 newTaskFor 方法返回了一個 FutureTask 對象。

protected <T> RunnableFuture<T> newTaskFor(Runnable runnable, T value) {return new FutureTask<T>(runnable, value); }

我們再來看看execute()方法：

public void execute(Runnable command) {... }

如何創建線程池

《阿里巴巴 Java 開發手冊》中強制線程池不允許使用 Executors 去創建，而是通過 ThreadPoolExecutor 的方式，這樣的處理方式讓寫的同學更加明確線程池的運行規則，規避資源耗盡的風險

Executors 返回線程池對象的弊端如下：

FixedThreadPool 和 SingleThreadExecutor ：允許請求的隊列長度為 Integer.MAX_VALUE ，可能堆積大量的請求，從而導致 OOM。
CachedThreadPool 和 ScheduledThreadPool ：允許創建的線程數量為 Integer.MAX_VALUE ，可能會創建大量線程，從而導致 OOM。

方式一：通過構造方法實現

方式二：通過 Executor 框架的工具類 Executors 來實現

我們可以創建三種類型的 ThreadPoolExecutor：

FixedThreadPool ：該方法返回一個固定線程數量的線程池。該線程池中的線程數量始終不變。當有一個新的任務提交時，線程池中若有空閑線程，則立即執行。若沒有，則新的任務會被暫存在一個任務隊列中，待有線程空閑時，便處理在任務隊列中的任務。
SingleThreadExecutor： 方法返回一個只有一個線程的線程池。若多余一個任務被提交到該線程池，任務會被保存在一個任務隊列中，待線程空閑，按先入先出的順序執行隊列中的任務。
CachedThreadPool： 該方法返回一個可根據實際情況調整線程數量的線程池。線程池的線程數量不確定，但若有空閑線程可以復用，則會優先使用可復用的線程。若所有線程均在工作，又有新的任務提交，則會創建新的線程處理任務。所有線程在當前任務執行完畢后，將返回線程池進行復用。

對應 Executors 工具類中的方法如圖所示：

ThreadPoolExecutor 類分析

ThreadPoolExecutor 類中提供的四個構造方法。我們來看最長的那個，其余三個都是在這個構造方法的基礎上產生（其他幾個構造方法說白點都是給定某些默認參數的構造方法比如默認制定拒絕策略是什么），這里就不貼代碼講了，比較簡單。

/*** 用給定的初始參數創建一個新的ThreadPoolExecutor。*/ public ThreadPoolExecutor(int corePoolSize,int maximumPoolSize,long keepAliveTime,TimeUnit unit,BlockingQueue<Runnable> workQueue,ThreadFactory threadFactory,RejectedExecutionHandler handler) {if (corePoolSize < 0 ||maximumPoolSize <= 0 ||maximumPoolSize < corePoolSize ||keepAliveTime < 0)throw new IllegalArgumentException();if (workQueue == null || threadFactory == null || handler == null)throw new NullPointerException();this.corePoolSize = corePoolSize;this.maximumPoolSize = maximumPoolSize;this.workQueue = workQueue;this.keepAliveTime = unit.toNanos(keepAliveTime);this.threadFactory = threadFactory;this.handler = handler; }

下面這些對創建非常重要，在后面使用線程池的過程中你一定會用到！所以，務必拿著小本本記清楚。

ThreadPoolExecutor構造函數重要參數分析

ThreadPoolExecutor 3 個最重要的參數：

corePoolSize : 核心線程數定義了最小可以同時運行的線程數量。
maximumPoolSize : 當隊列中存放的任務達到隊列容量的時候，當前可以同時運行的線程數量變為最大線程數。
workQueue: 當新任務來的時候會先判斷當前運行的線程數量是否達到核心線程數，如果達到的話，新任務就會被存放在隊列中。

ThreadPoolExecutor其他常見參數:

keepAliveTime:當線程池中的線程數量大于 corePoolSize 的時候，如果這時沒有新的任務提交，核心線程外的線程不會立即銷毀，而是會等待，直到等待的時間超過了 keepAliveTime才會被回收銷毀；

unit : keepAliveTime 參數的時間單位。

threadFactory :executor 創建新線程的時候會用到。

handler :飽和策略。關于飽和策略下面單獨介紹一下。

ThreadPoolExecutor 飽和策略

ThreadPoolExecutor 飽和策略定義:

如果當前同時運行的線程數量達到最大線程數量并且隊列也已經被放滿了任務時，ThreadPoolTaskExecutor 定義一些策略:

ThreadPoolExecutor.AbortPolicy： 拋出 RejectedExecutionException來拒絕新任務的處理。
ThreadPoolExecutor.CallerRunsPolicy： 調用執行自己的線程運行任務，也就是直接在調用execute方法的線程中運行(run)被拒絕的任務，如果執行程序已關閉，則會丟棄該任務。因此這種策略會降低對于新任務提交速度，影響程序的整體性能。如果您的應用程序可以承受此延遲并且你要求任何一個任務請求都要被執行的話，你可以選擇這個策略。
ThreadPoolExecutor.DiscardPolicy： 不處理新任務，直接丟棄掉。
ThreadPoolExecutor.DiscardOldestPolicy： 此策略將丟棄最早的未處理的任務請求。

舉個例子： Spring 通過 ThreadPoolTaskExecutor 或者我們直接通過 ThreadPoolExecutor 的構造函數創建線程池的時候，當我們不指定 RejectedExecutionHandler 飽和策略的話來配置線程池的時候默認使用的是 ThreadPoolExecutor.AbortPolicy。在默認情況下，ThreadPoolExecutor 將拋出 RejectedExecutionException 來拒絕新來的任務，這代表你將丟失對這個任務的處理。對于可伸縮的應用程序，建議使用 ThreadPoolExecutor.CallerRunsPolicy。當最大池被填滿時，此策略為我們提供可伸縮隊列。（這個直接查看 ThreadPoolExecutor 的構造函數源碼就可以看出，比較簡單的原因，這里就不貼代碼了）

一個簡單的線程池 Demo

為了讓大家更清楚上面的面試題中的一些概念，我寫了一個簡單的線程池 Demo。

首先創建一個 Runnable 接口的實現類（當然也可以是 Callable 接口，我們上面也說了兩者的區別。）

MyRunnable.java import java.util.Date;/*** 這是一個簡單的Runnable類，需要大約5秒鐘來執行其任務。* @author shuang.kou*/ public class MyRunnable implements Runnable {private String command;public MyRunnable(String s) {this.command = s;}@Overridepublic void run() {System.out.println(Thread.currentThread().getName() + " Start. Time = " + new Date());processCommand();System.out.println(Thread.currentThread().getName() + " End. Time = " + new Date());}private void processCommand() {try {Thread.sleep(5000);} catch (InterruptedException e) {e.printStackTrace();}}@Overridepublic String toString() {return this.command;} }

編寫測試程序，我們這里以阿里巴巴推薦的使用 ThreadPoolExecutor 構造函數自定義參數的方式來創建線程池。

ThreadPoolExecutorDemo.java import java.util.concurrent.ArrayBlockingQueue; import java.util.concurrent.ThreadPoolExecutor; import java.util.concurrent.TimeUnit;public class ThreadPoolExecutorDemo {private static final int CORE_POOL_SIZE = 5;private static final int MAX_POOL_SIZE = 10;private static final int QUEUE_CAPACITY = 100;private static final Long KEEP_ALIVE_TIME = 1L;public static void main(String[] args) {//使用阿里巴巴推薦的創建線程池的方式//通過ThreadPoolExecutor構造函數自定義參數創建ThreadPoolExecutor executor = new ThreadPoolExecutor(CORE_POOL_SIZE,MAX_POOL_SIZE,KEEP_ALIVE_TIME,TimeUnit.SECONDS,new ArrayBlockingQueue<>(QUEUE_CAPACITY),new ThreadPoolExecutor.CallerRunsPolicy());for (int i = 0; i < 10; i++) {//創建WorkerThread對象（WorkerThread類實現了Runnable 接口）Runnable worker = new MyRunnable("" + i);//執行Runnableexecutor.execute(worker);}//終止線程池executor.shutdown();while (!executor.isTerminated()) {}System.out.println("Finished all threads");} }

可以看到我們上面的代碼指定了：

corePoolSize: 核心線程數為 5。

maximumPoolSize ：最大線程數 10

keepAliveTime : 等待時間為 1L。

unit: 等待時間的單位為 TimeUnit.SECONDS。

workQueue：任務隊列為 ArrayBlockingQueue，并且容量為 100;

handler:飽和策略為 CallerRunsPolicy。

Output：

pool-1-thread-3 Start. Time = Sun Apr 12 11:14:37 CST 2020 pool-1-thread-5 Start. Time = Sun Apr 12 11:14:37 CST 2020 pool-1-thread-2 Start. Time = Sun Apr 12 11:14:37 CST 2020 pool-1-thread-1 Start. Time = Sun Apr 12 11:14:37 CST 2020 pool-1-thread-4 Start. Time = Sun Apr 12 11:14:37 CST 2020 pool-1-thread-3 End. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-4 End. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-1 End. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-5 End. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-1 Start. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-2 End. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-5 Start. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-4 Start. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-3 Start. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-2 Start. Time = Sun Apr 12 11:14:42 CST 2020 pool-1-thread-1 End. Time = Sun Apr 12 11:14:47 CST 2020 pool-1-thread-4 End. Time = Sun Apr 12 11:14:47 CST 2020 pool-1-thread-5 End. Time = Sun Apr 12 11:14:47 CST 2020 pool-1-thread-3 End. Time = Sun Apr 12 11:14:47 CST 2020 pool-1-thread-2 End. Time = Sun Apr 12 11:14:47 CST 2020

線程池原理分析

承接 4.6 節，我們通過代碼輸出結果可以看出：線程池首先會先執行 5 個任務，然后這些任務有任務被執行完的話，就會去拿新的任務執行。 大家可以先通過上面講解的內容，分析一下到底是咋回事？（自己獨立思考一會）

現在，我們就分析上面的輸出內容來簡單分析一下線程池原理。

為了搞懂線程池的原理，我們需要首先分析一下 execute方法。 在 4.6 節中的 Demo 中我們使用 executor.execute(worker)來提交一個任務到線程池中去，這個方法非常重要，下面我們來看看它的源碼：

// 存放線程池的運行狀態 (runState) 和線程池內有效線程的數量 (workerCount) private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));private static int workerCountOf(int c) {return c & CAPACITY; }private final BlockingQueue<Runnable> workQueue;public void execute(Runnable command) {// 如果任務為null，則拋出異常。if (command == null)throw new NullPointerException();// ctl 中保存的線程池當前的一些狀態信息int c = ctl.get();// 下面會涉及到 3 步操作// 1.首先判斷當前線程池中執行的任務數量是否小于 corePoolSize// 如果小于的話，通過addWorker(command, true)新建一個線程，并將任務(command)添加到該線程中；然后，啟動該線程從而執行任務。if (workerCountOf(c) < corePoolSize) {if (addWorker(command, true))return;c = ctl.get();}// 2.如果當前執行的任務數量大于等于 corePoolSize 的時候就會走到這里// 通過 isRunning 方法判斷線程池狀態，線程池處于 RUNNING 狀態才會被并且隊列可以加入任務，該任務才會被加入進去if (isRunning(c) && workQueue.offer(command)) {int recheck = ctl.get();// 再次獲取線程池狀態，如果線程池狀態不是 RUNNING 狀態就需要從任務隊列中移除任務，并嘗試判斷線程是否全部執行完畢。同時執行拒絕策略。if (!isRunning(recheck) && remove(command))reject(command);// 如果當前線程池為空就新創建一個線程并執行。else if (workerCountOf(recheck) == 0)addWorker(null, false);}//3. 通過addWorker(command, false)新建一個線程，并將任務(command)添加到該線程中；然后，啟動該線程從而執行任務。//如果addWorker(command, false)執行失敗，則通過reject()執行相應的拒絕策略的內容。else if (!addWorker(command, false))reject(command); }

通過下圖可以更好的對上面這 3 步做一個展示，下圖是我為了省事直接從網上找到，原地址不明。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-sAPFnSYJ-1638524593736)(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAn8AAAETCAMAAABwTpB1AAAABGdBTUEAALGPC/xhBQAAAAFzUkdCAK7OHOkAAAIuUExURf///1qq8oS/9c/m+yOH4b3d+uDv/SaP7gu+yHzKYqPQ+O/3/pHD8O36+87m+0qi8cnx8/L4/keHwHTa4EXO1bTr7vf9/fj7/tz29/f7/vT5/vX786jG4Zjj6Mjw847F9vr8/zTJ0YfB9vP8/Oz46LXhppvXiDGV7zCP49fvz3jb4C2T7/z+/4y02Pj89vb6/oDd4vn+/hnCzNbp+eLz3TB4uHWl0Nvt/MjpvUCd8Pv9//n9+G+19PD7/Pz++8Lg+jWX7/P5/snc7F6WyF+t8ymR7mqy85HH9/b89efz/ZvM96zV+T2b8PX8/fP68BTBynu79VOn8hlpsJfVgluq8jCU78Xi+/b7/uPw+6XR+Fml6YnPccPnt+72/n3KY1Cl8WKu8/v9+oG+9Y3h5qDZjbrt8CfGz0Of8Lrb+sjh99X09tfq/D6W5Wix813V2/3+/YXf5IrQc0fP1rDfoYnC9ljT2kDN1C7I0bfa+U7Q1w+/yTmZ76TakqLm6oPNaWew84K776/q7bLX+SLFztPuy5TI977u8VTS2SWO7KDO+Eih8eDv/Feo8pjK92jX3eT03t7y13K29LvkrpTj50vP13a48uX5+prXhm3Y3jrL02is6srk+63S9Eyd5+f14rfiqZ/L8iSL57rZ9rLgoqjcl6vp7NDsx/7//5zXieLw/dnw0uD3+K/W+abn64/SecTv8jGS6Y7Rd9Hn+5rk6M7y9Or5+trw04bA9X7d4g63y3NWUXwAABP/SURBVHja7J37f1P1Gce/53x77o1LSdKGhkg30kgqAh3dqK2AoCIIRX11A4Vah9PNOZ1jzLkLMnWM6S7Ciw1xNxibl81tTn/Z/r19LycnaZJzThJyLg2f9wtocpKYp08/38/zPN9zGgkBAAAAAAAAAAAAAAAAAAAAHnu3H1rs/9XbS4eQQtAvi3svXTm3fGbV6pPVM9feXzkGCYJ+KFXOnrIGwPLcy0gm6LXwLk5bg+KTC9uRUNCT+V04bw2QGyWkFHTPoRVrsHx2fS+yCrqdW6etQbN6DAIEXcpvxRo8q9eRWNANpy9bUfAZekDQlf2dj0R/1o1F5BaEj75XrIi4gK1oEK6/qORnffIRsgtCWLwQmf6sS6eRXxAyfZyKTn/LGEFACBVf9cxNWxX+jCq/U5VfLGu6qV7PzYUI8BjyC4LtbyVQf+xLRQpvbr5+dI6/jitvOkTAlrWCAgyCN1/O+WmH1c6a639eGa1Z1ZI1bdXmpSXOz62xw3bexwQMgqff5a7qL2GKq3CnK3G9Sf2xW7WQ6fkaCjAIHn9PBenPpUr4zekaqdbmG/rjFjkXLMAzuBALBON/tXOJVORTrFq1VnFFaJVq8iBTI6nO88PE/+qFVeQX9Ol/pMLqb9WdPqzKfEXKrOF/rhBL8D/Q//wR2P+VeAcoFUjqNbep/lqlqlWtYAMQ9D9/PBugv3lSqe++kGrFrb/VKtefW4utYP2dw/wBAtl71k87NVIjcovPItL8KqTG/a9EanNENH5V3iTOB+hvGvUXBPNfK0IuIb8gxAAjlN8pXIMP+m8Ab5mzaP9AGB9Hp78KsgtCd2D+HpX8prH7AsK5HJH8zmP4BV2w+Ldo9Pch7A90NQJHMoKsQH6gyxn4WgSzLy79A8ltwqyg+QM9lODB9oDna9j5Az0NIZcHuA1z4xDcD/TI9o8HU4RPfXgMkwfopwvcWzv77HL/vw+8emb53JXrpzF4gL7LcKkU+KlBI8GvPlbCFQcgQkaQAgD9AegPAOgPQH8AQH8A+gMA+gPQHwDQH4D+AID+APQHAPQHoD8AoD8A/QEA/QHoDwDoD0B/AEB/APoDAPoD0B8A0B+A/gD0BwD0B6A/AKA/AP0BAP0B6A8A6A9AfwBAfwD6AwD6A9AfANAfgP4AgP7AOmHX6OjoCPu7C6kACTA2Itg6hlSAJBgV+htFIkByBgj7A0kaIOwPJGiAsD+QpAHC/kCCBgj7Awmy8Yl0xjWe1nzF+m5PvnSvMWiOPvjIttSkc/+3D94xkcIf854XXrkzjRKMNV+7H7/LiIS7jqQknQs/Z9F8IX0/5m3fNU1zJn1xxZqv3cbdRkR89b5UZHP34yKaz6XMAmeLPzA5n0+ZBcacr6cjk59hPPRw8umcesQLJ1UWOPt1s06qLDDmfD15vxEhd+9LOpv/+EpTOOmxwNl/fs9skB4LjD1fLxmRcjDhdNot8aTEAmd/a64lJRYYf77ujVZ/9yeazcNfawsoDRY4++6PzFbSYIFJ5MuImCQ3sf71UKeIErfA8X//2OxA4haYSL6GVn9TzkGfkJK1wPHMK2ZnkrXAhPI1rPrb8cOAXc0ELXDpgy+aviRogUnlazj1NzH5WGBUSVng+JZ3zCCSssDk8jWU+pvc95OwuBKxwC3P/cwMYeY2y9cQ6m9i4pkuAovfAsfHc2Y48VtgovkaPv3tON7lnlLMFrh08RtmV8zcTvkaNv1t3Pb9rmOL0wLHX54xuyVOC0w6X0Omv/13/LKX6GKzwC13vmr2wMxtk6/h0t+2h3sMLyYL/Gin2RsxWWDy+Rom/Y3tfrr3AGOwwD0v/N7smZnbI19DpL+F3/QVYeQW2HSlVaosMBX5Ghr9Lfzq14ZBVf6W7ltTTX5VqGFo8jYl1OZPtg2F37W16C2wfpmpaWYL7J+M3IMhplkueFLLlpuFR2KxQJGvJnTDUHVxyyaOwp/B0sazpOhRWuCw6G/qbaEvrj9Frb+34ulQs3X2r0OpYtvsiG1oRPX0F6UFjntXWuWKBUKy/JhpFnN1/bG7WTPLRVkQz2e3MnFYoMxXA5sqhko1pjVKHYUvWZsaKtE66W+Q+RoO/U0dftB9M0qIoxOpK2l6LJdE0WzDYcJTqeHqj93WVKY/O9IucPbd33liypj5QqEg7K1YNstEKI8dLeal/kx+y8wXm/QXmQW6+Vpjf7rNskOZ8AzHcPXHkqRqTH+qEpkFDoX+Jo7US67KsydtTajPFhGImsty6DBxyvrLF7Wmaux+lF3g+GvNdbUoDxaZFeZJ3vU/pr96/c1zRbboLxoL9PLVkB8hmiMaE9ajEKLK+uuIVSpzF5EFDoH+pp76qfdu1KhLTRX64wnli1mkkUmOuk9UbZ07pWbo0Q3Cs5lftM4UBbfRK+YyJMvLsZnJM7kVs24XWC636i8CC2zK19r+j/1l0jPU+ppUVL5yHd3QoxuE17/+Trzp/QYVdRze5ams1yNu9WVa1EUUuiKi0TX+GmmQvP7qkQ3CSx882iyjfOMRM0tEwS0K/2M1OcMlV85ky8V8u/4GbYFN+WpCU7kHCqPTXf8TqRH1V49uEF7v+psau6/RQ+uUdSpE5Z2z7upPVamY5HSbWSFlKGwW4Q84CtMfJTSiwW58z3c67qqUmdXlClnmfxwmPTOXzRW4L+bMPNNhB/0N1AKb89U8fohOhKosHzZ1WI+sisRQm+vPcaLbC2z9T4ppR69PkJS4PQH7WaqNKBz5OG/j6yNkQvrb8fya39+jrKVjuVS5+Lj+FK9x4ZOdovP5g79MFQJV24IPX9Ib7iFk05fCz7e90XaZqWeAzPvYwJHJSf9jXsjmDuKWZTOX6aC/Liywy7ha8tWCSsT0weYPt0gQ6X+3sBcYFldH/fGOSS4Jdpf19LxmUd6e6tyYRUcq5ySpPx6tKGtEi1d/Eyeeaasihs66GNWdP2xdDB3EcDSHqU+uauF/7A5/spzyeljSB1guN2xqO/yttea39J6f95Vlq8eEVnDrr9gXLPPbpOAOyn2cDukqrokTj73VWUhi6KA6tXnW+M9VZkpj+uN6cPo+HRIWV3sclIohkb+zzuWlK9IrbDkO6ewP6wgUKTsqLYRVNYf9Y8erv/3Hj7aGr4p9PbGIVGl03k4g72dUqsiX8q1WeVPpcUk/sGnTA+1HR0deb3zE0Z6LPpeZ5lnnV3D1x+Qm9ZcVimQlWDaFeXG4dwvsIq79z386ctPfzHSb937SAWWSxB23BPZrgSFxdfA/qrBIdP7z020eiuhIJRrXn0416vqIbdsiYqa/2P1vYuF/0bSswUv6wIYNBzrlc2TkD3JRj8/OmJEwc2txTTx1kt25mbJ8de7/5OTDm3bPQ6hiuKaiiQ6L2QdlfmNrrC/kKyRu/5v84zejmpmCl/SGDsvZ/YjzP/+JdX7/edWMiGALDInr8FVx82bK8tU+COk6Ed2AqL+O3NOt25+ovw4Tnk5sZoSK2OtV1ST8T4tyat834sco+fI99fR14MUnCmaEPNd3XLu2urdSlq+WfpSy3o7JjrugmD9c/+MTkcodUfR/ttsRiGld88yRKnHOv5PH/fyv3uL5JUtxu4yA9TwZ8MY8nz7r+cW/jJEtF/38L++Nv37dId99yeYD/G9L/3FNvu6nv0Tz1aH+8l2xlmCYEKmjEbf+2rY4i8rEpdX1Z4udGkLjnD8WfH5nUG4Y8G9Bqz9VcTtqIr4F6h3tyObgj//0zefJv8oP+Z19z0dfxfroUai/LG9m6nvSZk5enCCOdmRn8Melhsa1cNJHf0nmq2MwDt+MtFn15aMv3+yzCZ9KWADCAl39qUShIiZF7pXH6398M2vf0VD/o6RlIXlTltrPYvZjdOvJxv/ea6nzr1mu8b8sWfNYxpNoNteP+XUV1459n4b6X9z5aouFalzoClEccaZAbAFyX+PqcuoXiPH6q4s7jhs59VkiEZ97uxrof/zbIYqIyr0AkPezthKwnjf399nHu9Z+wPTSO4H+x6SYJXlhdAVvzy9bzgf4387+Piu6Ja4TV0dSlq91fv5tY6f9fNXdshKXHBCeVd0rLXxzXRGXGw1uMXc6/fZGh4/ZyPFHyuKruAyLb/UVvPqb551f0SwOzvw65WskZfla99cftJ3P9DYrZe1wv8PGeuZnEn2+980D/OD3tvO/xfojmearnAtN5zzck8JkUOa3HvK1/q9/GTvSej2H453YbXQFWmO/RqNsnFJ0w4nK/FwBvvZoi4wyuf+3d76vURxxGJ+9zf5g9xY27m1dxUUhL1KaFOVEQ4pibBMDmhIjavFFsRiMRVFDqLZafGFLa+kvEPqi0j+h9E1/QPvfdWZ2NyaibbzL7Hxn7nkg5pLcycMzn3lmdm/vrrnmPt1caPPn52vyNAnZS69/mbA3L7uu/6v2M7HcofrNpkY+WdjkKZ/ejL0ojt1YXflVx8F/bb/+r5fIq56LZhMor3du+MtFByZ5mSRpoq786OVlxfXPh7e9mMF3mf/K+cyP2eWl+Gzr9Ty7X371VTDb3ma3SFnxyv5jvbQMk5Ivy1misPzI5WXV6z+q1cRtTmRtnc/O5tMmTr2rYbHK8qsr8Nctr/9ImxN/W/uvOebNxelnSR5LVJYftbxsef3bvh+GMKmk/OoD4dWhnvCdsD0va17/Oz7z/aAeD6r8vLOTN+8Pit8RlZ8PRyQvi97/4NAitfKrF+F1auVHKC+L+GPjt64SK7+6Av98Rqz86ORlE3+Mvcab2bVUfrWvt6iVH5W87OKPnf7lW2LlV5+Jeb2rUo+09cnA2vOyjD8+pa9RK79KdzNq5UciL+v4Y4dPzRIrv0rvX18jVn4U8rKPP8b2nqdWfvW5wB+plZ/+vGzkj33gfU6s/OoKzL8kVn7a87KSP76vfkqt/OrjkDvUyk9zXpbyxw5/MUms/OoK/K1PrPz05mUrf+zQh2eolV+1CfyPz7+c0OhLU17W8sfY/miBWPnVa3D5kFj5aczLYv5e8Xne+5luvfzzzye0+9KRl8388V3NWWrlV1fgKrXy05XXrFr8buie0t9dJFZ+dQUWG8TKT1NeT9Xyd157onu/olZ+9XHIOrXy05LXlSmV+E1d1h/o+K0VYuVXqbkwlU75aclrRSF+C5+QSPSdg9TKr9L039TKT0NeM+rwu3SCSKCnfz9DrPzqCkzvESs/DXnNrKhZghfmIjqJju1jJDX2BlFfbeZ1ZX5p1+lbml+cppQnIzrO8DUSwjiDP+QJX+APvsAf8oQv8Adf4A/jDF/gD77AH8YZvsAffIE/jDN8gT/4gjDO8AX+4AvCOMMX+IMvCOMM/sAffEEYZ/BnirrwZYUvI3VBfAL8ngPwZbgvU3XsAs084Ws0tOft90jmCV8jwp8Ik+I4w9eI8PfuMZrjDF+jwR87fpzkOMPXiPDHjtEcZ/gaEf4OXDgAX4b7giAIgiAIeg3heVY7fJkqXGdihy/wB18Qxhn8gT/4gjDO4A/8wReEcQZ/4A++IIwz+EOe8AVhnMGffh3tdrtj/OsofBnty1SNj0m9OQ5fRvsyVl2ZZxe+DPdldAESnM7wNUIF2IUv430ZXIAkpzN8jUwBduHLAl/GFiDR6QxfJuvK7dlgh/pmp3dcmj87PayvP56shTvUPzu949pPq3dtzctMzaxMBko0eW4oXzfv90Ml6j+yMi9T8QumAkW6dGIY/MLlUJGW71iYl6m6qizOIFhYHNzXM2X4heHDdfvyMnXvNxco1NTlgfd+/VChlq8TzevUqPF3O1Cqa4P6ehIq1T2ieZ0ZNf5m1eZ5Y1Bfa2r56xPNa27U+AsUa1BfoWLZlhf4A3/gD/yBP/AH/sAf+AN/4A/8gb/B84xi8a8XVT95HfnNDwJH/j7o8EeL/8Jvm7+kt3kzK7f+Id32E2ubP5152cgfi6Mqx5i5kbizy0N0O4Hji6Q9P+a3+G/a5+/5zTLJN3lKwzTjt3L5+Gzb3drhT2deFvLnR4Hr+o6Yx65T3dvl09n1eIqeCDGWs7tt/iRfZYWYgLH+Fha9ir9Q3Ap7Rev8ac3LPv58j//jVHn6cl533MDlmfr8YfxvHv/W0bP+8oU2DfMavKLhr1l/e6IL2+dPb1728dfhucWBzNPlK0sTnC+/YhYFDtN0/FHwomv4K9NqN5j0OG5FWu8Cy7J9/vTmZeP66wR1nnxau6yaxVEk5jQTe2u3ns9xy/z10rDY5C/plWnVf3keJoncEqZl0dOx/urMy0r+Ir/KM/a8+niuIx/idfjc7vhxx5M76pb5K3O+w6v5S/N6B5iEWZrlOV+As7DHOdTCn8a8bOSP71+qPB3mxPLeTvUXR9zwxWmF+iivVf744UVS85cLxjLGV+AkZRn/Q/W4IguzpH3+dOZl5/orIuN5Rj7fvsjzWmITHXl8fkeuPJ7T0H9ZIVZdefybVoiVLBWwiS4sxdEIy188TdPW+qsvLwv5i+S+xWOOOGPgss2p63riR0fk6cvfRq3yl2Q9Vsr+y4oGSXlMLPeBfAmuTsz0WNEyf1rzwvNveP4Nz7+BP/AH/sAf+AN/4A/8gT/wB/7AH/gDf+AP/IE/alpSG+fsoL6ovv6cal6m6qLaPAd+R6cNtfxt2JaXqTp7SWWckx8P6mt1WWn9PbYtL1M1Pakyz/mBfd1V+v5XD6zLy1idUzihJ4d49+NHCguwf9K+vIzViQVlcQ71bnZ3HirD77qNeRmrRTXv6Dl5ccjZvK6mAfsbJ+3My1hdPn9j19Oc++izoX19/fOnu0/fg8fW5gVBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARBEARB/69/AUmVy3iWKLVNAAAAAElFTkSuQmCC)]

現在，讓我們在回到 4.6 節我們寫的 Demo，現在是不是很容易就可以搞懂它的原理了呢？

沒搞懂的話，也沒關系，可以看看我的分析：

我們在代碼中模擬了 10 個任務，我們配置的核心線程數為 5 、等待隊列容量為 100 ，所以每次只可能存在 5 個任務同時執行，剩下的 5 個任務會被放到等待隊列中去。當前的5個任務中如果有任務被執行完了，線程池就會去拿新的任務執行。

9、Atomic 原子類

介紹一下 Atomic 原子類

Atomic 翻譯成中文是原子的意思。在化學上，我們知道原子是構成一般物質的最小單位，在化學反應中是不可分割的。在我們這里 Atomic 是指一個操作是不可中斷的。即使是在多個線程一起執行的時候，一個操作一旦開始，就不會被其他線程干擾。

所以，所謂原子類說簡單點就是具有原子/原子操作特征的類。

并發包 java.util.concurrent 的原子類都存放在java.util.concurrent.atomic下,如下圖所示。

JUC 包中的原子類是哪 4 類?

基本類型

使用原子的方式更新基本類型

AtomicInteger：整形原子類
AtomicLong：長整型原子類
AtomicBoolean：布爾型原子類

數組類型

使用原子的方式更新數組里的某個元素

AtomicIntegerArray：整形數組原子類
AtomicLongArray：長整形數組原子類
AtomicReferenceArray：引用類型數組原子類

引用類型

AtomicReference：引用類型原子類
AtomicStampedReference：原子更新帶有版本號的引用類型。該類將整數值與引用關聯起來，可用于解決原子的更新數據和數據的版本號，可以解決使用 CAS 進行原子更新時可能出現的 ABA 問題。
AtomicMarkableReference ：原子更新帶有標記位的引用類型

對象的屬性修改類型

AtomicIntegerFieldUpdater：原子更新整形字段的更新器
AtomicLongFieldUpdater：原子更新長整形字段的更新器
AtomicReferenceFieldUpdater：原子更新引用類型字段的更新器

講講 AtomicInteger 的使用

AtomicInteger 類常用方法

public final int get() //獲取當前的值 public final int getAndSet(int newValue)//獲取當前的值，并設置新的值 public final int getAndIncrement()//獲取當前的值，并自增 public final int getAndDecrement() //獲取當前的值，并自減 public final int getAndAdd(int delta) //獲取當前的值，并加上預期的值 boolean compareAndSet(int expect, int update) //如果輸入的數值等于預期值，則以原子方式將該值設置為輸入值（update） public final void lazySet(int newValue)//最終設置為newValue,使用 lazySet 設置之后可能導致其他線程在之后的一小段時間內還是可以讀到舊的值。

1
2
3
4
5
6
7

AtomicInteger 類的使用示例

使用 AtomicInteger 之后，不用對 increment() 方法加鎖也可以保證線程安全。

class AtomicIntegerTest {private AtomicInteger count = new AtomicInteger();//使用AtomicInteger之后，不需要對該方法加鎖，也可以實現線程安全。public void increment() {count.incrementAndGet();}public int getCount() {return count.get();} }

能不能給我簡單介紹一下 AtomicInteger 類的原理

AtomicInteger 線程安全原理簡單分析

AtomicInteger 類的部分源碼：

// setup to use Unsafe.compareAndSwapInt for updates（更新操作時提供“比較并替換”的作用） private static final Unsafe unsafe = Unsafe.getUnsafe(); private static final long valueOffset;static {try {valueOffset = unsafe.objectFieldOffset(AtomicInteger.class.getDeclaredField("value"));} catch (Exception ex) { throw new Error(ex); } }private volatile int value;

AtomicInteger 類主要利用 CAS (compare and swap) + volatile 和 native 方法來保證原子操作，從而避免 synchronized 的高開銷，執行效率大為提升。

CAS 的原理是拿期望的值和原本的一個值作比較，如果相同則更新成新的值。UnSafe 類的 objectFieldOffset() 方法是一個本地方法，這個方法是用來拿到“原來的值”的內存地址，返回值是 valueOffset。另外 value 是一個 volatile 變量，在內存中可見，因此 JVM 可以保證任何時刻任何線程總能拿到該變量的最新值。

關于 Atomic 原子類這部分更多內容可以查看我的這篇文章：并發編程面試必備：JUC 中的 Atomic 原子類總結 (opens new window)

10、AQS

AQS 介紹

AQS 的全稱為（AbstractQueuedSynchronizer），這個類在java.util.concurrent.locks包下面。

AQS 是一個用來構建鎖和同步器的框架，使用 AQS 能簡單且高效地構造出大量應用廣泛的同步器，比如我們提到的 ReentrantLock，Semaphore，其他的諸如 ReentrantReadWriteLock，SynchronousQueue，FutureTask 等等皆是基于 AQS 的。當然，我們自己也能利用 AQS 非常輕松容易地構造出符合我們自己需求的同步器。

AQS 原理分析

AQS 原理這部分參考了部分博客，在 5.2 節末尾放了鏈接。

在面試中被問到并發知識的時候，大多都會被問到“請你說一下自己對于 AQS 原理的理解”。下面給大家一個示例供大家參加，面試不是背題，大家一定要加入自己的思想，即使加入不了自己的思想也要保證自己能夠通俗的講出來而不是背出來。

下面大部分內容其實在 AQS 類注釋上已經給出了，不過是英語看著比較吃力一點，感興趣的話可以看看源碼。

AQS 原理概覽

AQS 核心思想是，如果被請求的共享資源空閑，則將當前請求資源的線程設置為有效的工作線程，并且將共享資源設置為鎖定狀態。如果被請求的共享資源被占用，那么就需要一套線程阻塞等待以及被喚醒時鎖分配的機制，這個機制 AQS 是用 CLH 隊列鎖實現的，即將暫時獲取不到鎖的線程加入到隊列中。

CLH(Craig,Landin and Hagersten)隊列是一個虛擬的雙向隊列（虛擬的雙向隊列即不存在隊列實例，僅存在結點之間的關聯關系）。AQS 是將每條請求共享資源的線程封裝成一個 CLH 鎖隊列的一個結點（Node）來實現鎖的分配。

看個 AQS(AbstractQueuedSynchronizer)原理圖：

AQS 使用一個 int 成員變量來表示同步狀態，通過內置的 FIFO 隊列來完成獲取資源線程的排隊工作。AQS 使用 CAS 對該同步狀態進行原子操作實現對其值的修改。

private volatile int state;//共享變量，使用volatile修飾保證線程可見性

狀態信息通過 protected 類型的 getState，setState，compareAndSetState 進行操作

//返回同步狀態的當前值 protected final int getState() {return state; } //設置同步狀態的值 protected final void setState(int newState) {state = newState; } //原子地（CAS操作）將同步狀態值設置為給定值update如果當前同步狀態的值等于expect（期望值） protected final boolean compareAndSetState(int expect, int update) {return unsafe.compareAndSwapInt(this, stateOffset, expect, update); }

AQS 對資源的共享方式

AQS 定義兩種資源共享方式

Exclusive

（獨占）：只有一個線程能執行，如
ReentrantLock
。又可分為公平鎖和非公平鎖：
- 公平鎖：按照線程在隊列中的排隊順序，先到者先拿到鎖
- 非公平鎖：當線程要獲取鎖時，無視隊列順序直接去搶鎖，誰搶到就是誰的
Share（共享）：多個線程可同時執行，如CountDownLatch、Semaphore、 CyclicBarrier、ReadWriteLock 我們都會在后面講到。

ReentrantReadWriteLock 可以看成是組合式，因為 ReentrantReadWriteLock 也就是讀寫鎖允許多個線程同時對某一資源進行讀。

不同的自定義同步器爭用共享資源的方式也不同。自定義同步器在實現時只需要實現共享資源 state 的獲取與釋放方式即可，至于具體線程等待隊列的維護（如獲取資源失敗入隊/喚醒出隊等），AQS 已經在頂層實現好了。

AQS 底層使用了模板方法模式

同步器的設計是基于模板方法模式的，如果需要自定義同步器一般的方式是這樣（模板方法模式很經典的一個應用）：

使用者繼承 AbstractQueuedSynchronizer 并重寫指定的方法。（這些重寫方法很簡單，無非是對于共享資源 state 的獲取和釋放）

將 AQS 組合在自定義同步組件的實現中，并調用其模板方法，而這些模板方法會調用使用者重寫的方法。

這和我們以往通過實現接口的方式有很大區別，這是模板方法模式很經典的一個運用。

AQS 使用了模板方法模式，自定義同步器時需要重寫下面幾個 AQS 提供的模板方法：

isHeldExclusively()//該線程是否正在獨占資源。只有用到condition才需要去實現它。 tryAcquire(int)//獨占方式。嘗試獲取資源，成功則返回true，失敗則返回false。 tryRelease(int)//獨占方式。嘗試釋放資源，成功則返回true，失敗則返回false。 tryAcquireShared(int)//共享方式。嘗試獲取資源。負數表示失敗；0表示成功，但沒有剩余可用資源；正數表示成功，且有剩余資源。 tryReleaseShared(int)//共享方式。嘗試釋放資源，成功則返回true，失敗則返回false。

默認情況下，每個方法都拋出 UnsupportedOperationException。這些方法的實現必須是內部線程安全的，并且通常應該簡短而不是阻塞。AQS 類中的其他方法都是 final ，所以無法被其他類使用，只有這幾個方法可以被其他類使用。

以 ReentrantLock 為例，state 初始化為 0，表示未鎖定狀態。A 線程 lock()時，會調用 tryAcquire()獨占該鎖并將 state+1。此后，其他線程再 tryAcquire()時就會失敗，直到 A 線程 unlock()到 state=0（即釋放鎖）為止，其它線程才有機會獲取該鎖。當然，釋放鎖之前，A 線程自己是可以重復獲取此鎖的（state 會累加），這就是可重入的概念。但要注意，獲取多少次就要釋放多少次，這樣才能保證 state 是能回到零態的。

再以 CountDownLatch 以例，任務分為 N 個子線程去執行，state 也初始化為 N（注意 N 要與線程個數一致）。這 N 個子線程是并行執行的，每個子線程執行完后countDown() 一次，state 會 CAS(Compare and Swap)減 1。等到所有子線程都執行完后(即 state=0)，會 unpark()主調用線程，然后主調用線程就會從 await() 函數返回，繼續后余動作。

一般來說，自定義同步器要么是獨占方法，要么是共享方式，他們也只需實現tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一種即可。但 AQS 也支持自定義同步器同時實現獨占和共享兩種方式，如ReentrantReadWriteLock。

推薦兩篇 AQS 原理和相關源碼分析的文章：

https://www.cnblogs.com/waterystone/p/4920797.html
https://www.cnblogs.com/chengxiao/archive/2017/07/24/7141160.html

AQS 組件總結

Semaphore(信號量)-允許多個線程同時訪問： synchronized 和 ReentrantLock 都是一次只允許一個線程訪問某個資源，Semaphore(信號量)可以指定多個線程同時訪問某個資源。
CountDownLatch（倒計時器）： CountDownLatch 是一個同步工具類，用來協調多個線程之間的同步。這個工具通常用來控制線程等待，它可以讓某一個線程等待直到倒計時結束，再開始執行。
CyclicBarrier(循環柵欄)： CyclicBarrier 和 CountDownLatch 非常類似，它也可以實現線程間的技術等待，但是它的功能比 CountDownLatch 更加復雜和強大。主要應用場景和 CountDownLatch 類似。CyclicBarrier 的字面意思是可循環使用（Cyclic）的屏障（Barrier）。它要做的事情是，讓一組線程到達一個屏障（也可以叫同步點）時被阻塞，直到最后一個線程到達屏障時，屏障才會開門，所有被屏障攔截的線程才會繼續干活。CyclicBarrier 默認的構造方法是 CyclicBarrier(int parties)，其參數表示屏障攔截的線程數量，每個線程調用 await() 方法告訴 CyclicBarrier 我已經到達了屏障，然后當前線程被阻塞。

11、用過 CountDownLatch 么？什么場景下用的？

CountDownLatch 的作用就是允許 count 個線程阻塞在一個地方，直至所有線程的任務都執行完畢。之前在項目中，有一個使用多線程讀取多個文件處理的場景，我用到了 CountDownLatch 。具體場景是下面這樣的：

我們要讀取處理 6 個文件，這 6 個任務都是沒有執行順序依賴的任務，但是我們需要返回給用戶的時候將這幾個文件的處理的結果進行統計整理。

為此我們定義了一個線程池和 count 為 6 的CountDownLatch對象。使用線程池處理讀取任務，每一個線程處理完之后就將 count-1，調用CountDownLatch對象的 await()方法，直到所有文件讀取完之后，才會接著執行后面的邏輯。

偽代碼是下面這樣的：

public class CountDownLatchExample1 {// 處理文件的數量private static final int threadCount = 6;public static void main(String[] args) throws InterruptedException {// 創建一個具有固定線程數量的線程池對象（推薦使用構造方法創建）ExecutorService threadPool = Executors.newFixedThreadPool(10);final CountDownLatch countDownLatch = new CountDownLatch(threadCount);for (int i = 0; i < threadCount; i++) {final int threadnum = i;threadPool.execute(() -> {try {//處理文件的業務操作//......} catch (InterruptedException e) {e.printStackTrace();} finally {//表示一個文件已經被完成countDownLatch.countDown();}});}countDownLatch.await();threadPool.shutdown();System.out.println("finish");} }

有沒有可以改進的地方呢？

可以使用 CompletableFuture 類來改進！Java8 的 CompletableFuture 提供了很多對多線程友好的方法，使用它可以很方便地為我們編寫多線程程序，什么異步、串行、并行或者等待所有線程執行完任務什么的都非常方便。

CompletableFuture<Void> task1 =CompletableFuture.supplyAsync(()->{//自定義業務操作}); ...... CompletableFuture<Void> task6 =CompletableFuture.supplyAsync(()->{//自定義業務操作}); ...... CompletableFuture<Void> headerFuture=CompletableFuture.allOf(task1,.....,task6);try {headerFuture.join(); } catch (Exception ex) {//...... } System.out.println("all done. ");

上面的代碼還可以接續優化，當任務過多的時候，把每一個 task 都列出來不太現實，可以考慮通過循環來添加任務。

//文件夾位置 List<String> filePaths = Arrays.asList(...) // 異步處理所有文件 List<CompletableFuture<String>> fileFutures = filePaths.stream().map(filePath -> doSomeThing(filePath)).collect(Collectors.toList()); // 將他們合并起來 CompletableFuture<Void> allFutures = CompletableFuture.allOf(fileFutures.toArray(new CompletableFuture[fileFutures.size()]) );

問題四： JVM 對 Java 的原生鎖做了哪些優化？在 Java 6 之前， Monitor 的實現完全依賴底層操作系統的互斥鎖來實現，也就是我們剛才在問題二中所闡述的獲取 /釋放鎖的邏輯。由于 Java 層面的線程與操作系統的原生線程有映射關系，如果要將一個線程進行阻塞或喚起都需要操作系統的協助，這就需要從用戶態切換到內核態來執行，這種切換代價十分昂貴，很耗處理器時間，現代 JDK 中做了大量的優化。一種優化是使用自旋鎖，即在把線程進行阻塞操作之前先讓線程自旋等待一段時間，可能在等待期間其他線程已經解鎖，這時就無需再讓線程執行阻塞操作，避免了用戶態到內核態的切換。現代 JDK 中還提供了三種不同的 Monitor 實現，也就是三種不同的鎖： ? 偏向鎖（ Biased Locking） ? 輕量級鎖 ? 重量級鎖這三種鎖使得 JDK 得以優化 Synchronized 的運行，當 JVM 檢測到不同的競爭狀況時，會自動切換到適合的鎖實現，這就是鎖的升級、降級。 ? 當沒有競爭出現時，默認會使用偏向鎖。 JVM 會利用 CAS 操作，在對象頭上的 Mark Word 部分設置線程 ID，以表示這個對象偏向于當前線程，所以并不涉及真正的互斥鎖，因為在很多應用場景中，大部分對象生命周期中最多會被一個線程鎖定，使用偏斜鎖可以降低無競爭開銷。 ? 如果有另一線程試圖鎖定某個被偏斜過的對象， JVM 就撤銷偏斜鎖，切換到輕量級鎖實現。 ? 輕量級鎖依賴 CAS 操作 Mark Word 來試圖獲取鎖，如果重試成功，就使用普通的輕量級鎖；否則，進一步升級為重量級鎖。

做了哪些優化？在 Java 6 之前， Monitor 的實現完全依賴底層操作系統的互斥鎖來實現，也就是我們剛才在問題二中所闡述的獲取 /釋放鎖的邏輯。由于 Java 層面的線程與操作系統的原生線程有映射關系，如果要將一個線程進行阻塞或喚起都需要操作系統的協助，這就需要從用戶態切換到內核態來執行，這種切換代價十分昂貴，很耗處理器時間，現代 JDK 中做了大量的優化。一種優化是使用自旋鎖，即在把線程進行阻塞操作之前先讓線程自旋等待一段時間，可能在等待期間其他線程已經解鎖，這時就無需再讓線程執行阻塞操作，避免了用戶態到內核態的切換。現代 JDK 中還提供了三種不同的 Monitor 實現，也就是三種不同的鎖： ? 偏向鎖（ Biased Locking） ? 輕量級鎖 ? 重量級鎖這三種鎖使得 JDK 得以優化 Synchronized 的運行，當 JVM 檢測到不同的競爭狀況時，會自動切換到適合的鎖實現，這就是鎖的升級、降級。 ? 當沒有競爭出現時，默認會使用偏向鎖。 JVM 會利用 CAS 操作，在對象頭上的 Mark Word 部分設置線程 ID，以表示這個對象偏向于當前線程，所以并不涉及真正的互斥鎖，因為在很多應用場景中，大部分對象生命周期中最多會被一個線程鎖定，使用偏斜鎖可以降低無競爭開銷。 ? 如果有另一線程試圖鎖定某個被偏斜過的對象， JVM 就撤銷偏斜鎖，切換到輕量級鎖實現。 ? 輕量級鎖依賴 CAS 操作 Mark Word 來試圖獲取鎖，如果重試成功，就使用普通的輕量級鎖；否則，進一步升級為重量級鎖。

Synchronized 相關問題問題一： Synchronized 用過嗎，其原理是什么？這是一道 Java 面試中幾乎百分百會問到的問題，因為沒有任何寫過并發程序的開發者會沒聽說或者沒接觸過 Synchronized。 Synchronized 是由 JVM 實現的一種實現互斥同步的一種方式，如果你查看被 Synchronized 修飾過的程序塊編譯后的字節碼，會發現，被 Synchronized 修飾過的程序塊，在編譯前后被編譯器生成了 monitorenter 和 monitorexit 兩個字節碼指令。這兩個指令是什么意思呢？在虛擬機執行到 monitorenter 指令時，首先要嘗試獲取對象的鎖：如果這個對象沒有鎖定，或者當前線程已經擁有了這個對象的鎖，把鎖的計數器 +1；當執行 monitorexit 指令時將鎖計數器 -1；當計數器為 0 時，鎖就被釋放了。如果獲取對象失敗了，那當前線程就要阻塞等待，直到對象鎖被另外一個線程釋放為止。 Java 中 Synchronize 通過在對象頭設置標記，達到了獲取鎖和釋放鎖的目的。問題二：你剛才提到獲取對象的鎖，這個 “ 鎖 ” 到底是什么？如何確定對象的鎖？ “ 鎖 ” 的本質其實是 monitorenter 和 monitorexit 字節碼指令的一個 Reference 類型的參數，即要鎖定和解鎖的對象。我們知道，使用 Synchronized 可以修飾不同的對象，因此，對應的對象鎖可以這么確定。 1. 如果 Synchronized 明確指定了鎖對象，比如 Synchronized（變量名）、 Synchronized(this) 等，說明加解鎖對象為該對象。 2. 如果沒有明確指定：若 Synchronized 修飾的方法為非靜態方法，表示此方法對應的對象為鎖對象；若 Synchronized 修飾的方法為靜態方法，則表示此方法對應的類對象為鎖對象。注意，當一個對象被鎖住時，對象里面所有用 Synchronized 修飾的方法都將產生堵塞，而對象里非 Synchronized 修飾的方法可正常被調用，不受鎖影響。問題三：什么是可重入性，為什么說 Synchronized 是可重入鎖？可重入性是鎖的一個基本要求，是為了解決自己鎖死自己的情況。比如下面的偽代碼，一個類中的同步方法調用另一個同步方法，假如 Synchronized 不支持重入，進入 method2 方法時當前線程獲得鎖， method2 方法里面執行 method1 時當前線程又要去嘗試獲取鎖，這時如果不支持重入，它就要等釋放，把自己阻塞，導致自己鎖死自己。 · 點擊圖片，放大查看 · 對 Synchronized 來說，可重入性是顯而易見的，剛才提到，在執行 monitorenter 指令時，如果這個對象沒有鎖定，或者當前線程已經擁有了這個對象的鎖（而不是已擁有了鎖則不能繼續獲取），就把鎖的計數器 +1，其實本質上就通過這種方式實現了可重入性。問題四： JVM 對 Java 的原生鎖做了哪些優化？在 Java 6 之前， Monitor 的實現完全依賴底層操作系統的互斥鎖來實現，也就是我們剛才在問題二中所闡述的獲取 /釋放鎖的邏輯。由于 Java 層面的線程與操作系統的原生線程有映射關系，如果要將一個線程進行阻塞或喚起都需要操作系統的協助，這就需要從用戶態切換到內核態來執行，這種切換代價十分昂貴，很耗處理器時間，現代 JDK 中做了大量的優化。一種優化是使用自旋鎖，即在把線程進行阻塞操作之前先讓線程自旋等待一段時間，可能在等待期間其他線程已經解鎖，這時就無需再讓線程執行阻塞操作，避免了用戶態到內核態的切換。現代 JDK 中還提供了三種不同的 Monitor 實現，也就是三種不同的鎖： ? 偏向鎖（ Biased Locking） ? 輕量級鎖 ? 重量級鎖這三種鎖使得 JDK 得以優化 Synchronized 的運行，當 JVM 檢測到不同的競爭狀況時，會自動切換到適合的鎖實現，這就是鎖的升級、降級。 ? 當沒有競爭出現時，默認會使用偏向鎖。 JVM 會利用 CAS 操作，在對象頭上的 Mark Word 部分設置線程 ID，以表示這個對象偏向于當前線程，所以并不涉及真正的互斥鎖，因為在很多應用場景中，大部分對象生命周期中最多會被一個線程鎖定，使用偏斜鎖可以降低無競爭開銷。 ? 如果有另一線程試圖鎖定某個被偏斜過的對象， JVM 就撤銷偏斜鎖，切換到輕量級鎖實現。 ? 輕量級鎖依賴 CAS 操作 Mark Word 來試圖獲取鎖，如果重試成功，就使用普通的輕量級鎖；否則，進一步升級為重量級鎖。問題五：為什么說 Synchronized 是非公平鎖？非公平主要表現在獲取鎖的行為上，并非是按照申請鎖的時間前后給等待線程分配鎖的，每當鎖被釋放后，任何一個線程都有機會競爭到鎖，這樣做的目的是為了提高執行性能，缺點是可能會產生線程饑餓現象。問題六：什么是鎖消除和鎖粗化？ ? 鎖消除：指虛擬機即時編譯器在運行時，對一些代碼上要求同步，但被檢測到不可能存在共享數據競爭的鎖進行消除。主要根據逃逸分析。程序員怎么會在明知道不存在數據競爭的情況下使用同步呢？很多不是程序員自己加入的。 ? 鎖粗化：原則上，同步塊的作用范圍要盡量小。但是如果一系列的連續操作都對同一個對象反復加鎖和解鎖，甚至加鎖操作在循環體內，頻繁地進行互斥同步操作也會導致不必要的性能損耗。鎖粗化就是增大鎖的作用域。問題七：為什么說 Synchronized 是一個悲觀鎖？樂觀鎖的實現原理又是什么？什么是 CAS，它有什么特性？ Synchronized 顯然是一個悲觀鎖，因為它的并發策略是悲觀的：不管是否會產生競爭，任何的數據操作都必須要加鎖、用戶態核心態轉換、維護鎖計數器和檢查是否有被阻塞的線程需要被喚醒等操作。隨著硬件指令集的發展，我們可以使用基于沖突檢測的樂觀并發策略。先進行操作，如果沒有其他線程征用數據，那操作就成功了；如果共享數據有征用，產生了沖突，那就再進行其他的補償措施。這種樂觀的并發策略的許多實現不需要線程掛起，所以被稱為非阻塞同步。樂觀鎖的核心算法是 CAS（ Compareand Swap，比較并交換），它涉及到三個操作數：內存值、預期值、新值。當且僅當預期值和內存值相等時才將內存值修改為新值。這樣處理的邏輯是，首先檢查某塊內存的值是否跟之前我讀取時的一樣，如不一樣則表示期間此內存值已經被別的線程更改過，舍棄本次操作，否則說明期間沒有其他線程對此內存值操作，可以把新值設置給此塊內存。 CAS 具有原子性，它的原子性由 CPU 硬件指令實現保證，即使用 JNI 調用 Native 方法調用由 C++ 編寫的硬件級別指令， JDK 中提供了 Unsafe 類執行這些操作。問題八：樂觀鎖一定就是好的嗎？樂觀鎖避免了悲觀鎖獨占對象的現象，同時也提高了并發性能，但它也有缺點： 1. 樂觀鎖只能保證一個共享變量的原子操作。如果多一個或幾個變量，樂觀鎖將變得力不從心，但互斥鎖能輕易解決，不管對象數量多少及對象顆粒度大小。 2. 長時間自旋可能導致開銷大。假如 CAS 長時間不成功而一直自旋，會給 CPU 帶來很大的開銷。 3. ABA 問題。 CAS 的核心思想是通過比對內存值與預期值是否一樣而判斷內存值是否被改過，但這個判斷邏輯不嚴謹，假如內存值原來是 A，后來被一條線程改為 B，最后又被改成了 A，則 CAS 認為此內存值并沒有發生改變，但實際上是有被其他線程改過的，這種情況對依賴過程值的情景的運算結果影響很大。解決的思路是引入版本號，每次變量更新都把版本號加一。可重入鎖 ReentrantLock 及其他顯式鎖相關問題問題一：跟 Synchronized 相比，可重入鎖 ReentrantLock 其實現原理有什么不同？其實，鎖的實現原理基本是為了達到一個目的：讓所有的線程都能看到某種標記。 Synchronized 通過在對象頭中設置標記實現了這一目的，是一種 JVM 原生的鎖實現方式，而 ReentrantLock 以及所有的基于 Lock 接口的實現類，都是通過用一個 volitile 修飾的 int 型變量，并保證每個線程都能擁有對該 int 的可見性和原子修改，其本質是基于所謂的 AQS 框架。問題二：那么請談談 AQS 框架是怎么回事兒？ AQS（ AbstractQueuedSynchronizer 類）是一個用來構建鎖和同步器的框架，各種 Lock 包中的鎖（常用的有 ReentrantLock、 ReadWriteLock），以及其他如 Semaphore、 CountDownLatch，甚至是早期的 FutureTask 等，都是基于 AQS 來構建。 1. AQS 在內部定義了一個 volatile int state 變量，表示同步狀態：當線程調用 lock 方法時，如果 state=0，說明沒有任何線程占有共享資源的鎖，可以獲得鎖并將 state=1；如果 state=1，則說明有線程目前正在使用共享變量，其他線程必須加入同步隊列進行等待。 2. AQS 通過 Node 內部類構成的一個雙向鏈表結構的同步隊列，來完成線程獲取鎖的排隊工作，當有線程獲取鎖失敗后，就被添加到隊列末尾。 o Node 類是對要訪問同步代碼的線程的封裝，包含了線程本身及其狀態叫 waitStatus（有五種不同取值，分別表示是否被阻塞，是否等待喚醒，是否已經被取消等），每個 Node 結點關聯其 prev 結點和 next 結點，方便線程釋放鎖后快速喚醒下一個在等待的線程，是一個 FIFO 的過程。 o Node 類有兩個常量， SHARED 和 EXCLUSIVE，分別代表共享模式和獨占模式。所謂共享模式是一個鎖允許多條線程同時操作（信號量 Semaphore 就是基于 AQS 的共享模式實現的），獨占模式是同一個時間段只能有一個線程對共享資源進行操作，多余的請求線程需要排隊等待（如 ReentranLock）。 3. AQS 通過內部類 ConditionObject 構建等待隊列（可有多個），當 Condition 調用 wait() 方法后，線程將會加入等待隊列中，而當 Condition 調用 signal() 方法后，線程將從等待隊列轉移動同步隊列中進行鎖競爭。 4. AQS 和 Condition 各自維護了不同的隊列，在使用 Lock 和 Condition 的時候，其實就是兩個隊列的互相移動。問題三：請盡可能詳盡地對比下 Synchronized 和 ReentrantLock 的異同。 ReentrantLock 是 Lock 的實現類，是一個互斥的同步鎖。從功能角度， ReentrantLock 比 Synchronized 的同步操作更精細（因為可以像普通對象一樣使用），甚至實現 Synchronized 沒有的高級功能，如： ? 等待可中斷：當持有鎖的線程長期不釋放鎖的時候，正在等待的線程可以選擇放棄等待，對處理執行時間非常長的同步塊很有用。 ? 帶超時的獲取鎖嘗試：在指定的時間范圍內獲取鎖，如果時間到了仍然無法獲取則返回。 ? 可以判斷是否有線程在排隊等待獲取鎖。 ? 可以響應中斷請求：與 Synchronized 不同，當獲取到鎖的線程被中斷時，能夠響應中斷，中斷異常將會被拋出，同時鎖會被釋放。 ? 可以實現公平鎖。從鎖釋放角度， Synchronized 在 JVM 層面上實現的，不但可以通過一些監控工具監控 Synchronized 的鎖定，而且在代碼執行出現異常時， JVM 會自動釋放鎖定；但是使用 Lock 則不行， Lock 是通過代碼實現的，要保證鎖定一定會被釋放，就必須將 unLock() 放到 finally{} 中。從性能角度， Synchronized 早期實現比較低效，對比 ReentrantLock，大多數場景性能都相差較大。但是在 Java 6 中對其進行了非常多的改進，在競爭不激烈時， Synchronized 的性能要優于 ReetrantLock；在高競爭情況下， Synchronized 的性能會下降幾十倍，但是 ReetrantLock 的性能能維持常態。問題四： ReentrantLock 是如何實現可重入性的？ ReentrantLock 內部自定義了同步器 Sync（ Sync 既實現了 AQS，又實現了 AOS，而 AOS 提供了一種互斥鎖持有的方式），其實就是加鎖的時候通過 CAS 算法，將線程對象放到一個雙向鏈表中，每次獲取鎖的時候，看下當前維護的那個線程 ID 和當前請求的線程 ID 是否一樣，一樣就可重入了。問題五：除了 ReetrantLock，你還接觸過 JUC 中的哪些并發工具？通常所說的并發包（ JUC）也就是 java.util.concurrent 及其子包，集中了 Java 并發的各種基礎工具類，具體主要包括幾個方面： ? 提供了 CountDownLatch、 CyclicBarrier、 Semaphore 等，比 Synchronized 更加高級，可以實現更加豐富多線程操作的同步結構。 ? 提供了 ConcurrentHashMap、有序的 ConcunrrentSkipListMap，或者通過類似快照機制實現線程安全的動態數組 CopyOnWriteArrayList 等，各種線程安全的容器。 ? 提供了 ArrayBlockingQueue、 SynchorousQueue 或針對特定場景的 PriorityBlockingQueue 等，各種并發隊列實現。 ? 強大的 Executor 框架，可以創建各種不同類型的線程池，調度任務運行等。問題六：請談談 ReadWriteLock 和 StampedLock。雖然 ReentrantLock 和 Synchronized 簡單實用，但是行為上有一定局限性，要么不占，要么獨占。實際應用場景中，有時候不需要大量競爭的寫操作，而是以并發讀取為主，為了進一步優化并發操作的粒度， Java 提供了讀寫鎖。讀寫鎖基于的原理是多個讀操作不需要互斥，如果讀鎖試圖鎖定時，寫鎖是被某個線程持有，讀鎖將無法獲得，而只好等待對方操作結束，這樣就可以自動保證不會讀取到有爭議的數據。 ReadWriteLock 代表了一對鎖，下面是一個基于讀寫鎖實現的數據結構，當數據量較大，并發讀多、并發寫少的時候，能夠比純同步版本凸顯出優勢： · 讀寫鎖看起來比 Synchronized 的粒度似乎細一些，但在實際應用中，其表現也并不盡如人意，主要還是因為相對比較大的開銷。所以， JDK 在后期引入了 StampedLock，在提供類似讀寫鎖的同時，還支持優化讀模式。優化讀基于假設，大多數情況下讀操作并不會和寫操作沖突，其邏輯是先試著修改，然后通過 validate 方法確認是否進入了寫模式，如果沒有進入，就成功避免了開銷；如果進入，則嘗試獲取讀鎖。 · 問題七：如何讓 Java 的線程彼此同步？你了解過哪些同步器？請分別介紹下。 JUC 中的同步器三個主要的成員： CountDownLatch、 CyclicBarrier 和 Semaphore，通過它們可以方便地實現很多線程之間協作的功能。 CountDownLatch 叫倒計數，允許一個或多個線程等待某些操作完成。看幾個場景： ? 跑步比賽，裁判需要等到所有的運動員（ “ 其他線程 ” ）都跑到終點（達到目標），才能去算排名和頒獎。 ? 模擬并發，我需要啟動 100 個線程去同時訪問某一個地址，我希望它們能同時并發，而不是一個一個的去執行。用法： CountDownLatch 構造方法指明計數數量，被等待線程調用 countDown 將計數器減 1，等待線程使用 await 進行線程等待。一個簡單的例子： CyclicBarrier 叫循環柵欄，它實現讓一組線程等待至某個狀態之后再全部同時執行，而且當所有等待線程被釋放后， CyclicBarrier 可以被重復使用。 CyclicBarrier 的典型應用場景是用來等待并發線程結束。 CyclicBarrier 的主要方法是 await()， await() 每被調用一次，計數便會減少 1，并阻塞住當前線程。當計數減至 0 時，阻塞解除，所有在此 CyclicBarrier 上面阻塞的線程開始運行。在這之后，如果再次調用 await()，計數就又會變成 N-1，新一輪重新開始，這便是 Cyclic 的含義所在。 CyclicBarrier.await() 帶有返回值，用來表示當前線程是第幾個到達這個 Barrier 的線程。舉例說明如下： · Semaphore， Java 版本的信號量實現，用于控制同時訪問的線程個數，來達到限制通用資源訪問的目的，其原理是通過 acquire() 獲取一個許可，如果沒有就等待，而 release() 釋放一個許可。如果 Semaphore 的數值被初始化為 1，那么一個線程就可以通過 acquire 進入互斥狀態，本質上和互斥鎖是非常相似的。但是區別也非常明顯，比如互斥鎖是有持有者的，而對于 Semaphore 這種計數器結構，雖然有類似功能，但其實不存在真正意義的持有者，除非我們進行擴展包裝。問題八： CyclicBarrier 和 CountDownLatch 看起來很相似，請對比下呢？它們的行為有一定相似度，區別主要在于： ? CountDownLatch 是不可以重置的，所以無法重用， CyclicBarrier 沒有這種限制，可以重用。 ? CountDownLatch 的基本操作組合是 countDown/await，調用 await 的線程阻塞等待 countDown 足夠的次數，不管你是在一個線程還是多個線程里 countDown，只要次數足夠即可。 CyclicBarrier 的基本操作組合就是 await，當所有的伙伴都調用了 await，才會繼續進行任務，并自動進行重置。 CountDownLatch 目的是讓一個線程等待其他 N 個線程達到某個條件后，自己再去做某個事（通過 CyclicBarrier 的第二個構造方法 public CyclicBarrier(int parties, Runnable barrierAction)，在新線程里做事可以達到同樣的效果）。而 CyclicBarrier 的目的是讓 N 多線程互相等待直到所有的都達到某個狀態，然后這 N 個線程再繼續執行各自后續（通過 CountDownLatch 在某些場合也能完成類似的效果）。 Java 線程池相關問題問題一： Java 中的線程池是如何實現的？ ? 在 Java 中，所謂的線程池中的 “ 線程 ” ，其實是被抽象為了一個靜態內部類 Worker，它基于 AQS 實現，存放在線程池的 HashSet workers 成員變量中； ? 而需要執行的任務則存放在成員變量 workQueue （ BlockingQueue workQueue）中。這樣，整個線程池實現的基本思想就是：從 workQueue 中不斷取出需要執行的任務，放在 Workers 中進行處理。問題二：創建線程池的幾個核心構造參數？ Java 中的線程池的創建其實非常靈活，我們可以通過配置不同的參數，創建出行為不同的線程池，這幾個參數包括： ? corePoolSize：線程池的核心線程數。 ? maximumPoolSize：線程池允許的最大線程數。 ? keepAliveTime：超過核心線程數時閑置線程的存活時間。 ? workQueue：任務執行前保存任務的隊列，保存由 execute 方法提交的 Runnable 任務。問題三：線程池中的線程是怎么創建的？是一開始就隨著線程池的啟動創建好的嗎？顯然不是的。線程池默認初始化后不啟動 Worker，等待有請求時才啟動。每當我們調用 execute() 方法添加一個任務時，線程池會做如下判斷： ? 如果正在運行的線程數量小于 corePoolSize，那么馬上創建線程運行這個任務； ? 如果正在運行的線程數量大于或等于 corePoolSize，那么將這個任務放入隊列； ? 如果這時候隊列滿了，而且正在運行的線程數量小于 maximumPoolSize，那么還是要創建非核心線程立刻運行這個任務； ? 如果隊列滿了，而且正在運行的線程數量大于或等于 maximumPoolSize，那么線程池會拋出異常 RejectExecutionException。當一個線程完成任務時，它會從隊列中取下一個任務來執行。當一個線程無事可做，超過一定的時間（ keepAliveTime）時，線程池會判斷。如果當前運行的線程數大于 corePoolSize，那么這個線程就被停掉。所以線程池的所有任務完成后，它最終會收縮到 corePoolSize 的大小。問題四：既然提到可以通過配置不同參數創建出不同的線程池，那么 Java 中默認實現好的線程池又有哪些呢？請比較它們的異同。 1. SingleThreadExecutor 線程池這個線程池只有一個核心線程在工作，也就是相當于單線程串行執行所有任務。如果這個唯一的線程因為異常結束，那么會有一個新的線程來替代它。此線程池保證所有任務的執行順序按照任務的提交順序執行。 ? corePoolSize： 1，只有一個核心線程在工作。 ? maximumPoolSize： 1。 ? keepAliveTime： 0L。 ? workQueue： new LinkedBlockingQueue()，其緩沖隊列是無界的。 2. FixedThreadPool 線程池 FixedThreadPool 是固定大小的線程池，只有核心線程。每次提交一個任務就創建一個線程，直到線程達到線程池的最大大小。線程池的大小一旦達到最大值就會保持不變，如果某個線程因為執行異常而結束，那么線程池會補充一個新線程。 FixedThreadPool 多數針對一些很穩定很固定的正規并發線程，多用于服務器。 ? corePoolSize： nThreads ? maximumPoolSize： nThreads ? keepAliveTime： 0L ? workQueue： new LinkedBlockingQueue()，其緩沖隊列是無界的。 3. CachedThreadPool 線程池 CachedThreadPool 是無界線程池，如果線程池的大小超過了處理任務所需要的線程，那么就會回收部分空閑（ 60 秒不執行任務）線程，當任務數增加時，此線程池又可以智能的添加新線程來處理任務。線程池大小完全依賴于操作系統（或者說 JVM）能夠創建的最大線程大小。 SynchronousQueue 是一個是緩沖區為 1 的阻塞隊列。緩存型池子通常用于執行一些生存期很短的異步型任務，因此在一些面向連接的 daemon 型 SERVER 中用得不多。但對于生存期短的異步任務，它是 Executor 的首選。 ? corePoolSize： 0 ? maximumPoolSize： Integer.MAX_VALUE ? keepAliveTime： 60L ? workQueue： new SynchronousQueue()，一個是緩沖區為 1 的阻塞隊列。 4. ScheduledThreadPool 線程池 ScheduledThreadPool：核心線程池固定，大小無限的線程池。此線程池支持定時以及周期性執行任務的需求。創建一個周期性執行任務的線程池。如果閑置，非核心線程池會在 DEFAULT_KEEPALIVEMILLIS 時間內回收。 ? corePoolSize： corePoolSize ? maximumPoolSize： Integer.MAX_VALUE ? keepAliveTime： DEFAULT_KEEPALIVE_MILLIS ? workQueue： new DelayedWorkQueue() 問題六：如何在 Java 線程池中提交線程？線程池最常用的提交任務的方法有兩種： 1. execute()： ExecutorService.execute 方法接收一個 Runable 實例，它用來執行一個任務： · 2. submit()： ExecutorService.submit() 方法返回的是 Future 對象。可以用 isDone() 來查詢 Future 是否已經完成，當任務完成時，它具有一個結果，可以調用 get() 來獲取結果。也可以不用 isDone() 進行檢查就直接調用 get()，在這種情況下， get() 將阻塞，直至結果準備就緒。 Java 內存模型相關問題問題一：什么是 Java 的內存模型， Java 中各個線程是怎么彼此看到對方的變量的？ Java 的內存模型定義了程序中各個變量的訪問規則，即在虛擬機中將變量存儲到內存和從內存中取出這樣的底層細節。此處的變量包括實例字段、靜態字段和構成數組對象的元素，但是不包括局部變量和方法參數，因為這些是線程私有的，不會被共享，所以不存在競爭問題。 Java 中各個線程是怎么彼此看到對方的變量的呢？ Java 中定義了主內存與工作內存的概念：所有的變量都存儲在主內存，每條線程還有自己的工作內存，保存了被該線程使用到的變量的主內存副本拷貝。線程對變量的所有操作（讀取、賦值）都必須在工作內存中進行，不能直接讀寫主內存的變量。不同的線程之間也無法直接訪問對方工作內存的變量，線程間變量值的傳遞需要通過主內存。問題二：請談談 volatile 有什么特點，為什么它能保證變量對所有線程的可見性？關鍵字 volatile 是 Java 虛擬機提供的最輕量級的同步機制。當一個變量被定義成 volatile 之后，具備兩種特性： 1. 保證此變量對所有線程的可見性。當一條線程修改了這個變量的值，新值對于其他線程是可以立即得知的。而普通變量做不到這一點。 2. 禁止指令重排序優化。普通變量僅僅能保證在該方法執行過程中，得到正確結果，但是不保證程序代碼的執行順序。 Java 的內存模型定義了 8 種內存間操作： lock 和 unlock ? 把一個變量標識為一條線程獨占的狀態。 ? 把一個處于鎖定狀態的變量釋放出來，釋放之后的變量才能被其他線程鎖定。 read 和 write ? 把一個變量值從主內存傳輸到線程的工作內存，以便 load。 ? 把 store 操作從工作內存得到的變量的值，放入主內存的變量中。 load 和 store ? 把 read 操作從主內存得到的變量值放入工作內存的變量副本中。 ? 把工作內存的變量值傳送到主內存，以便 write。 use 和 assgin ? 把工作內存變量值傳遞給執行引擎。 ? 將執行引擎值傳遞給工作內存變量值。 volatile 的實現基于這 8 種內存間操作，保證了一個線程對某個 volatile 變量的修改，一定會被另一個線程看見，即保證了可見性。問題三：既然 volatile 能夠保證線程間的變量可見性，是不是就意味著基于 volatile 變量的運算就是并發安全的？顯然不是的。基于 volatile 變量的運算在并發下不一定是安全的。 volatile 變量在各個線程的工作內存，不存在一致性問題（各個線程的工作內存中 volatile 變量，每次使用前都要刷新到主內存）。但是 Java 里面的運算并非原子操作，導致 volatile 變量的運算在并發下一樣是不安全的。問題四：請對比下 volatile 對比 Synchronized 的異同。 Synchronized 既能保證可見性，又能保證原子性，而 volatile 只能保證可見性，無法保證原子性。 ThreadLocal 和 Synchonized 都用于解決多線程并發訪問，防止任務在共享資源上產生沖突。但是 ThreadLocal 與 Synchronized 有本質的區別。 Synchronized 用于實現同步機制，是利用鎖的機制使變量或代碼塊在某一時該只能被一個線程訪問，是一種 “ 以時間換空間 ” 的方式。而 ThreadLocal 為每一個線程都提供了變量的副本，使得每個線程在某一時間訪問到的并不是同一個對象，根除了對變量的共享，是一種 “ 以空間換時間 ” 的方式。問題五：請談談 ThreadLocal 是怎么解決并發安全的？ ThreadLocal 這是 Java 提供的一種保存線程私有信息的機制，因為其在整個線程生命周期內有效，所以可以方便地在一個線程關聯的不同業務模塊之間傳遞信息，比如事務 ID、 Cookie 等上下文相關信息。 ThreadLocal 為每一個線程維護變量的副本，把共享數據的可見范圍限制在同一個線程之內，其實現原理是，在 ThreadLocal 類中有一個 Map，用于存儲每一個線程的變量的副本。問題六：很多人都說要慎用 ThreadLocal，談談你的理解，使用 ThreadLocal 需要注意些什么？使用 ThreadLocal 要注意 remove！ ThreadLocal 的實現是基于一個所謂的 ThreadLocalMap，在 ThreadLocalMap 中，它的 key 是一個弱引用。通常弱引用都會和引用隊列配合清理機制使用，但是 ThreadLocal 是個例外，它并沒有這么做。這意味著，廢棄項目的回收依賴于顯式地觸發，否則就要等待線程結束，進而回收相應 ThreadLocalMap！這就是很多 OOM 的來源，所以通常都會建議，應用一定要自己負責 remove，并且不要和線程池配合，因為 worker 線程往往是不會退出的。

總結

以上是生活随笔為你收集整理的面试-多线程进阶篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇：智能家居控制系统制作技术_智能家居控制系
下一篇：怎么使用JavaScript进行进制…