Java併發編程面試題彙總

 個人博客請訪問 http://www.x0100.top   

基礎知識

併發編程的優缺點

爲什麼要使用併發編程（併發編程的優點）

• 充分利用多核CPU的計算能力：通過併發編程的形式可以將多核CPU的計算能力發揮到極致，性能得到提升

• 方便進行業務拆分，提升系統併發能力和性能：在特殊的業務場景下，先天的就適合於併發編程。現在的系統動不動就要求百萬級甚至千萬級的併發量，而多線程併發編程正是開發高併發系統的基礎，利用好多線程機制可以大大提高系統整體的併發能力以及性能。面對複雜業務模型，並行程序會比串行程序更適應業務需求，而併發編程更能吻合這種業務拆分 。

併發編程有什麼缺點

併發編程的目的就是爲了能提高程序的執行效率，提高程序運行速度，但是併發編程並不總是能提高程序運行速度的，而且併發編程可能會遇到很多問題，比如**：內存泄漏、上下文切換、線程安全、死鎖**等問題。

併發編程三要素是什麼？在 Java 程序中怎麼保證多線程的運行安全？

併發編程三要素（線程的安全性問題體現在）：

原子性：原子，即一個不可再被分割的顆粒。原子性指的是一個或多個操作要麼全部執行成功要麼全部執行失敗。

可見性：一個線程對共享變量的修改,另一個線程能夠立刻看到。（synchronized,volatile）

有序性：程序執行的順序按照代碼的先後順序執行。（處理器可能會對指令進行重排序）

出現線程安全問題的原因：

• 線程切換帶來的原子性問題

• 緩存導致的可見性問題

• 編譯優化帶來的有序性問題

解決辦法：

• JDK Atomic開頭的原子類、synchronized、LOCK，可以解決原子性問題

• synchronized、volatile、LOCK，可以解決可見性問題

• Happens-Before 規則可以解決有序性問題

並行和併發有什麼區別？

• 併發：多個任務在同一個 CPU 核上，按細分的時間片輪流(交替)執行，從邏輯上來看那些任務是同時執行。

• 並行：單位時間內，多個處理器或多核處理器同時處理多個任務，是真正意義上的“同時進行”。

• 串行：有n個任務，由一個線程按順序執行。由於任務、方法都在一個線程執行所以不存在線程不安全情況，也就不存在臨界區的問題。

做一個形象的比喻：

併發 = 兩個隊列和一臺咖啡機。

並行 = 兩個隊列和兩臺咖啡機。

串行 = 一個隊列和一臺咖啡機。

什麼是多線程，多線程的優劣？

多線程：多線程是指程序中包含多個執行流，即在一個程序中可以同時運行多個不同的線程來執行不同的任務。

多線程的好處：

可以提高 CPU 的利用率。在多線程程序中，一個線程必須等待的時候，CPU 可以運行其它的線程而不是等待，這樣就大大提高了程序的效率。也就是說允許單個程序創建多個並行執行的線程來完成各自的任務。

多線程的劣勢：

• 線程也是程序，所以線程需要佔用內存，線程越多佔用內存也越多；

• 多線程需要協調和管理，所以需要 CPU 時間跟蹤線程；

• 線程之間對共享資源的訪問會相互影響，必須解決競用共享資源的問題。

線程和進程區別

什麼是線程和進程?

進程

一個在內存中運行的應用程序。每個進程都有自己獨立的一塊內存空間，一個進程可以有多個線程，比如在Windows系統中，一個運行的xx.exe就是一個進程。

線程

進程中的一個執行任務（控制單元），負責當前進程中程序的執行。一個進程至少有一個線程，一個進程可以運行多個線程，多個線程可共享數據。

進程與線程的區別

線程具有許多傳統進程所具有的特徵，故又稱爲輕型進程(Light—Weight Process)或進程元；而把傳統的進程稱爲重型進程(Heavy—Weight Process)，它相當於只有一個線程的任務。在引入了線程的操作系統中，通常一個進程都有若干個線程，至少包含一個線程。

根本區別：進程是操作系統資源分配的基本單位，而線程是處理器任務調度和執行的基本單位

資源開銷：每個進程都有獨立的代碼和數據空間（程序上下文），程序之間的切換會有較大的開銷；線程可以看做輕量級的進程，同一類線程共享代碼和數據空間，每個線程都有自己獨立的運行棧和程序計數器（PC），線程之間切換的開銷小。

包含關係：如果一個進程內有多個線程，則執行過程不是一條線的，而是多條線（線程）共同完成的；線程是進程的一部分，所以線程也被稱爲輕權進程或者輕量級進程。

內存分配：同一進程的線程共享本進程的地址空間和資源，而進程之間的地址空間和資源是相互獨立的

影響關係：一個進程崩潰後，在保護模式下不會對其他進程產生影響，但是一個線程崩潰整個進程都死掉。所以多進程要比多線程健壯。

執行過程：每個獨立的進程有程序運行的入口、順序執行序列和程序出口。但是線程不能獨立執行，必須依存在應用程序中，由應用程序提供多個線程執行控制，兩者均可併發執行

什麼是上下文切換?

多線程編程中一般線程的個數都大於 CPU 核心的個數，而一個 CPU 核心在任意時刻只能被一個線程使用，爲了讓這些線程都能得到有效執行，CPU 採取的策略是爲每個線程分配時間片並輪轉的形式。當一個線程的時間片用完的時候就會重新處於就緒狀態讓給其他線程使用，這個過程就屬於一次上下文切換。

概括來說就是：當前任務在執行完 CPU 時間片切換到另一個任務之前會先保存自己的狀態，以便下次再切換回這個任務時，可以再加載這個任務的狀態。任務從保存到再加載的過程就是一次上下文切換。

上下文切換通常是計算密集型的。也就是說，它需要相當可觀的處理器時間，在每秒幾十上百次的切換中，每次切換都需要納秒量級的時間。所以，上下文切換對系統來說意味着消耗大量的 CPU 時間，事實上，可能是操作系統中時間消耗最大的操作。

Linux 相比與其他操作系統（包括其他類 Unix 系統）有很多的優點，其中有一項就是，其上下文切換和模式切換的時間消耗非常少。

守護線程和用戶線程有什麼區別呢？

守護線程和用戶線程

• 用戶 (User) 線程：運行在前臺，執行具體的任務，如程序的主線程、連接網絡的子線程等都是用戶線程

• 守護 (Daemon) 線程：運行在後臺，爲其他前臺線程服務。也可以說守護線程是 JVM 中非守護線程的 “傭人”。一旦所有用戶線程都結束運行，守護線程會隨 JVM 一起結束工作

main 函數所在的線程就是一個用戶線程啊，main 函數啓動的同時在 JVM 內部同時還啓動了好多守護線程，比如垃圾回收線程。

比較明顯的區別之一是用戶線程結束，JVM 退出，不管這個時候有沒有守護線程運行。而守護線程不會影響 JVM 的退出。

注意事項：

1. setDaemon(true)必須在start()方法前執行，否則會拋出 IllegalThreadStateException 異常

2. 在守護線程中產生的新線程也是守護線程

3. 不是所有的任務都可以分配給守護線程來執行，比如讀寫操作或者計算邏輯

4. 守護 (Daemon) 線程中不能依靠 finally 塊的內容來確保執行關閉或清理資源的邏輯。因爲我們上面也說過了一旦所有用戶線程都結束運行，守護線程會隨 JVM 一起結束工作，所以守護 (Daemon) 線程中的 finally 語句塊可能無法被執行。

如何在 Windows 和 Linux 上查找哪個線程cpu利用率最高？

windows上面用任務管理器看，linux下可以用 top 這個工具看。

• 找出cpu耗用厲害的進程pid， 終端執行top命令，然後按下shift+p 查找出cpu利用最厲害的pid號

• 根據上面第一步拿到的pid號，top -H -p pid 。然後按下shift+p，查找出cpu利用率最厲害的線程號，比如top -H -p 1328

• 將獲取到的線程號轉換成16進制，去百度轉換一下就行

• 使用jstack工具將進程信息打印輸出，jstack pid號 > /tmp/t.dat，比如jstack 31365 > /tmp/t.dat

• 編輯/tmp/t.dat文件，查找線程號對應的信息

什麼是線程死鎖

百度百科：死鎖是指兩個或兩個以上的進程（線程）在執行過程中，由於競爭資源或者由於彼此通信而造成的一種阻塞的現象，若無外力作用，它們都將無法推進下去。此時稱系統處於死鎖狀態或系統產生了死鎖，這些永遠在互相等待的進程（線程）稱爲死鎖進程（線程）。

多個線程同時被阻塞，它們中的一個或者全部都在等待某個資源被釋放。由於線程被無限期地阻塞，因此程序不可能正常終止。如下圖所示，線程 A 持有資源 2，線程 B 持有資源 1，他們同時都想申請對方的資源，所以這兩個線程就會互相等待而進入死鎖狀態。

下面通過一個例子來說明線程死鎖，代碼模擬了上圖的死鎖的情況 (代碼來源於《併發編程之美》)：

public class DeadLockDemo {    private static Object resource1 = new Object();//資源 1    private static Object resource2 = new Object();//資源 2
    public static void main(String[] args) {        new Thread(() -> {            synchronized (resource1) {                System.out.println(Thread.currentThread() + "get resource1");                try {                    Thread.sleep(1000);                } catch (InterruptedException e) {                    e.printStackTrace();                }                System.out.println(Thread.currentThread() + "waiting get resource2");                synchronized (resource2) {                    System.out.println(Thread.currentThread() + "get resource2");                }            }        }, "線程 1").start();
        new Thread(() -> {            synchronized (resource2) {                System.out.println(Thread.currentThread() + "get resource2");                try {                    Thread.sleep(1000);                } catch (InterruptedException e) {                    e.printStackTrace();                }                System.out.println(Thread.currentThread() + "waiting get resource1");                synchronized (resource1) {                    System.out.println(Thread.currentThread() + "get resource1");                }            }        }, "線程 2").start();    }}

輸出結果

Thread[線程 1,5,main]get resource1Thread[線程 2,5,main]get resource2Thread[線程 1,5,main]waiting get resource2Thread[線程 2,5,main]waiting get resource1

線程 A 通過 synchronized (resource1) 獲得 resource1 的監視器鎖，然後通過Thread.sleep(1000)；讓線程 A 休眠 1s 爲的是讓線程 B 得到CPU執行權，然後獲取到 resource2 的監視器鎖。線程 A 和線程 B 休眠結束了都開始企圖請求獲取對方的資源，然後這兩個線程就會陷入互相等待的狀態，這也就產生了死鎖。上面的例子符合產生死鎖的四個必要條件。

形成死鎖的四個必要條件是什麼

• 互斥條件：線程(進程)對於所分配到的資源具有排它性，即一個資源只能被一個線程(進程)佔用，直到被該線程(進程)釋放

• 請求與保持條件：一個線程(進程)因請求被佔用資源而發生阻塞時，對已獲得的資源保持不放。

• 不剝奪條件：線程(進程)已獲得的資源在末使用完之前不能被其他線程強行剝奪，只有自己使用完畢後才釋放資源。

• 循環等待條件：當發生死鎖時，所等待的線程(進程)必定會形成一個環路（類似於死循環），造成永久阻塞

如何避免線程死鎖

我們只要破壞產生死鎖的四個條件中的其中一個就可以了。

破壞互斥條件

這個條件我們沒有辦法破壞，因爲我們用鎖本來就是想讓他們互斥的（臨界資源需要互斥訪問）。

破壞請求與保持條件

一次性申請所有的資源。

破壞不剝奪條件

佔用部分資源的線程進一步申請其他資源時，如果申請不到，可以主動釋放它佔有的資源。

破壞循環等待條件

靠按序申請資源來預防。按某一順序申請資源，釋放資源則反序釋放。破壞循環等待條件。

我們對線程 2 的代碼修改成下面這樣就不會產生死鎖了。

new Thread(() -> {    synchronized (resource1) {        System.out.println(Thread.currentThread() + "get resource1");        try {            Thread.sleep(1000);        } catch (InterruptedException e) {            e.printStackTrace();        }        System.out.println(Thread.currentThread() + "waiting get resource2");        synchronized (resource2) {            System.out.println(Thread.currentThread() + "get resource2");        }    }}, "線程 2").start();
輸出結果​​​​​​​

Thread[線程 1,5,main]get resource1Thread[線程 1,5,main]waiting get resource2Thread[線程 1,5,main]get resource2Thread[線程 2,5,main]get resource1Thread[線程 2,5,main]waiting get resource2Thread[線程 2,5,main]get resource2
我們分析一下上面的代碼爲什麼避免了死鎖的發生?

線程 1 首先獲得到 resource1 的監視器鎖，這時候線程 2 就獲取不到了。然後線程 1 再去獲取 resource2 的監視器鎖，可以獲取到。然後線程 1 釋放了對 resource1、resource2 的監視器鎖的佔用，線程 2 獲取到就可以執行了。這樣就破壞了破壞循環等待條件，因此避免了死鎖。

創建線程的四種方式

創建線程有哪幾種方式？

創建線程有四種方式：

• 繼承 Thread 類；

• 實現 Runnable 接口；

• 實現 Callable 接口；

• 使用 Executors 工具類創建線程池

繼承 Thread 類

步驟

1. 定義一個Thread類的子類，重寫run方法，將相關邏輯實現，run()方法就是線程要執行的業務邏輯方法

2. 創建自定義的線程子類對象

3. 調用子類實例的star()方法來啓動線程

public class MyThread extends Thread {
    @Override    public void run() {        System.out.println(Thread.currentThread().getName() + " run()方法正在執行...");    }
}
​​​​​​

public class TheadTest {
    public static void main(String[] args) {        MyThread myThread = new MyThread();           myThread.start();        System.out.println(Thread.currentThread().getName() + " main()方法執行結束");    }
}

運行結果​​​​​​​

main main()方法執行結束Thread-0 run()方法正在執行...

實現 Runnable 接口

步驟

1. 定義Runnable接口實現類MyRunnable，並重寫run()方法

2. 創建MyRunnable實例myRunnable，以myRunnable作爲target創建Thead對象，該Thread對象纔是真正的線程對象

3. 調用線程對象的start()方法

public class MyRunnable implements Runnable {
    @Override    public void run() {        System.out.println(Thread.currentThread().getName() + " run()方法執行中...");    }
}
​​​​​​

public class RunnableTest {
    public static void main(String[] args) {        MyRunnable myRunnable = new MyRunnable();        Thread thread = new Thread(myRunnable);        thread.start();        System.out.println(Thread.currentThread().getName() + " main()方法執行完成");    }
}

執行結果​​​​​​​​​​​​​​

main main()方法執行完成Thread-0 run()方法執行中...

實現 Callable 接口

步驟

1. 創建實現Callable接口的類myCallable

2. 以myCallable爲參數創建FutureTask對象

3. 將FutureTask作爲參數創建Thread對象

4. 調用線程對象的start()方法

public class MyCallable implements Callable<Integer> {
    @Override    public Integer call() {        System.out.println(Thread.currentThread().getName() + " call()方法執行中...");        return 1;    }
}
​​​​​​

public class CallableTest {
    public static void main(String[] args) {        FutureTask<Integer> futureTask = new FutureTask<Integer>(new MyCallable());        Thread thread = new Thread(futureTask);        thread.start();
        try {            Thread.sleep(1000);            System.out.println("返回結果 " + futureTask.get());        } catch (InterruptedException e) {            e.printStackTrace();        } catch (ExecutionException e) {            e.printStackTrace();        }        System.out.println(Thread.currentThread().getName() + " main()方法執行完成");    }
}

執行結果​​​​​​​

Thread-0 call()方法執行中...返回結果 1main main()方法執行完成

使用 Executors 工具類創建線程池

 

Executors提供了一系列工廠方法用於創先線程池，返回的線程池都實現了ExecutorService接口。

 

主要有newFixedThreadPool，newCachedThreadPool，newSingleThreadExecutor，newScheduledThreadPool，後續詳細介紹這四種線程池​​​​​​​

public class MyRunnable implements Runnable {
    @Override    public void run() {        System.out.println(Thread.currentThread().getName() + " run()方法執行中...");    }
}
​​​​​​​

public class SingleThreadExecutorTest {
    public static void main(String[] args) {        ExecutorService executorService = Executors.newSingleThreadExecutor();        MyRunnable runnableTest = new MyRunnable();        for (int i = 0; i < 5; i++) {            executorService.execute(runnableTest);        }
        System.out.println("線程任務開始執行");        executorService.shutdown();    }
}

執行結果​​​​​​​

線程任務開始執行pool-1-thread-1 is running...pool-1-thread-1 is running...pool-1-thread-1 is running...pool-1-thread-1 is running...pool-1-thread-1 is running...

說一下 runnable 和 callable 有什麼區別？

相同點

• 都是接口

• 都可以編寫多線程程序

• 都採用Thread.start()啓動線程

主要區別

• Runnable 接口 run 方法無返回值；Callable 接口 call 方法有返回值，是個泛型，和Future、FutureTask配合可以用來獲取異步執行的結果

• Runnable 接口 run 方法只能拋出運行時異常，且無法捕獲處理；Callable 接口 call 方法允許拋出異常，可以獲取異常信息

注：Callalbe接口支持返回執行結果，需要調用FutureTask.get()得到，此方法會阻塞主進程的繼續往下執行，如果不調用不會阻塞。

 

線程的 run()和 start()有什麼區別？

每個線程都是通過某個特定Thread對象所對應的方法run()來完成其操作的，run()方法稱爲線程體。通過調用Thread類的start()方法來啓動一個線程。

 

start() 方法用於啓動線程，run() 方法用於執行線程的運行時代碼。run() 可以重複調用，而 start() 只能調用一次。

 

start()方法來啓動一個線程，真正實現了多線程運行。調用start()方法無需等待run方法體代碼執行完畢，可以直接繼續執行其他的代碼；此時線程是處於就緒狀態，並沒有運行。然後通過此Thread類調用方法run()來完成其運行狀態， run()方法運行結束， 此線程終止。然後CPU再調度其它線程。

 

run()方法是在本線程裏的，只是線程裏的一個函數，而不是多線程的。如果直接調用run()，其實就相當於是調用了一個普通函數而已，直接待用run()方法必須等待run()方法執行完畢才能執行下面的代碼，所以執行路徑還是隻有一條，根本就沒有線程的特徵，所以在多線程執行時要使用start()方法而不是run()方法。

 

爲什麼我們調用 start() 方法時會執行 run() 方法，爲什麼我們不能直接調用 run() 方法？

這是另一個非常經典的 java 多線程面試問題，而且在面試中會經常被問到。很簡單，但是很多人都會答不上來！

 

new 一個 Thread，線程進入了新建狀態。調用 start() 方法，會啓動一個線程並使線程進入了就緒狀態，當分配到時間片後就可以開始運行了。start() 會執行線程的相應準備工作，然後自動執行 run() 方法的內容，這是真正的多線程工作。

 

而直接執行 run() 方法，會把 run 方法當成一個 main 線程下的普通方法去執行，並不會在某個線程中執行它，所以這並不是多線程工作。

 

總結：調用 start 方法方可啓動線程並使線程進入就緒狀態，而 run 方法只是 thread 的一個普通方法調用，還是在主線程裏執行。

 

什麼是 Callable 和 Future?

Callable 接口類似於 Runnable，從名字就可以看出來了，但是 Runnable 不會返回結果，並且無法拋出返回結果的異常，而 Callable 功能更強大一些，被線程執行後，可以返回值，這個返回值可以被 Future 拿到，也就是說，Future 可以拿到異步執行任務的返回值。

 

Future 接口表示異步任務，是一個可能還沒有完成的異步任務的結果。所以說 Callable用於產生結果，Future 用於獲取結果。

 

什麼是 FutureTask

FutureTask 表示一個異步運算的任務。FutureTask 裏面可以傳入一個 Callable 的具體實現類，可以對這個異步運算的任務的結果進行等待獲取、判斷是否已經完成、取消任務等操作。只有當運算完成的時候結果才能取回，如果運算尚未完成 get 方法將會阻塞。一個 FutureTask 對象可以對調用了 Callable 和 Runnable 的對象進行包裝，由於 FutureTask 也是Runnable 接口的實現類，所以 FutureTask 也可以放入線程池中。

 

線程的狀態和基本操作

說說線程的生命週期及五種基本狀態？

• 新建(new)：新創建了一個線程對象。

   

• 可運行(runnable)：線程對象創建後，當調用線程對象的 start()方法，該線程處於就緒狀態，等待被線程調度選中，獲取cpu的使用權。

   

• 運行(running)：可運行狀態(runnable)的線程獲得了cpu時間片（timeslice），執行程序代碼。注：就緒狀態是進入到運行狀態的唯一入口，也就是說，線程要想進入運行狀態執行，首先必須處於就緒狀態中；

   

• 阻塞(block)：處於運行狀態中的線程由於某種原因，暫時放棄對 CPU的使用權，停止執行，此時進入阻塞狀態，直到其進入到就緒狀態，才 有機會再次被 CPU 調用以進入到運行狀態。

   

  阻塞的情況分三種：

  (一). 等待阻塞：運行狀態中的線程執行 wait()方法，JVM會把該線程放入等待隊列(waitting queue)中，使本線程進入到等待阻塞狀態；

  (二). 同步阻塞：線程在獲取 synchronized 同步鎖失敗(因爲鎖被其它線程所佔用)，，則JVM會把該線程放入鎖池(lock pool)中，線程會進入同步阻塞狀態；

  (三). 其他阻塞: 通過調用線程的 sleep()或 join()或發出了 I/O 請求時，線程會進入到阻塞狀態。當 sleep()狀態超時、join()等待線程終止或者超時、或者 I/O 處理完畢時，線程重新轉入就緒狀態。

   

• 死亡(dead)：線程run()、main()方法執行結束，或者因異常退出了run()方法，則該線程結束生命週期。死亡的線程不可再次復生。

 

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

計算機通常只有一個 CPU，在任意時刻只能執行一條機器指令，每個線程只有獲得CPU 的使用權才能執行指令。所謂多線程的併發運行，其實是指從宏觀上看，各個線程輪流獲得 CPU 的使用權，分別執行各自的任務。在運行池中，會有多個處於就緒狀態的線程在等待 CPU，JAVA 虛擬機的一項任務就是負責線程的調度，線程調度是指按照特定機制爲多個線程分配 CPU 的使用權。

 

有兩種調度模型：分時調度模型和搶佔式調度模型。

 

分時調度模型是指讓所有的線程輪流獲得 cpu 的使用權，並且平均分配每個線程佔用的 CPU 的時間片這個也比較好理解。

 

Java虛擬機採用搶佔式調度模型，是指優先讓可運行池中優先級高的線程佔用CPU，如果可運行池中的線程優先級相同，那麼就隨機選擇一個線程，使其佔用CPU。處於運行狀態的線程會一直運行，直至它不得不放棄 CPU。

 

線程的調度策略

線程調度器選擇優先級最高的線程運行，但是，如果發生以下情況，就會終止線程的運行：

（1）線程體中調用了 yield 方法讓出了對 cpu 的佔用權利

（2）線程體中調用了 sleep 方法使線程進入睡眠狀態

（3）線程由於 IO 操作受到阻塞

（4）另外一個更高優先級線程出現

（5）在支持時間片的系統中，該線程的時間片用完

什麼是線程調度器(Thread Scheduler)和時間分片(Time Slicing )？

線程調度器是一個操作系統服務，它負責爲 Runnable 狀態的線程分配 CPU 時間。一旦我們創建一個線程並啓動它，它的執行便依賴於線程調度器的實現。

 

時間分片是指將可用的 CPU 時間分配給可用的 Runnable 線程的過程。分配 CPU 時間可以基於線程優先級或者線程等待的時間。

 

線程調度並不受到 Java 虛擬機控制，所以由應用程序來控制它是更好的選擇（也就是說不要讓你的程序依賴於線程的優先級）。

 

請說出與線程同步以及線程調度相關的方法。

（1） wait()：使一個線程處於等待（阻塞）狀態，並且釋放所持有的對象的鎖；

 

（2）sleep()：使一個正在運行的線程處於睡眠狀態，是一個靜態方法，調用此方法要處理 InterruptedException 異常；

 

（3）notify()：喚醒一個處於等待狀態的線程，當然在調用此方法的時候，並不能確切的喚醒某一個等待狀態的線程，而是由 JVM 確定喚醒哪個線程，而且與優先級無關；

 

（4）notityAll()：喚醒所有處於等待狀態的線程，該方法並不是將對象的鎖給所有線程，而是讓它們競爭，只有獲得鎖的線程才能進入就緒狀態；

 

sleep() 和 wait() 有什麼區別？

兩者都可以暫停線程的執行

• 類的不同：sleep() 是 Thread線程類的靜態方法，wait() 是 Object類的方法。

• 是否釋放鎖：sleep() 不釋放鎖；wait() 釋放鎖。

• 用途不同：Wait 通常被用於線程間交互/通信，sleep 通常被用於暫停執行。

• 用法不同：wait() 方法被調用後，線程不會自動甦醒，需要別的線程調用同一個對象上的 notify() 或者 notifyAll() 方法。sleep() 方法執行完成後，線程會自動甦醒。或者可以使用wait(long timeout)超時後線程會自動甦醒。

 

你是如何調用 wait() 方法的？使用 if 塊還是循環？爲什麼？

處於等待狀態的線程可能會收到錯誤警報和僞喚醒，如果不在循環中檢查等待條件，程序就會在沒有滿足結束條件的情況下退出。

 

wait() 方法應該在循環調用，因爲當線程獲取到 CPU 開始執行的時候，其他條件可能還沒有滿足，所以在處理前，循環檢測條件是否滿足會更好。下面是一段標準的使用 wait 和 notify 方法的代碼：​​​​​​​

synchronized (monitor) {    //  判斷條件謂詞是否得到滿足    while(!locked) {        //  等待喚醒        monitor.wait();    }    //  處理其他的業務邏輯}

爲什麼線程通信的方法 wait(), notify()和 notifyAll()被定義在 Object 類裏？

Java中，任何對象都可以作爲鎖，並且 wait()，notify()等方法用於等待對象的鎖或者喚醒線程，在 Java 的線程中並沒有可供任何對象使用的鎖，所以任意對象調用方法一定定義在Object類中。

 

wait(), notify()和 notifyAll()這些方法在同步代碼塊中調用

 

有的人會說，既然是線程放棄對象鎖，那也可以把wait()定義在Thread類裏面啊，新定義的線程繼承於Thread類，也不需要重新定義wait()方法的實現。然而，這樣做有一個非常大的問題，一個線程完全可以持有很多鎖，你一個線程放棄鎖的時候，到底要放棄哪個鎖？當然了，這種設計並不是不能實現，只是管理起來更加複雜。

 

綜上所述，wait()、notify()和notifyAll()方法要定義在Object類中。

 

爲什麼 wait(), notify()和 notifyAll()必須在同步方法或者同步塊中被調用？

當一個線程需要調用對象的 wait()方法的時候，這個線程必須擁有該對象的鎖，接着它就會釋放這個對象鎖並進入等待狀態直到其他線程調用這個對象上的 notify()方法。同樣的，當一個線程需要調用對象的 notify()方法時，它會釋放這個對象的鎖，以便其他在等待的線程就可以得到這個對象鎖。由於所有的這些方法都需要線程持有對象的鎖，這樣就只能通過同步來實現，所以他們只能在同步方法或者同步塊中被調用。

 

Thread 類中的 yield 方法有什麼作用？

使當前線程從執行狀態（運行狀態）變爲可執行態（就緒狀態）。

 

當前線程到了就緒狀態，那麼接下來哪個線程會從就緒狀態變成執行狀態呢？可能是當前線程，也可能是其他線程，看系統的分配了。

 

爲什麼 Thread 類的 sleep()和 yield ()方法是靜態的？

Thread 類的 sleep()和 yield()方法將在當前正在執行的線程上運行。所以在其他處於等待狀態的線程上調用這些方法是沒有意義的。這就是爲什麼這些方法是靜態的。它們可以在當前正在執行的線程中工作，並避免程序員錯誤的認爲可以在其他非運行線程調用這些方法。

 

線程的 sleep()方法和 yield()方法有什麼區別？

（1） sleep()方法給其他線程運行機會時不考慮線程的優先級，因此會給低優先級的線程以運行的機會；yield()方法只會給相同優先級或更高優先級的線程以運行的機會；

 

（2） 線程執行 sleep()方法後轉入阻塞（blocked）狀態，而執行 yield()方法後轉入就緒（ready）狀態；

 

（3）sleep()方法聲明拋出 InterruptedException，而 yield()方法沒有聲明任何異常；

 

（4）sleep()方法比 yield()方法（跟操作系統 CPU 調度相關）具有更好的可移植性，通常不建議使用yield()方法來控制併發線程的執行。

 

如何停止一個正在運行的線程？

在java中有以下3種方法可以終止正在運行的線程：

1. 使用退出標誌，使線程正常退出，也就是當run方法完成後線程終止。

2. 使用stop方法強行終止，但是不推薦這個方法，因爲stop和suspend及resume一樣都是過期作廢的方法。

3. 使用interrupt方法中斷線程。

Java 中 interrupted 和 isInterrupted 方法的區別？

interrupt：用於中斷線程。調用該方法的線程的狀態爲將被置爲”中斷”狀態。

 

注意：線程中斷僅僅是置線程的中斷狀態位，不會停止線程。需要用戶自己去監視線程的狀態爲並做處理。支持線程中斷的方法（也就是線程中斷後會拋出interruptedException 的方法）就是在監視線程的中斷狀態，一旦線程的中斷狀態被置爲“中斷狀態”，就會拋出中斷異常。

 

interrupted：是靜態方法，查看當前中斷信號是true還是false並且清除中斷信號。如果一個線程被中斷了，第一次調用 interrupted 則返回 true，第二次和後面的就返回 false 了。

 

isInterrupted：查看當前中斷信號是true還是false

 

什麼是阻塞式方法？

阻塞式方法是指程序會一直等待該方法完成期間不做其他事情，ServerSocket 的accept()方法就是一直等待客戶端連接。這裏的阻塞是指調用結果返回之前，當前線程會被掛起，直到得到結果之後纔會返回。此外，還有異步和非阻塞式方法在任務完成前就返回。

 

Java 中你怎樣喚醒一個阻塞的線程？

首先 ，wait()、notify() 方法是針對對象的，調用任意對象的 wait()方法都將導致線程阻塞，阻塞的同時也將釋放該對象的鎖，相應地，調用任意對象的 notify()方法則將隨機解除該對象阻塞的線程，但它需要重新獲取該對象的鎖，直到獲取成功才能往下執行；

 

其次，wait、notify 方法必須在 synchronized 塊或方法中被調用，並且要保證同步塊或方法的鎖對象與調用 wait、notify 方法的對象是同一個，如此一來在調用 wait 之前當前線程就已經成功獲取某對象的鎖，執行 wait 阻塞後當前線程就將之前獲取的對象鎖釋放。

 

notify() 和 notifyAll() 有什麼區別？

如果線程調用了對象的 wait()方法，那麼線程便會處於該對象的等待池中，等待池中的線程不會去競爭該對象的鎖。

 

notifyAll() 會喚醒所有的線程，notify() 只會喚醒一個線程。

 

notifyAll() 調用後，會將全部線程由等待池移到鎖池，然後參與鎖的競爭，競爭成功則繼續執行，如果不成功則留在鎖池等待鎖被釋放後再次參與競爭。而 notify()只會喚醒一個線程，具體喚醒哪一個線程由虛擬機控制。

 

如何在兩個線程間共享數據？

在兩個線程間共享變量即可實現共享。

 

一般來說，共享變量要求變量本身是線程安全的，然後在線程內使用的時候，如果有對共享變量的複合操作，那麼也得保證複合操作的線程安全性。

 

Java 如何實現多線程之間的通訊和協作？

可以通過中斷 和 共享變量的方式實現線程間的通訊和協作

 

比如說最經典的生產者-消費者模型：當隊列滿時，生產者需要等待隊列有空間才能繼續往裏面放入商品，而在等待的期間內，生產者必須釋放對臨界資源（即隊列）的佔用權。因爲生產者如果不釋放對臨界資源的佔用權，那麼消費者就無法消費隊列中的商品，就不會讓隊列有空間，那麼生產者就會一直無限等待下去。因此，一般情況下，當隊列滿時，會讓生產者交出對臨界資源的佔用權，並進入掛起狀態。然後等待消費者消費了商品，然後消費者通知生產者隊列有空間了。同樣地，當隊列空時，消費者也必須等待，等待生產者通知它隊列中有商品了。這種互相通信的過程就是線程間的協作。

 

Java中線程通信協作的最常見的兩種方式：

 

一.syncrhoized加鎖的線程的Object類的wait()/notify()/notifyAll()

 

二.ReentrantLock類加鎖的線程的Condition類的await()/signal()/signalAll()

 

線程間直接的數據交換：

 

三.通過管道進行線程間通信：1）字節流；2）字符流

 

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

同步塊是更好的選擇，因爲它不會鎖住整個對象（當然你也可以讓它鎖住整個對象）。同步方法會鎖住整個對象，哪怕這個類中有多個不相關聯的同步塊，這通常會導致他們停止執行並需要等待獲得這個對象上的鎖。

 

同步塊更要符合開放調用的原則，只在需要鎖住的代碼塊鎖住相應的對象，這樣從側面來說也可以避免死鎖。

 

請知道一條原則：同步的範圍越小越好。

 

什麼是線程同步和線程互斥，有哪幾種實現方式？

當一個線程對共享的數據進行操作時，應使之成爲一個”原子操作“，即在沒有完成相關操作之前，不允許其他線程打斷它，否則，就會破壞數據的完整性，必然會得到錯誤的處理結果，這就是線程的同步。

 

在多線程應用中，考慮不同線程之間的數據同步和防止死鎖。當兩個或多個線程之間同時等待對方釋放資源的時候就會形成線程之間的死鎖。爲了防止死鎖的發生，需要通過同步來實現線程安全。

 

線程互斥是指對於共享的進程系統資源，在各單個線程訪問時的排它性。當有若干個線程都要使用某一共享資源時，任何時刻最多隻允許一個線程去使用，其它要使用該資源的線程必須等待，直到佔用資源者釋放該資源。線程互斥可以看成是一種特殊的線程同步。

 

線程間的同步方法大體可分爲兩類：用戶模式和內核模式。顧名思義，內核模式就是指利用系統內核對象的單一性來進行同步，使用時需要切換內核態與用戶態，而用戶模式就是不需要切換到內核態，只在用戶態完成操作。

 

用戶模式下的方法有：原子操作（例如一個單一的全局變量），臨界區。內核模式下的方法有：事件，信號量，互斥量。

 

實現線程同步的方法

• 同步代碼方法：sychronized 關鍵字修飾的方法

   

• 同步代碼塊：sychronized 關鍵字修飾的代碼塊

   

• 使用特殊變量域volatile實現線程同步：volatile關鍵字爲域變量的訪問提供了一種免鎖機制

   

• 使用重入鎖實現線程同步：reentrantlock類是可衝入、互斥、實現了lock接口的鎖他與sychronized方法具有相同的基本行爲和語義

 

在監視器(Monitor)內部，是如何做線程同步的？程序應該做哪種級別的同步？

在 java 虛擬機中，每個對象( Object 和 class )通過某種邏輯關聯監視器,每個監視器和一個對象引用相關聯，爲了實現監視器的互斥功能，每個對象都關聯着一把鎖。

 

一旦方法或者代碼塊被 synchronized 修飾，那麼這個部分就放入了監視器的監視區域，確保一次只能有一個線程執行該部分的代碼，線程在獲取鎖之前不允許執行該部分的代碼

 

另外 java 還提供了顯式監視器( Lock )和隱式監視器( synchronized )兩種鎖方案

 

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

這裏區分一下：

 

（1）如果使用的是無界隊列 LinkedBlockingQueue，也就是無界隊列的話，沒關係，繼續添加任務到阻塞隊列中等待執行，因爲 LinkedBlockingQueue 可以近乎認爲是一個無窮大的隊列，可以無限存放任務

 

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

 

什麼叫線程安全？servlet 是線程安全嗎?

線程安全是編程中的術語，指某個方法在多線程環境中被調用時，能夠正確地處理多個線程之間的共享變量，使程序功能正確完成。

 

Servlet 不是線程安全的，servlet 是單實例多線程的，當多個線程同時訪問同一個方法，是不能保證共享變量的線程安全性的。

 

Struts2 的 action 是多實例多線程的，是線程安全的，每個請求過來都會 new 一個新的 action 分配給這個請求，請求完成後銷燬。

 

SpringMVC 的 Controller 是線程安全的嗎？不是的，和 Servlet 類似的處理流程。

 

Struts2 好處是不用考慮線程安全問題；Servlet 和 SpringMVC 需要考慮線程安全問題，但是性能可以提升不用處理太多的 gc，可以使用 ThreadLocal 來處理多線程的問題。

 

在 Java 程序中怎麼保證多線程的運行安全？

• 方法一：使用安全類，比如 java.util.concurrent 下的類，使用原子類AtomicInteger

• 方法二：使用自動鎖 synchronized。

• 方法三：使用手動鎖 Lock。

手動鎖 Java 示例代碼如下：​​​​​​​

Lock lock = new ReentrantLock();lock. lock();try {    System. out. println("獲得鎖");} catch (Exception e) {    // TODO: handle exception} finally {    System. out. println("釋放鎖");    lock. unlock();}

你對線程優先級的理解是什麼？

每一個線程都是有優先級的，一般來說，高優先級的線程在運行時會具有優先權，但這依賴於線程調度的實現，這個實現是和操作系統相關的(OS dependent)。我們可以定義線程的優先級，但是這並不能保證高優先級的線程會在低優先級的線程前執行。線程優先級是一個 int 變量(從 1-10)，1 代表最低優先級，10 代表最高優先級。

 

Java 的線程優先級調度會委託給操作系統去處理，所以與具體的操作系統優先級有關，如非特別需要，一般無需設置線程優先級。

 

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

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

 

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

 

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

 

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

 

Java 中怎麼獲取一份線程 dump 文件？你如何在 Java 中獲取線程堆棧？

Dump文件是進程的內存鏡像。可以把程序的執行狀態通過調試器保存到dump文件中。

 

在 Linux 下，你可以通過命令 kill -3 PID （Java 進程的進程 ID）來獲取 Java應用的 dump 文件。

 

在 Windows 下，你可以按下 Ctrl + Break 來獲取。這樣 JVM 就會將線程的 dump 文件打印到標準輸出或錯誤文件中，它可能打印在控制檯或者日誌文件中，具體位置依賴應用的配置。

 

一個線程運行時發生異常會怎樣？

如果異常沒有被捕獲該線程將會停止執行。Thread.UncaughtExceptionHandler是用於處理未捕獲異常造成線程突然中斷情況的一個內嵌接口。當一個未捕獲異常將造成線程中斷的時候，JVM 會使用 Thread.getUncaughtExceptionHandler()來查詢線程的 UncaughtExceptionHandler 並將線程和異常作爲參數傳遞給 handler 的 uncaughtException()方法進行處理。

 

Java 線程數過多會造成什麼異常？

• 線程的生命週期開銷非常高

   

• 消耗過多的 CPU

   

• 資源如果可運行的線程數量多於可用處理器的數量，那麼有線程將會被閒置。大量空閒的線程會佔用許多內存，給垃圾回收器帶來壓力，而且大量的線程在競爭 CPU資源時還將產生其他性能的開銷。

   

• 降低穩定性JVM

   

• 在可創建線程的數量上存在一個限制，這個限制值將隨着平臺的不同而不同，並且承受着多個因素制約，包括 JVM 的啓動參數、Thread 構造函數中請求棧的大小，以及底層操作系統對線程的限制等。如果破壞了這些限制，那麼可能拋出OutOfMemoryError 異常。

 

併發理論

Java內存模型

Java中垃圾回收有什麼目的？什麼時候進行垃圾回收？

垃圾回收是在內存中存在沒有引用的對象或超過作用域的對象時進行的。

 

垃圾回收的目的是識別並且丟棄應用不再使用的對象來釋放和重用資源。

 

如果對象的引用被置爲null，垃圾收集器是否會立即釋放對象佔用的內存？

不會，在下一個垃圾回調週期中，這個對象將是被可回收的。

 

也就是說並不會立即被垃圾收集器立刻回收，而是在下一次垃圾回收時纔會釋放其佔用的內存。

 

finalize()方法什麼時候被調用？析構函數(finalization)的目的是什麼？

1）垃圾回收器（garbage colector）決定回收某對象時，就會運行該對象的finalize()方法；

finalize是Object類的一個方法，該方法在Object類中的聲明protected void finalize() throws Throwable { }

在垃圾回收器執行時會調用被回收對象的finalize()方法，可以覆蓋此方法來實現對其資源的回收。注意：一旦垃圾回收器準備釋放對象佔用的內存，將首先調用該對象的finalize()方法，並且下一次垃圾回收動作發生時，才真正回收對象佔用的內存空間

 

2）GC本來就是內存回收了，應用還需要在finalization做什麼呢？答案是大部分時候，什麼都不用做(也就是不需要重載)。只有在某些很特殊的情況下，比如你調用了一些native的方法(一般是C寫的)，可以要在finaliztion裏去調用C的釋放函數。

 

重排序與數據依賴性

爲什麼代碼會重排序？

在執行程序時，爲了提供性能，處理器和編譯器常常會對指令進行重排序，但是不能隨意重排序，不是你想怎麼排序就怎麼排序，它需要滿足以下兩個條件：

• 在單線程環境下不能改變程序運行的結果；

• 存在數據依賴關係的不允許重排序

需要注意的是：重排序不會影響單線程環境的執行結果，但是會破壞多線程的執行語義。

as-if-serial規則和happens-before規則的區別

• as-if-serial語義保證單線程內程序的執行結果不被改變，happens-before關係保證正確同步的多線程程序的執行結果不被改變。

   

• as-if-serial語義給編寫單線程程序的程序員創造了一個幻境：單線程程序是按程序的順序來執行的。happens-before關係給編寫正確同步的多線程程序的程序員創造了一個幻境：正確同步的多線程程序是按happens-before指定的順序來執行的。

   

• as-if-serial語義和happens-before這麼做的目的，都是爲了在不改變程序執行結果的前提下，儘可能地提高程序執行的並行度。

併發關鍵字

synchronized

synchronized 的作用？

在 Java 中，synchronized 關鍵字是用來控制線程同步的，就是在多線程的環境下，控制 synchronized 代碼段不被多個線程同時執行。synchronized 可以修飾類、方法、變量。

 

另外，在 Java 早期版本中，synchronized屬於重量級鎖，效率低下，因爲監視器鎖（monitor）是依賴於底層的操作系統的 Mutex Lock 來實現的，Java 的線程是映射到操作系統的原生線程之上的。如果要掛起或者喚醒一個線程，都需要操作系統幫忙完成，而操作系統實現線程之間的切換時需要從用戶態轉換到內核態，這個狀態之間的轉換需要相對比較長的時間，時間成本相對較高，這也是爲什麼早期的 synchronized 效率低的原因。慶幸的是在 Java 6 之後 Java 官方對從 JVM 層面對synchronized 較大優化，所以現在的 synchronized 鎖效率也優化得很不錯了。JDK1.6對鎖的實現引入了大量的優化，如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減少鎖操作的開銷。

 

說說自己是怎麼使用 synchronized 關鍵字，在項目中用到了嗎

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

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

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

• 修飾代碼塊: 指定加鎖對象，對給定對象加鎖，進入同步代碼庫前要獲得給定對象的鎖。

總結：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(); 這段代碼其實是分爲三步執行：

1. 爲 uniqueInstance 分配內存空間

2. 初始化 uniqueInstance

3. 將 uniqueInstance 指向分配的內存地址

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

 

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

 

說一下 synchronized 底層實現原理？

synchronized是Java中的一個關鍵字，在使用的過程中並沒有看到顯示的加鎖和解鎖過程。因此有必要通過javap命令，查看相應的字節碼文件。

 

synchronized 同步語句塊的情況​​​​​​​

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

通過JDK 反彙編指令 javap -c -v SynchronizedDemo

可以看出在執行同步代碼塊之前之後都有一個monitor字樣，其中前面的是monitorenter，後面的是離開monitorexit，不難想象一個線程也執行同步代碼塊，首先要獲取鎖，而獲取鎖的過程就是monitorenter ，在執行完代碼塊之後，要釋放鎖，釋放鎖就是執行monitorexit指令。

 

爲什麼會有兩個monitorexit呢？

 

這個主要是防止在同步代碼塊中線程因異常退出，而鎖沒有得到釋放，這必然會造成死鎖（等待的線程永遠獲取不到鎖）。因此最後一個monitorexit是保證在異常情況下，鎖也可以得到釋放，避免死鎖。

僅有ACC_SYNCHRONIZED這麼一個標誌，該標記表明線程進入該方法時，需要monitorenter，退出該方法時需要monitorexit。

 

synchronized可重入的原理

 

重入鎖是指一個線程獲取到該鎖之後，該線程可以繼續獲得該鎖。底層原理維護一個計數器，當線程獲取該鎖時，計數器加一，再次獲得該鎖時繼續加一，釋放鎖時，計數器減一，當計數器值爲0時，表明該鎖未被任何線程所持有，其它線程可以競爭獲取鎖。

 

什麼是自旋

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

 

多線程中 synchronized 鎖升級的原理是什麼？

synchronized 鎖升級原理：在鎖對象的對象頭裏面有一個 threadid 字段，在第一次訪問的時候 threadid 爲空，jvm 讓其持有偏向鎖，並將 threadid 設置爲其線程 id，再次進入的時候會先判斷 threadid 是否與其線程 id 一致，如果一致則可以直接使用此對象，如果不一致，則升級偏向鎖爲輕量級鎖，通過自旋循環一定次數來獲取鎖，執行一定次數之後，如果還沒有正常獲取到要使用的對象，此時就會把鎖從輕量級升級爲重量級鎖，此過程就構成了 synchronized 鎖的升級。

 

鎖的升級的目的：鎖升級是爲了減低了鎖帶來的性能消耗。在 Java 6 之後優化 synchronized 的實現方式，使用了偏向鎖升級爲輕量級鎖再升級到重量級鎖的方式，從而減低了鎖帶來的性能消耗。

 

線程 B 怎麼知道線程 A 修改了變量

（1）volatile 修飾變量

 

（2）synchronized 修飾修改變量的方法

 

（3）wait/notify

 

（4）while 輪詢

 

當一個線程進入一個對象的 synchronized 方法 A 之後，其它線程是否可進入此對象的 synchronized 方法 B？

不能。其它線程只能訪問該對象的非同步方法，同步方法則不能進入。因爲非靜態方法上的 synchronized 修飾符要求執行方法時要獲得對象的鎖，如果已經進入A 方法說明對象鎖已經被取走，那麼試圖進入 B 方法的線程就只能在等鎖池（注意不是等待池哦）中等待對象的鎖。

 

synchronized、volatile、CAS 比較

（1）synchronized 是悲觀鎖，屬於搶佔式，會引起其他線程阻塞。

 

（2）volatile 提供多線程共享變量可見性和禁止指令重排序優化。

 

（3）CAS 是基於衝突檢測的樂觀鎖（非阻塞）

 

synchronized 和 Lock 有什麼區別？

• 首先synchronized是Java內置關鍵字，在JVM層面，Lock是個Java類；

• synchronized 可以給類、方法、代碼塊加鎖；而 lock 只能給代碼塊加鎖。

• synchronized 不需要手動獲取鎖和釋放鎖，使用簡單，發生異常會自動釋放鎖，不會造成死鎖；而 lock 需要自己加鎖和釋放鎖，如果使用不當沒有 unLock()去釋放鎖就會造成死鎖。

• 通過 Lock 可以知道有沒有成功獲取鎖，而 synchronized 卻無法辦到。

 

synchronized 和 ReentrantLock 區別是什麼？

synchronized 是和 if、else、for、while 一樣的關鍵字，ReentrantLock 是類，這是二者的本質區別。既然 ReentrantLock 是類，那麼它就提供了比synchronized 更多更靈活的特性，可以被繼承、可以有方法、可以有各種各樣的類變量

 

synchronized 早期的實現比較低效，對比 ReentrantLock，大多數場景性能都相差較大，但是在 Java 6 中對 synchronized 進行了非常多的改進。

 

相同點：兩者都是可重入鎖

 

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

 

主要區別如下：

• ReentrantLock 使用起來比較靈活，但是必須有釋放鎖的配合動作；

• ReentrantLock 必須手動獲取與釋放鎖，而 synchronized 不需要手動釋放和開啓鎖；

• ReentrantLock 只適用於代碼塊鎖，而 synchronized 可以修飾類、方法、變量等。

• 二者的鎖機制其實也是不一樣的。ReentrantLock 底層調用的是 Unsafe 的park 方法加鎖，synchronized 操作的應該是對象頭中 mark word

Java中每一個對象都可以作爲鎖，這是synchronized實現同步的基礎：

• 普通同步方法，鎖是當前實例對象

• 靜態同步方法，鎖是當前類的class對象

• 同步方法塊，鎖是括號裏面的對象

volatile

volatile 關鍵字的作用

對於可見性，Java 提供了 volatile 關鍵字來保證可見性和禁止指令重排。volatile 提供 happens-before 的保證，確保一個線程的修改能對其他線程是可見的。當一個共享變量被 volatile 修飾時，它會保證修改的值會立即被更新到主存，當有其他線程需要讀取時，它會去內存中讀取新值。

 

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

 

volatile 常用於多線程環境下的單次操作(單次讀或者單次寫)。

 

Java 中能創建 volatile 數組嗎？

能，Java 中可以創建 volatile 類型數組，不過只是一個指向數組的引用，而不是整個數組。意思是，如果改變引用指向的數組，將會受到 volatile 的保護，但是如果多個線程同時改變數組的元素，volatile 標示符就不能起到之前的保護作用了。

 

volatile 變量和 atomic 變量有什麼不同？

volatile 變量可以確保先行關係，即寫操作會發生在後續的讀操作之前, 但它並不能保證原子性。例如用 volatile 修飾 count 變量，那麼 count++ 操作就不是原子性的。

 

而 AtomicInteger 類提供的 atomic 方法可以讓這種操作具有原子性如getAndIncrement()方法會原子性的進行增量操作把當前值加一，其它數據類型和引用變量也可以進行相似操作。

 

volatile 能使得一個非原子操作變成原子操作嗎？

關鍵字volatile的主要作用是使變量在多個線程間可見，但無法保證原子性，對於多個線程訪問同一個實例變量需要加鎖進行同步。

 

雖然volatile只能保證可見性不能保證原子性，但用volatile修飾long和double可以保證其操作原子性。

 

所以從Oracle Java Spec裏面可以看到：

• 對於64位的long和double，如果沒有被volatile修飾，那麼對其操作可以不是原子的。在操作的時候，可以分成兩步，每次對32位操作。

• 如果使用volatile修飾long和double，那麼其讀寫都是原子操作

• 對於64位的引用地址的讀寫，都是原子操作

• 在實現JVM時，可以自由選擇是否把讀寫long和double作爲原子操作

• 推薦JVM實現爲原子操作

 

volatile 修飾符的有過什麼實踐？

單例模式

 

是否 Lazy 初始化：是

 

是否多線程安全：是

 

實現難度：較複雜

 

描述：對於Double-Check這種可能出現的問題（當然這種概率已經非常小了，但畢竟還是有的嘛~），解決方案是：只需要給instance的聲明加上volatile關鍵字即可volatile關鍵字的一個作用是禁止指令重排，把instance聲明爲volatile之後，對它的寫操作就會有一個內存屏障（什麼是內存屏障？），這樣，在它的賦值完成之前，就不用會調用讀操作。注意：volatile阻止的不是singleton = newSingleton()這句話內部[1-2-3]的指令重排，而是保證了在一個寫操作（[1-2-3]）完成之前，不會調用讀操作（if (instance == null)）。​​​​​​​

public class Singleton7 {
    private static volatile Singleton7 instance = null;
    private Singleton7() {}
    public static Singleton7 getInstance() {        if (instance == null) {            synchronized (Singleton7.class) {                if (instance == null) {                    instance = new Singleton7();                }            }        }
        return instance;    }
}

synchronized 和 volatile 的區別是什麼？

synchronized 表示只有一個線程可以獲取作用對象的鎖，執行代碼，阻塞其他線程。

 

volatile 表示變量在 CPU 的寄存器中是不確定的，必須從主存中讀取。保證多線程環境下變量的可見性；禁止指令重排序。

 

區別

• volatile 是變量修飾符；synchronized 可以修飾類、方法、變量。

   

• volatile 僅能實現變量的修改可見性，不能保證原子性；而 synchronized 則可以保證變量的修改可見性和原子性。

   

• volatile 不會造成線程的阻塞；synchronized 可能會造成線程的阻塞。

•  

• volatile標記的變量不會被編譯器優化；synchronized標記的變量可以被編譯器優化。

   

• volatile關鍵字是線程同步的輕量級實現，所以volatile性能肯定比synchronized關鍵字要好。但是volatile關鍵字只能用於變量而synchronized關鍵字可以修飾方法以及代碼塊。synchronized關鍵字在JavaSE1.6之後進行了主要包括爲了減少獲得鎖和釋放鎖帶來的性能消耗而引入的偏向鎖和輕量級鎖以及其它各種優化之後執行效率有了顯著提升，實際開發中使用 synchronized 關鍵字的場景還是更多一些。

final

什麼是不可變對象，它對寫併發應用有什麼幫助？

不可變對象(Immutable Objects)即對象一旦被創建它的狀態（對象的數據，也即對象屬性值）就不能改變，反之即爲可變對象(Mutable Objects)。

 

不可變對象的類即爲不可變類(Immutable Class)。Java 平臺類庫中包含許多不可變類，如 String、基本類型的包裝類、BigInteger 和 BigDecimal 等。

 

只有滿足如下狀態，一個對象纔是不可變的；

• 它的狀態不能在創建後再被修改；

• 所有域都是 final 類型；並且，它被正確創建（創建期間沒有發生 this 引用的逸出）。

不可變對象保證了對象的內存可見性，對不可變對象的讀取不需要進行額外的同步手段，提升了代碼執行效率。

 

Lock體系

Lock簡介與初識AQS

Java Concurrency API 中的 Lock 接口(Lock interface)是什麼？對比同步它有什麼優勢？

Lock 接口比同步方法和同步塊提供了更具擴展性的鎖操作。他們允許更靈活的結構，可以具有完全不同的性質，並且可以支持多個相關類的條件對象。

 

它的優勢有：

 

（1）可以使鎖更公平

 

（2）可以使線程在等待鎖的時候響應中斷

 

（3）可以讓線程嘗試獲取鎖，並在無法獲取鎖的時候立即返回或者等待一段時間

 

（4）可以在不同的範圍，以不同的順序獲取和釋放鎖

 

整體上來說 Lock 是 synchronized 的擴展版，Lock 提供了無條件的、可輪詢的(tryLock 方法)、定時的(tryLock 帶參方法)、可中斷的(lockInterruptibly)、可多條件隊列的(newCondition 方法)鎖操作。另外 Lock 的實現類基本都支持非公平鎖(默認)和公平鎖，synchronized 只支持非公平鎖，當然，在大部分情況下，非公平鎖是高效的選擇。

 

樂觀鎖和悲觀鎖的理解及如何實現，有哪些實現方式？

悲觀鎖：總是假設最壞的情況，每次去拿數據的時候都認爲別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會阻塞直到它拿到鎖。傳統的關係型數據庫裏邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。再比如 Java 裏面的同步原語 synchronized 關鍵字的實現也是悲觀鎖。

 

樂觀鎖：顧名思義，就是很樂觀，每次去拿數據的時候都認爲別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像數據庫提供的類似於 write_condition 機制，其實都是提供的樂觀鎖。在 Java中 java.util.concurrent.atomic 包下面的原子變量類就是使用了樂觀鎖的一種實現方式 CAS 實現的。

 

樂觀鎖的實現方式：

 

1、使用版本標識來確定讀到的數據與提交時的數據是否一致。提交後修改版本標識，不一致時可以採取丟棄和再次嘗試的策略。

 

2、java 中的 Compare and Swap 即 CAS ，當多個線程嘗試使用 CAS 同時更新同一個變量時，只有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程並不會被掛起，而是被告知這次競爭中失敗，並可以再次嘗試。CAS 操作中包含三個操作數 —— 需要讀寫的內存位置（V）、進行比較的預期原值（A）和擬寫入的新值(B)。如果內存位置 V 的值與預期原值 A 相匹配，那麼處理器會自動將該位置值更新爲新值 B。否則處理器不做任何操作。

 

什麼是 CAS

CAS 是 compare and swap 的縮寫，即我們所說的比較交換。

 

cas 是一種基於鎖的操作，而且是樂觀鎖。在 java 中鎖分爲樂觀鎖和悲觀鎖。悲觀鎖是將資源鎖住，等一個之前獲得鎖的線程釋放鎖之後，下一個線程纔可以訪問。而樂觀鎖採取了一種寬泛的態度，通過某種方式不加鎖來處理資源，比如通過給記錄加 version 來獲取數據，性能較悲觀鎖有很大的提高。

 

CAS 操作包含三個操作數 —— 內存位置（V）、預期原值（A）和新值(B)。如果內存地址裏面的值和 A 的值是一樣的，那麼就將內存裏面的值更新成 B。CAS是通過無限循環來獲取數據的，若果在第一輪循環中，a 線程獲取地址裏面的值被b 線程修改了，那麼 a 線程需要自旋，到下次循環纔有可能機會執行。

 

java.util.concurrent.atomic 包下的類大多是使用 CAS 操作來實現的(AtomicInteger,AtomicBoolean,AtomicLong)。

 

CAS 的會產生什麼問題？

1、ABA 問題：

 

比如說一個線程 one 從內存位置 V 中取出 A，這時候另一個線程 two 也從內存中取出 A，並且 two 進行了一些操作變成了 B，然後 two 又將 V 位置的數據變成 A，這時候線程 one 進行 CAS 操作發現內存中仍然是 A，然後 one 操作成功。儘管線程 one 的 CAS 操作成功，但可能存在潛藏的問題。從 Java1.5 開始 JDK 的 atomic包裏提供了一個類 AtomicStampedReference 來解決 ABA 問題。

 

2、循環時間長開銷大：

 

對於資源競爭嚴重（線程衝突嚴重）的情況，CAS 自旋的概率會比較大，從而浪費更多的 CPU 資源，效率低於 synchronized。

 

3、只能保證一個共享變量的原子操作：

 

當對一個共享變量執行操作時，我們可以使用循環 CAS 的方式來保證原子操作，但是對多個共享變量操作時，循環 CAS 就無法保證操作的原子性，這個時候就可以用鎖。

 

什麼是死鎖？

當線程 A 持有獨佔鎖a，並嘗試去獲取獨佔鎖 b 的同時，線程 B 持有獨佔鎖 b，並嘗試獲取獨佔鎖 a 的情況下，就會發生 AB 兩個線程由於互相持有對方需要的鎖，而發生的阻塞現象，我們稱爲死鎖。

 

產生死鎖的條件是什麼？怎麼防止死鎖？

產生死鎖的必要條件：

 

1、互斥條件：所謂互斥就是進程在某一時間內獨佔資源。

 

2、請求與保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放。

 

3、不剝奪條件：進程已獲得資源，在末使用完之前，不能強行剝奪。

 

4、循環等待條件：若干進程之間形成一種頭尾相接的循環等待資源關係。

 

這四個條件是死鎖的必要條件，只要系統發生死鎖，這些條件必然成立，而只要上述條件之 一不滿足，就不會發生死鎖。

 

理解了死鎖的原因，尤其是產生死鎖的四個必要條件，就可以最大可能地避免、預防和 解除死鎖。

 

防止死鎖可以採用以下的方法：

• 儘量使用 tryLock(long timeout, TimeUnit unit)的方法(ReentrantLock、ReentrantReadWriteLock)，設置超時時間，超時可以退出防止死鎖。

• 儘量使用 Java. util. concurrent 併發類代替自己手寫鎖。

• 儘量降低鎖的使用粒度，儘量不要幾個功能用同一把鎖。

• 儘量減少同步的代碼塊。

 

死鎖與活鎖的區別，死鎖與飢餓的區別？

死鎖：是指兩個或兩個以上的進程（或線程）在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。

 

活鎖：任務或者執行者沒有被阻塞，由於某些條件沒有滿足，導致一直重複嘗試，失敗，嘗試，失敗。

 

活鎖和死鎖的區別在於，處於活鎖的實體是在不斷的改變狀態，這就是所謂的“活”， 而處於死鎖的實體表現爲等待；活鎖有可能自行解開，死鎖則不能。

 

飢餓：一個或者多個線程因爲種種原因無法獲得所需要的資源，導致一直無法執行的狀態。

 

Java 中導致飢餓的原因：

 

1、高優先級線程吞噬所有的低優先級線程的 CPU 時間。

 

2、線程被永久堵塞在一個等待進入同步塊的狀態，因爲其他線程總是能在它之前持續地對該同步塊進行訪問。

 

3、線程在等待一個本身也處於永久等待完成的對象(比如調用這個對象的 wait 方法)，因爲其他線程總是被持續地獲得喚醒。

 

多線程鎖的升級原理是什麼？

在Java中，鎖共有4種狀態，級別從低到高依次爲：無狀態鎖，偏向鎖，輕量級鎖和重量級鎖狀態，這幾個狀態會隨着競爭情況逐漸升級。鎖可以升級但不能降級。

 

AQS(AbstractQueuedSynchronizer)詳解與源碼分析

AQS 介紹

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

 

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

 

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（共享）：多個線程可同時執行，如Semaphore/CountDownLatch。Semaphore、CountDownLatch、 CyclicBarrier、ReadWriteLock 我們都會在後面講到。

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

 

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

 

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

 

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

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

2. 將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。

 

ReentrantLock(重入鎖)實現原理與公平鎖非公平鎖區別

什麼是可重入鎖（ReentrantLock）？

ReentrantLock重入鎖，是實現Lock接口的一個類，也是在實際編程中使用頻率很高的一個鎖，支持重入性，表示能夠對共享資源能夠重複加鎖，即當前線程獲取該鎖再次獲取不會被阻塞。

 

在java關鍵字synchronized隱式支持重入性，synchronized通過獲取自增，釋放自減的方式實現重入。與此同時，ReentrantLock還支持公平鎖和非公平鎖兩種方式。那麼，要想完完全全的弄懂ReentrantLock的話，主要也就是ReentrantLock同步語義的學習：1. 重入性的實現原理；2. 公平鎖和非公平鎖。

 

重入性的實現原理

 

要想支持重入性，就要解決兩個問題：1. 在線程獲取鎖的時候，如果已經獲取鎖的線程是當前線程的話則直接再次獲取成功；2. 由於鎖會被獲取n次，那麼只有鎖在被釋放同樣的n次之後，該鎖纔算是完全釋放成功。

 

ReentrantLock支持兩種鎖：公平鎖和非公平鎖。何謂公平性，是針對獲取鎖而言的，如果一個鎖是公平的，那麼鎖的獲取順序就應該符合請求上的絕對時間順序，滿足FIFO。

 

讀寫鎖ReentrantReadWriteLock源碼分析

ReadWriteLock 是什麼

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

 

ReadWriteLock 是一個讀寫鎖接口，讀寫鎖是用來提升併發程序性能的鎖分離技術，ReentrantReadWriteLock 是 ReadWriteLock 接口的一個具體實現，實現了讀寫的分離，讀鎖是共享的，寫鎖是獨佔的，讀和讀之間不會互斥，讀和寫、寫和讀、寫和寫之間纔會互斥，提升了讀寫的性能。

 

而讀寫鎖有以下三個重要的特性：

 

（1）公平選擇性：支持非公平（默認）和公平的鎖獲取方式，吞吐量還是非公平優於公平。

 

（2）重進入：讀鎖和寫鎖都支持線程重進入。

 

（3）鎖降級：遵循獲取寫鎖、獲取讀鎖再釋放寫鎖的次序，寫鎖能夠降級成爲讀鎖。

 

Condition源碼分析與等待通知機制

LockSupport詳解

併發容器

併發容器之ConcurrentHashMap詳解(JDK1.8版本)與源碼分析

什麼是ConcurrentHashMap？

ConcurrentHashMap是Java中的一個線程安全且高效的HashMap實現。平時涉及高併發如果要用map結構，那第一時間想到的就是它。相對於hashmap來說，ConcurrentHashMap就是線程安全的map，其中利用了鎖分段的思想提高了併發度。

 

那麼它到底是如何實現線程安全的？

 

JDK 1.6版本關鍵要素：

• segment繼承了ReentrantLock充當鎖的角色，爲每一個segment提供了線程安全的保障；

• segment維護了哈希散列表的若干個桶，每個桶由HashEntry構成的鏈表。

JDK1.8後，ConcurrentHashMap拋棄了原有的Segment 分段鎖，而採用了 CAS + synchronized 來保證併發安全性。

 

Java 中 ConcurrentHashMap 的併發度是什麼？

ConcurrentHashMap 把實際 map 劃分成若干部分來實現它的可擴展性和線程安全。這種劃分是使用併發度獲得的，它是 ConcurrentHashMap 類構造函數的一個可選參數，默認值爲 16，這樣在多線程情況下就能避免爭用。

 

在 JDK8 後，它摒棄了 Segment（鎖段）的概念，而是啓用了一種全新的方式實現,利用 CAS 算法。同時加入了更多的輔助變量來提高併發度，具體內容還是查看源碼吧。

 

什麼是併發容器的實現？

何爲同步容器：可以簡單地理解爲通過 synchronized 來實現同步的容器，如果有多個線程調用同步容器的方法，它們將會串行執行。比如 Vector，Hashtable，以及 Collections.synchronizedSet，synchronizedList 等方法返回的容器。可以通過查看 Vector，Hashtable 等這些同步容器的實現代碼，可以看到這些容器實現線程安全的方式就是將它們的狀態封裝起來，並在需要同步的方法上加上關鍵字 synchronized。

 

併發容器使用了與同步容器完全不同的加鎖策略來提供更高的併發性和伸縮性，例如在 ConcurrentHashMap 中採用了一種粒度更細的加鎖機制，可以稱爲分段鎖，在這種鎖機制下，允許任意數量的讀線程併發地訪問 map，並且執行讀操作的線程和寫操作的線程也可以併發的訪問 map，同時允許一定數量的寫操作線程併發地修改 map，所以它可以在併發環境下實現更高的吞吐量。

 

Java 中的同步集合與併發集合有什麼區別？

同步集合與併發集合都爲多線程和併發提供了合適的線程安全的集合，不過併發集合的可擴展性更高。在 Java1.5 之前程序員們只有同步集合來用且在多線程併發的時候會導致爭用，阻礙了系統的擴展性。Java5 介紹了併發集合像ConcurrentHashMap，不僅提供線程安全還用鎖分離和內部分區等現代技術提高了可擴展性。

 

SynchronizedMap 和 ConcurrentHashMap 有什麼區別？

SynchronizedMap 一次鎖住整張表來保證線程安全，所以每次只能有一個線程來訪爲 map。

 

ConcurrentHashMap 使用分段鎖來保證在多線程下的性能。

 

ConcurrentHashMap 中則是一次鎖住一個桶。ConcurrentHashMap 默認將hash 表分爲 16 個桶，諸如 get，put，remove 等常用操作只鎖當前需要用到的桶。

 

這樣，原來只能一個線程進入，現在卻能同時有 16 個寫線程執行，併發性能的提升是顯而易見的。

 

另外 ConcurrentHashMap 使用了一種不同的迭代方式。在這種迭代方式中，當iterator 被創建後集合再發生改變就不再是拋出ConcurrentModificationException，取而代之的是在改變時 new 新的數據從而不影響原有的數據，iterator 完成後再將頭指針替換爲新的數據 ，這樣 iterator線程可以使用原來老的數據，而寫線程也可以併發的完成改變。

 

併發容器之CopyOnWriteArrayList詳解

CopyOnWriteArrayList 是什麼，可以用於什麼應用場景？有哪些優缺點？

CopyOnWriteArrayList 是一個併發容器。有很多人稱它是線程安全的，我認爲這句話不嚴謹，缺少一個前提條件，那就是非複合場景下操作它是線程安全的。

 

CopyOnWriteArrayList(免鎖容器)的好處之一是當多個迭代器同時遍歷和修改這個列表時，不會拋出 ConcurrentModificationException。在CopyOnWriteArrayList 中，寫入將導致創建整個底層數組的副本，而源數組將保留在原地，使得複製的數組在被修改時，讀取操作可以安全地執行。

 

CopyOnWriteArrayList 的使用場景

 

通過源碼分析，我們看出它的優缺點比較明顯，所以使用場景也就比較明顯。就是合適讀多寫少的場景。

 

CopyOnWriteArrayList 的缺點

• 由於寫操作的時候，需要拷貝數組，會消耗內存，如果原數組的內容比較多的情況下，可能導致 young gc 或者 full gc。

• 不能用於實時讀的場景，像拷貝數組、新增元素都需要時間，所以調用一個 set 操作後，讀取到數據可能還是舊的，雖然CopyOnWriteArrayList 能做到最終一致性,但是還是沒法滿足實時性要求。

• 由於實際使用中可能沒法保證 CopyOnWriteArrayList 到底要放置多少數據，萬一數據稍微有點多，每次 add/set 都要重新複製數組，這個代價實在太高昂了。在高性能的互聯網應用中，這種操作分分鐘引起故障。

CopyOnWriteArrayList 的設計思想

1. 讀寫分離，讀和寫分開

2. 最終一致性

3. 使用另外開闢空間的思路，來解決併發衝突

併發容器之ThreadLocal詳解

ThreadLocal 是什麼？有哪些使用場景？

ThreadLocal 是一個本地線程副本變量工具類，在每個線程中都創建了一個 ThreadLocalMap 對象，簡單說 ThreadLocal 就是一種以空間換時間的做法，每個線程可以訪問自己內部 ThreadLocalMap 對象內的 value。通過這種方式，避免資源在多線程間共享。

 

原理：線程局部變量是侷限於線程內部的變量，屬於線程自身所有，不在多個線程間共享。Java提供ThreadLocal類來支持線程局部變量，是一種實現線程安全的方式。但是在管理環境下（如 web 服務器）使用線程局部變量的時候要特別小心，在這種情況下，工作線程的生命週期比任何應用變量的生命週期都要長。任何線程局部變量一旦在工作完成後沒有釋放，Java 應用就存在內存泄露的風險。

 

經典的使用場景是爲每個線程分配一個 JDBC 連接 Connection。這樣就可以保證每個線程的都在各自的 Connection 上進行數據庫的操作，不會出現 A 線程關了 B線程正在使用的 Connection；還有 Session 管理 等問題。

 

ThreadLocal 使用例子：​​​​​​​

public class TestThreadLocal {        //線程本地存儲變量    private static final ThreadLocal<Integer> THREAD_LOCAL_NUM         = new ThreadLocal<Integer>() {        @Override        protected Integer initialValue() {            return 0;        }    };     public static void main(String[] args) {        for (int i = 0; i <3; i++) {//啓動三個線程            Thread t = new Thread() {                @Override                public void run() {                    add10ByThreadLocal();                }            };            t.start();        }    }        /**     * 線程本地存儲變量加 5     */    private static void add10ByThreadLocal() {        for (int i = 0; i <5; i++) {            Integer n = THREAD_LOCAL_NUM.get();            n += 1;            THREAD_LOCAL_NUM.set(n);            System.out.println(Thread.currentThread().getName() + " : ThreadLocal num=" + n);        }    }    }

打印結果：啓動了 3 個線程，每個線程最後都打印到 “ThreadLocal num=5”，而不是 num 一直在累加直到值等於 15​​​​​​​

Thread-0 : ThreadLocal num=1Thread-1 : ThreadLocal num=1Thread-0 : ThreadLocal num=2Thread-0 : ThreadLocal num=3Thread-1 : ThreadLocal num=2Thread-2 : ThreadLocal num=1Thread-0 : ThreadLocal num=4Thread-2 : ThreadLocal num=2Thread-1 : ThreadLocal num=3Thread-1 : ThreadLocal num=4Thread-2 : ThreadLocal num=3Thread-0 : ThreadLocal num=5Thread-2 : ThreadLocal num=4Thread-2 : ThreadLocal num=5Thread-1 : ThreadLocal num=5

 

什麼是線程局部變量？

線程局部變量是侷限於線程內部的變量，屬於線程自身所有，不在多個線程間共享。Java 提供 ThreadLocal 類來支持線程局部變量，是一種實現線程安全的方式。但是在管理環境下（如 web 服務器）使用線程局部變量的時候要特別小心，在這種情況下，工作線程的生命週期比任何應用變量的生命週期都要長。任何線程局部變量一旦在工作完成後沒有釋放，Java 應用就存在內存泄露的風險。

 

ThreadLocal內存泄漏分析與解決方案

ThreadLocal造成內存泄漏的原因？

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

 

ThreadLocal內存泄漏解決方案？

• 每次使用完ThreadLocal，都調用它的remove()方法，清除數據。

• 在使用線程池的情況下，沒有及時清理ThreadLocal，不僅是內存泄漏的問題，更嚴重的是可能導致業務邏輯出現問題。所以，使用ThreadLocal就跟加鎖完要解鎖一樣，用完就清理。

併發容器之BlockingQueue詳解

什麼是阻塞隊列？阻塞隊列的實現原理是什麼？如何使用阻塞隊列來實現生產者-消費者模型？

阻塞隊列（BlockingQueue）是一個支持兩個附加操作的隊列。

 

這兩個附加的操作是：在隊列爲空時，獲取元素的線程會等待隊列變爲非空。當隊列滿時，存儲元素的線程會等待隊列可用。

 

阻塞隊列常用於生產者和消費者的場景，生產者是往隊列裏添加元素的線程，消費者是從隊列裏拿元素的線程。阻塞隊列就是生產者存放元素的容器，而消費者也只從容器裏拿元素。

 

JDK7 提供了 7 個阻塞隊列。分別是：

 

ArrayBlockingQueue ：一個由數組結構組成的有界阻塞隊列。

 

LinkedBlockingQueue ：一個由鏈表結構組成的有界阻塞隊列。

 

PriorityBlockingQueue ：一個支持優先級排序的無界阻塞隊列。

 

DelayQueue：一個使用優先級隊列實現的無界阻塞隊列。

 

SynchronousQueue：一個不存儲元素的阻塞隊列。

 

LinkedTransferQueue：一個由鏈表結構組成的無界阻塞隊列。

 

LinkedBlockingDeque：一個由鏈表結構組成的雙向阻塞隊列。

 

Java 5 之前實現同步存取時，可以使用普通的一個集合，然後在使用線程的協作和線程同步可以實現生產者，消費者模式，主要的技術就是用好，wait,notify,notifyAll,sychronized 這些關鍵字。而在 java 5 之後，可以使用阻塞隊列來實現，此方式大大簡少了代碼量，使得多線程編程更加容易，安全方面也有保障。

 

BlockingQueue 接口是 Queue 的子接口，它的主要用途並不是作爲容器，而是作爲線程同步的的工具，因此他具有一個很明顯的特性，當生產者線程試圖向 BlockingQueue 放入元素時，如果隊列已滿，則線程被阻塞，當消費者線程試圖從中取出一個元素時，如果隊列爲空，則該線程會被阻塞，正是因爲它所具有這個特性，所以在程序中多個線程交替向 BlockingQueue 中放入元素，取出元素，它可以很好的控制線程之間的通信。

 

阻塞隊列使用最經典的場景就是 socket 客戶端數據的讀取和解析，讀取數據的線程不斷將數據放入隊列，然後解析線程不斷從隊列取數據解析。

 

併發容器之ConcurrentLinkedQueue詳解與源碼分析

併發容器之ArrayBlockingQueue與LinkedBlockingQueue詳解

線程池

Executors類創建四種常見線程池

什麼是線程池？有哪幾種創建方式？

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

 

在面向對象編程中，創建和銷燬對象是很費時間的，因爲創建一個對象要獲取內存資源或者其它更多資源。在 Java 中更是如此，虛擬機將試圖跟蹤每一個對象，以便能夠在對象銷燬後進行垃圾回收。所以提高服務程序效率的一個手段就是儘可能減少創建和銷燬對象的次數，特別是一些很耗資源的對象創建和銷燬，這就是”池化資源”技術產生的原因。

 

線程池顧名思義就是事先創建若干個可執行的線程放入一個池（容器）中，需要的時候從池中獲取線程不用自行創建，使用完畢不需要銷燬線程而是放回池中，從而減少創建和銷燬線程對象的開銷。Java 5+中的 Executor 接口定義一個執行線程的工具。它的子類型即線程池接口是 ExecutorService。要配置一個線程池是比較複雜的，尤其是對於線程池的原理不是很清楚的情況下，因此在工具類 Executors 面提供了一些靜態工廠方法，生成一些常用的線程池，如下所示：

 

（1）newSingleThreadExecutor：創建一個單線程的線程池。這個線程池只有一個線程在工作，也就是相當於單線程串行執行所有任務。如果這個唯一的線程因爲異常結束，那麼會有一個新的線程來替代它。此線程池保證所有任務的執行順序按照任務的提交順序執行。

 

（2）newFixedThreadPool：創建固定大小的線程池。每次提交一個任務就創建一個線程，直到線程達到線程池的最大大小。線程池的大小一旦達到最大值就會保持不變，如果某個線程因爲執行異常而結束，那麼線程池會補充一個新線程。如果希望在服務器上使用線程池，建議使用 newFixedThreadPool方法來創建線程池，這樣能獲得更好的性能。

 

（3） newCachedThreadPool：創建一個可緩存的線程池。如果線程池的大小超過了處理任務所需要的線程，那麼就會回收部分空閒（60 秒不執行任務）的線程，當任務數增加時，此線程池又可以智能的添加新線程來處理任務。此線程池不會對線程池大小做限制，線程池大小完全依賴於操作系統（或者說 JVM）能夠創建的最大線程大小。

 

（4）newScheduledThreadPool：創建一個大小無限的線程池。此線程池支持定時以及週期性執行任務的需求。

 

線程池有什麼優點？

• 降低資源消耗：重用存在的線程，減少對象創建銷燬的開銷。

   

• 提高響應速度。可有效的控制最大併發線程數，提高系統資源的使用率，同時避免過多資源競爭，避免堵塞。當任務到達時，任務可以不需要的等到線程創建就能立即執行。

   

• 提高線程的可管理性。線程是稀缺資源，如果無限制的創建，不僅會消耗系統資源，還會降低系統的穩定性，使用線程池可以進行統一的分配，調優和監控。

•  

• 附加功能：提供定時執行、定期執行、單線程、併發數控制等功能。

綜上所述使用線程池框架 Executor 能更好的管理線程、提供系統資源使用率。

線程池都有哪些狀態？

• RUNNING：這是最正常的狀態，接受新的任務，處理等待隊列中的任務。

• SHUTDOWN：不接受新的任務提交，但是會繼續處理等待隊列中的任務。

• STOP：不接受新的任務提交，不再處理等待隊列中的任務，中斷正在執行任務的線程。

• TIDYING：所有的任務都銷燬了，workCount 爲 0，線程池的狀態在轉換爲 TIDYING 狀態時，會執行鉤子方法 terminated()。

• TERMINATED：terminated()方法結束後，線程池的狀態就會變成這個。

什麼是 Executor 框架？爲什麼使用 Executor 框架？

Executor 框架是一個根據一組執行策略調用，調度，執行和控制的異步任務的框架。

 

每次執行任務創建線程 new Thread()比較消耗性能，創建一個線程是比較耗時、耗資源的，而且無限制的創建線程會引起應用程序內存溢出。

 

所以創建一個線程池是個更好的的解決方案，因爲可以限制線程的數量並且可以回收再利用這些線程。利用Executors 框架可以非常方便的創建一個線程池。

 

在 Java 中 Executor 和 Executors 的區別？

• Executors 工具類的不同方法按照我們的需求創建了不同的線程池，來滿足業務的需求。

   

• Executor 接口對象能執行我們的線程任務。

   

• ExecutorService 接口繼承了 Executor 接口並進行了擴展，提供了更多的方法我們能獲得任務執行的狀態並且可以獲取任務的返回值。

•  

• 使用 ThreadPoolExecutor 可以創建自定義線程池。

   

• Future 表示異步計算的結果，他提供了檢查計算是否完成的方法，以等待計算的完成，並可以使用 get()方法獲取計算的結果。

 

線程池中 submit() 和 execute() 方法有什麼區別？

接收參數：execute()只能執行 Runnable 類型的任務。submit()可以執行 Runnable 和 Callable 類型的任務。

 

返回值：submit()方法可以返回持有計算結果的 Future 對象，而execute()沒有

 

異常處理：submit()方便Exception處理

 

什麼是線程組，爲什麼在 Java 中不推薦使用？

ThreadGroup 類，可以把線程歸屬到某一個線程組中，線程組中可以有線程對象，也可以有線程組，組中還可以有線程，這樣的組織結構有點類似於樹的形式。

 

線程組和線程池是兩個不同的概念，他們的作用完全不同，前者是爲了方便線程的管理，後者是爲了管理線程的生命週期，複用線程，減少創建銷燬線程的開銷。

 

爲什麼不推薦使用線程組？因爲使用有很多的安全隱患吧，沒有具體追究，如果需要使用，推薦使用線程池。

 

線程池之ThreadPoolExecutor詳解

Executors和ThreaPoolExecutor創建線程池的區別

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

 

Executors 各個方法的弊端：

• newFixedThreadPool 和 newSingleThreadExecutor:

  主要問題是堆積的請求處理隊列可能會耗費非常大的內存，甚至 OOM。

   

• newCachedThreadPool 和 newScheduledThreadPool:

  主要問題是線程數最大數是 Integer.MAX_VALUE，可能會創建數量非常多的線程，甚至 OOM。

ThreaPoolExecutor創建線程池方式只有一種，就是走它的構造函數，參數自己指定

 

你知道怎麼創建線程池嗎？

創建線程池的方式有多種，這裏你只需要答 ThreadPoolExecutor 即可。

 

ThreadPoolExecutor() 是最原始的線程池創建，也是阿里巴巴 Java 開發手冊中明確規範的創建線程池的方式。

 

ThreadPoolExecutor構造函數重要參數分析

ThreadPoolExecutor 3 個最重要的參數：

• corePoolSize ：核心線程數，線程數定義了最小可以同時運行的線程數量。

• maximumPoolSize ：線程池中允許存在的工作線程的最大數量

• workQueue：當新任務來的時候會先判斷當前運行的線程數量是否達到核心線程數，如果達到的話，任務就會被存放在隊列中。

ThreadPoolExecutor其他常見參數:

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

2. unit ：keepAliveTime 參數的時間單位。

3. threadFactory：爲線程池提供創建新線程的線程工廠

4. handler ：線程池任務隊列超過 maxinumPoolSize 之後的拒絕策略

 

ThreadPoolExecutor飽和策略

ThreadPoolExecutor 飽和策略定義:

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

• ThreadPoolExecutor.AbortPolicy：拋出 RejectedExecutionException來拒絕新任務的處理。

• ThreadPoolExecutor.CallerRunsPolicy：調用執行自己的線程運行任務。您不會任務請求。但是這種策略會降低對於新任務提交速度，影響程序的整體性能。另外，這個策略喜歡增加隊列容量。如果您的應用程序可以承受此延遲並且你不能任務丟棄任何一個任務請求的話，你可以選擇這個策略。

• ThreadPoolExecutor.DiscardPolicy：不處理新任務，直接丟棄掉。

• ThreadPoolExecutor.DiscardOldestPolicy：此策略將丟棄最早的未處理的任務請求。

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

 

一個簡單的線程池Demo:Runnable+ThreadPoolExecutor

線程池實現原理

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

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

import java.util.Date;
/** * 這是一個簡單的Runnable類，需要大約5秒鐘來執行其任務。 */public class MyRunnable implements Runnable {
    private String command;
    public MyRunnable(String s) {        this.command = s;    }
    @Override    public 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();        }    }
    @Override    public String toString() {        return this.command;    }}

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

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);            //執行Runnable            executor.execute(worker);        }        //終止線程池        executor.shutdown();        while (!executor.isTerminated()) {        }        System.out.println("Finished all threads");    }}

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

1. corePoolSize: 核心線程數爲 5。

2. maximumPoolSize ：最大線程數 10

3. keepAliveTime : 等待時間爲 1L。

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

5. workQueue：任務隊列爲 ArrayBlockingQueue，並且容量爲 100;

6. handler:飽和策略爲 CallerRunsPolicy。

 

Output：​​​​​​​

pool-1-thread-2 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-5 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-4 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-1 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-3 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-5 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-3 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-2 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-4 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-1 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-2 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-1 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-4 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-3 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-5 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-2 End. Time = Tue Nov 12 20:59:54 CST 2019pool-1-thread-3 End. Time = Tue Nov 12 20:59:54 CST 2019pool-1-thread-4 End. Time = Tue Nov 12 20:59:54 CST 2019pool-1-thread-5 End. Time = Tue Nov 12 20:59:54 CST 2019pool-1-thread-1 End. Time = Tue Nov 12 20:59:54 CST 2019

線程池之ScheduledThreadPoolExecutor詳解

FutureTask詳解

原子操作類

什麼是原子操作？在 Java Concurrency API 中有哪些原子類(atomic classes)？

原子操作（atomic operation）意爲”不可被中斷的一個或一系列操作” 。

 

處理器使用基於對緩存加鎖或總線加鎖的方式來實現多處理器之間的原子操作。在 Java 中可以通過鎖和循環 CAS 的方式來實現原子操作。CAS 操作——Compare & Set，或是 Compare & Swap，現在幾乎所有的 CPU 指令都支持 CAS 的原子操作。

 

原子操作是指一個不受其他操作影響的操作任務單元。原子操作是在多線程環境下避免數據不一致必須的手段。

 

int++並不是一個原子操作，所以當一個線程讀取它的值並加 1 時，另外一個線程有可能會讀到之前的值，這就會引發錯誤。

 

爲了解決這個問題，必須保證增加操作是原子的，在 JDK1.5 之前我們可以使用同步技術來做到這一點。到 JDK1.5，java.util.concurrent.atomic 包提供了 int 和long 類型的原子包裝類，它們可以自動的保證對於他們的操作是原子的並且不需要使用同步。

 

java.util.concurrent 這個包裏面提供了一組原子類。其基本的特性就是在多線程環境下，當有多個線程同時執行這些類的實例包含的方法時，具有排他性，即當某個線程進入方法，執行其中的指令時，不會被其他線程打斷，而別的線程就像自旋鎖一樣，一直等到該方法執行完成，才由 JVM 從等待隊列中選擇另一個線程進入，這只是一種邏輯上的理解。

 

原子類：AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference

 

原子數組：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray

 

原子屬性更新器：AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater

 

解決 ABA 問題的原子類：AtomicMarkableReference（通過引入一個 boolean來反映中間有沒有變過），AtomicStampedReference（通過引入一個 int 來累加來反映中間有沒有變過）

 

說一下 atomic 的原理？

Atomic包中的類基本的特性就是在多線程環境下，當有多個線程同時對單個（包括基本類型及引用類型）變量進行操作時，具有排他性，即當多個線程同時對該變量的值進行更新時，僅有一個線程能成功，而未成功的線程可以向自旋鎖一樣，繼續嘗試，一直等到執行成功。

 

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 可以保證任何時刻任何線程總能拿到該變量的最新值。

併發工具

併發工具之CountDownLatch與CyclicBarrier

在 Java 中 CycliBarriar 和 CountdownLatch 有什麼區別？

• CountDownLatch與CyclicBarrier都是用於控制併發的工具類，都可以理解成維護的就是一個計數器，但是這兩者還是各有不同側重點的：

• CountDownLatch一般用於某個線程A等待若干個其他線程執行完任務之後，它才執行；而CyclicBarrier一般用於一組線程互相等待至某個狀態，然後這一組線程再同時執行；CountDownLatch強調一個線程等多個線程完成某件事情。CyclicBarrier是多個線程互等，等大家都完成，再攜手共進。

   

• 調用CountDownLatch的countDown方法後，當前線程並不會阻塞，會繼續往下執行；而調用CyclicBarrier的await方法，會阻塞當前線程，直到CyclicBarrier指定的線程全部都到達了指定點的時候，才能繼續往下執行；

   

• CountDownLatch方法比較少，操作比較簡單，而CyclicBarrier提供的方法更多，比如能夠通過getNumberWaiting()，isBroken()這些方法獲取當前多個線程的狀態，並且CyclicBarrier的構造方法可以傳入barrierAction，指定當所有線程都到達時執行的業務功能；

   

• CountDownLatch是不能複用的，而CyclicLatch是可以複用的。

   

併發工具之Semaphore與Exchanger

Semaphore 有什麼作用

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

 

Semaphore(信號量)-允許多個線程同時訪問：synchronized 和 ReentrantLock 都是一次只允許一個線程訪問某個資源，Semaphore(信號量)可以指定多個線程同時訪問某個資源。

 

什麼是線程間交換數據的工具Exchanger

Exchanger是一個用於線程間協作的工具類，用於兩個線程間交換數據。它提供了一個交換的同步點，在這個同步點兩個線程能夠交換數據。交換數據是通過exchange方法來實現的，如果一個線程先執行exchange方法，那麼它會同步等待另一個線程也執行exchange方法，這個時候兩個線程就都達到了同步點，兩個線程就可以交換數據。

 

常用的併發工具類有哪些？

• Semaphore(信號量)-允許多個線程同時訪問：synchronized 和 ReentrantLock 都是一次只允許一個線程訪問某個資源，Semaphore(信號量)可以指定多個線程同時訪問某個資源。

• CountDownLatch(倒計時器)：CountDownLatch是一個同步工具類，用來協調多個線程之間的同步。這個工具通常用來控制線程等待，它可以讓某一個線程等待直到倒計時結束，再開始執行。

• CyclicBarrier(循環柵欄)：CyclicBarrier 和 CountDownLatch 非常類似，它也可以實現線程間的技術等待，但是它的功能比 CountDownLatch 更加複雜和強大。主要應用場景和 CountDownLatch 類似。CyclicBarrier 的字面意思是可循環使用（Cyclic）的屏障（Barrier）。它要做的事情是，讓一組線程到達一個屏障（也可以叫同步點）時被阻塞，直到最後一個線程到達屏障時，屏障纔會開門，所有被屏障攔截的線程纔會繼續幹活。CyclicBarrier默認的構造方法是 CyclicBarrier(int parties)，其參數表示屏障攔截的線程數量，每個線程調用await()方法告訴 CyclicBarrier 我已經到達了屏障，然後當前線程被阻塞。