前言
個人珍藏的80道Java多線程/併發經典面試題，因爲篇幅太長，現在先給出1-10的答案解析哈，後面一起完善~
1. synchronized的實現原理以及鎖優化？
synchronized的實現原理
- synchronized作用於「方法」或者「代碼塊」，保證被修飾的代碼在同一時間只能被一個線程訪問。
- synchronized修飾代碼塊時，JVM採用「monitorenter、monitorexit」兩個指令來實現同步
- synchronized修飾同步方法時，JVM採用「ACC_SYNCHRONIZED」標記符來實現同步
- monitorenter、monitorexit或者ACC_SYNCHRONIZED都是「基於Monitor實現」的
- 實例對象裏有對象頭，對象頭裏面有Mark Word，Mark Word指針指向了「monitor」
- Monitor其實是一種「同步工具」，也可以說是一種「同步機制」。
- 在Java虛擬機（HotSpot）中，Monitor是由「ObjectMonitor實現」的。ObjectMonitor體現出Monitor的工作原理~
ObjectMonitor() {
_header = NULL;
_count = 0; // 記錄線程獲取鎖的次數
_waiters = 0,
_recursions = 0; //鎖的重入次數
_object = NULL;
_owner = NULL; // 指向持有ObjectMonitor對象的線程
_WaitSet = NULL; // 處於wait狀態的線程，會被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; // 處於等待鎖block狀態的線程，會被加入到該列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
ObjectMonitor的幾個關鍵屬性 _count、_recursions、_owner、_WaitSet、 _EntryList 體現了monitor的工作原理
鎖優化
在討論鎖優化前，先看看JAVA對象頭(32位JVM)中Mark Word的結構圖吧~
Mark Word存儲對象自身的運行數據，如「哈希碼、GC分代年齡、鎖狀態標誌、偏向時間戳（Epoch）」 等，爲什麼區分「偏向鎖、輕量級鎖、重量級鎖」等幾種鎖狀態呢？
❝在JDK1.6之前，synchronized的實現直接調用ObjectMonitor的enter和exit，這種鎖被稱之爲「重量級鎖」。從JDK6開始，HotSpot虛擬機開發團隊對Java中的鎖進行優化，如增加了適應性自旋、鎖消除、鎖粗化、輕量級鎖和偏向鎖等優化策略。
❞
- 偏向鎖：在無競爭的情況下，把整個同步都消除掉，CAS操作都不做。
- 輕量級鎖：在沒有多線程競爭時，相對重量級鎖，減少操作系統互斥量帶來的性能消耗。但是，如果存在鎖競爭，除了互斥量本身開銷，還額外有CAS操作的開銷。
- 自旋鎖：減少不必要的CPU上下文切換。在輕量級鎖升級爲重量級鎖時，就使用了自旋加鎖的方式
- 鎖粗化：將多個連續的加鎖、解鎖操作連接在一起，擴展成一個範圍更大的鎖。
❝舉個例子，買門票進動物園。老師帶一羣小朋友去參觀，驗票員如果知道他們是個集體，就可以把他們看成一個整體（鎖租化），一次性驗票過，而不需要一個個找他們驗票。
❞
- 鎖消除:虛擬機即時編譯器在運行時，對一些代碼上要求同步，但是被檢測到不可能存在共享數據競爭的鎖進行削除。
2. ThreadLocal原理，使用注意點，應用場景有哪些？
回答四個主要點：
- ThreadLocal是什麼?
- ThreadLocal原理
- ThreadLocal使用注意點
- ThreadLocal的應用場景
ThreadLocal是什麼?
ThreadLocal，即線程本地變量。如果你創建了一個ThreadLocal變量，那麼訪問這個變量的每個線程都會有這個變量的一個本地拷貝，多個線程操作這個變量的時候，實際是操作自己本地內存裏面的變量，從而起到線程隔離的作用，避免了線程安全問題。
//創建一個ThreadLocal變量 static ThreadLocal<String> localVariable = new ThreadLocal<>();
ThreadLocal原理
ThreadLocal內存結構圖：
由結構圖是可以看出：
- Thread對象中持有一個ThreadLocal.ThreadLocalMap的成員變量。
- ThreadLocalMap內部維護了Entry數組，每個Entry代表一個完整的對象，key是ThreadLocal本身，value是ThreadLocal的泛型值。
對照着幾段關鍵源碼來看，更容易理解一點哈~
public class Thread implements Runnable {
//ThreadLocal.ThreadLocalMap是Thread的屬性
ThreadLocal.ThreadLocalMap threadLocals = null;
}
ThreadLocal中的關鍵方法set()和get()
public void set(T value) {
Thread t = Thread.currentThread(); //獲取當前線程t
ThreadLocalMap map = getMap(t); //根據當前線程獲取到ThreadLocalMap
if (map != null)
map.set(this, value); //K，V設置到ThreadLocalMap中
else
createMap(t, value); //創建一個新的ThreadLocalMap
}
public T get() {
Thread t = Thread.currentThread();//獲取當前線程t
ThreadLocalMap map = getMap(t);//根據當前線程獲取到ThreadLocalMap
if (map != null) {
//由this（即ThreadLoca對象）得到對應的Value，即ThreadLocal的泛型值
ThreadLocalMap.Entry e = map.getEntry(this);
if (e != null) {
@SuppressWarnings("unchecked")
T result = (T)e.value;
return result;
}
}
return setInitialValue();
}
ThreadLocalMap的Entry數組
static class ThreadLocalMap {
static class Entry extends WeakReference<ThreadLocal<?>> {
/** The value associated with this ThreadLocal. */
Object value;
Entry(ThreadLocal<?> k, Object v) {
super(k);
value = v;
}
}
}
所以怎麼回答「ThreadLocal的實現原理」？如下，最好是能結合以上結構圖一起說明哈~
❝❞
- Thread類有一個類型爲ThreadLocal.ThreadLocalMap的實例變量threadLocals，即每個線程都有一個屬於自己的ThreadLocalMap。
- ThreadLocalMap內部維護着Entry數組，每個Entry代表一個完整的對象，key是ThreadLocal本身，value是ThreadLocal的泛型值。
- 每個線程在往ThreadLocal裏設置值的時候，都是往自己的ThreadLocalMap裏存，讀也是以某個ThreadLocal作爲引用，在自己的map裏找對應的key，從而實現了線程隔離。
ThreadLocal 內存泄露問題
先看看一下的TreadLocal的引用示意圖哈，
ThreadLocalMap中使用的 key 爲 ThreadLocal 的弱引用，如下
❝弱引用：只要垃圾回收機制一運行，不管JVM的內存空間是否充足，都會回收該對象佔用的內存。
❞
弱引用比較容易被回收。因此，如果ThreadLocal（ThreadLocalMap的Key）被垃圾回收器回收了，但是因爲ThreadLocalMap生命週期和Thread是一樣的，它這時候如果不被回收，就會出現這種情況：ThreadLocalMap的key沒了，value還在，這就會「造成了內存泄漏問題」。
如何「解決內存泄漏問題」？使用完ThreadLocal後，及時調用remove()方法釋放內存空間。
ThreadLocal的應用場景
- 數據庫連接池
- 會話管理中使用
3. synchronized和ReentrantLock的區別？
我記得校招的時候，這道面試題出現的頻率還是挺高的~可以從鎖的實現、功能特點、性能等幾個維度去回答這個問題，
- 「鎖的實現：」 synchronized是Java語言的關鍵字，基於JVM實現。而ReentrantLock是基於JDK的API層面實現的（一般是lock()和unlock()方法配合try/finally 語句塊來完成。）
- 「性能：」 在JDK1.6鎖優化以前，synchronized的性能比ReenTrantLock差很多。但是JDK6開始，增加了適應性自旋、鎖消除等，兩者性能就差不多了。
- 「功能特點：」 ReentrantLock 比 synchronized 增加了一些高級功能，如等待可中斷、可實現公平鎖、可實現選擇性通知。
❝❞
- ReentrantLock提供了一種能夠中斷等待鎖的線程的機制，通過lock.lockInterruptibly()來實現這個機制。
- ReentrantLock可以指定是公平鎖還是非公平鎖。而synchronized只能是非公平鎖。所謂的公平鎖就是先等待的線程先獲得鎖。
- synchronized與wait()和notify()/notifyAll()方法結合實現等待/通知機制，ReentrantLock類藉助Condition接口與newCondition()方法實現。
- ReentrantLock需要手工聲明來加鎖和釋放鎖，一般跟finally配合釋放鎖。而synchronized不用手動釋放鎖。
4. 說說CountDownLatch與CyclicBarrier區別
- CountDownLatch：一個或者多個線程，等待其他多個線程完成某件事情之後才能執行;
- CyclicBarrier：多個線程互相等待，直到到達同一個同步點，再繼續一起執行。
舉個例子吧：
❝❞
- CountDownLatch：假設老師跟同學約定週末在公園門口集合，等人齊了再發門票。那麼，發門票（這個主線程），需要等各位同學都到齊（多個其他線程都完成），才能執行。
- CyclicBarrier:多名短跑運動員要開始田徑比賽，只有等所有運動員準備好，裁判纔會鳴槍開始，這時候所有的運動員纔會疾步如飛。
5. Fork/Join框架的理解
❝Fork/Join框架是Java7提供的一個用於並行執行任務的框架，是一個把大任務分割成若干個小任務，最終彙總每個小任務結果後得到大任務結果的框架。
❞
Fork/Join框架需要理解兩個點，「分而治之」和「工作竊取算法」。
「分而治之」
以上Fork/Join框架的定義，就是分而治之思想的體現啦
「工作竊取算法」
把大任務拆分成小任務，放到不同隊列執行，交由不同的線程分別執行時。有的線程優先把自己負責的任務執行完了，其他線程還在慢慢悠悠處理自己的任務，這時候爲了充分提高效率，就需要工作盜竊算法啦~
工作盜竊算法就是，「某個線程從其他隊列中竊取任務進行執行的過程」。一般就是指做得快的線程（盜竊線程）搶慢的線程的任務來做，同時爲了減少鎖競爭，通常使用雙端隊列，即快線程和慢線程各在一端。
6. 爲什麼我們調用start()方法時會執行run()方法，爲什麼我們不能直接調用run()方法？
看看Thread的start方法說明哈~
/**
* Causes this thread to begin execution; the Java Virtual Machine
* calls the <code>run</code> method of this thread.
* <p>
* The result is that two threads are running concurrently: the
* current thread (which returns from the call to the
* <code>start</code> method) and the other thread (which executes its
* <code>run</code> method).
* <p>
* It is never legal to start a thread more than once.
* In particular, a thread may not be restarted once it has completed
* execution.
*
* @exception IllegalThreadStateException if the thread was already
* started.
* @see #run()
* @see #stop()
*/
public synchronized void start() {
......
}
JVM執行start方法，會另起一條線程執行thread的run方法，這才起到多線程的效果~ 「爲什麼我們不能直接調用run()方法？」如果直接調用Thread的run()方法，其方法還是運行在主線程中，沒有起到多線程效果。
7. CAS？CAS 有什麼缺陷，如何解決？
CAS,Compare and Swap，比較並交換；
❝CAS 涉及3個操作數，內存地址值V，預期原值A，新值B；如果內存位置的值V與預期原A值相匹配，就更新爲新值B，否則不更新
❞
CAS有什麼缺陷？
「ABA 問題」
❝併發環境下，假設初始條件是A，去修改數據時，發現是A就會執行修改。但是看到的雖然是A，中間可能發生了A變B，B又變回A的情況。此時A已經非彼A，數據即使成功修改，也可能有問題。
❞
可以通過AtomicStampedReference「解決ABA問題」，它，一個帶有標記的原子引用類，通過控制變量值的版本來保證CAS的正確性。
「循環時間長開銷」
❝自旋CAS，如果一直循環執行，一直不成功，會給CPU帶來非常大的執行開銷。
❞
很多時候，CAS思想體現，是有個自旋次數的，就是爲了避開這個耗時問題~
「只能保證一個變量的原子操作。」
❝CAS 保證的是對一個變量執行操作的原子性，如果對多個變量操作時，CAS 目前無法直接保證操作的原子性的。
❞
可以通過這兩個方式解決這個問題：
❝❞
- 使用互斥鎖來保證原子性；
- 將多個變量封裝成對象，通過AtomicReference來保證原子性。
9. 如何保證多線程下i++ 結果正確？
- 使用循環CAS，實現i++原子操作
- 使用鎖機制，實現i++原子操作
- 使用synchronized，實現i++原子操作
沒有代碼demo，感覺是沒有靈魂的~ 如下：
/**
* @Author 撿田螺的小男孩
*/
public class AtomicIntegerTest {
private static AtomicInteger atomicInteger = new AtomicInteger(0);
public static void main(String[] args) throws InterruptedException {
testIAdd();
}
private static void testIAdd() throws InterruptedException {
//創建線程池
ExecutorService executorService = Executors.newFixedThreadPool(2);
for (int i = 0; i < 1000; i++) {
executorService.execute(() -> {
for (int j = 0; j < 2; j++) {
//自增並返回當前值
int andIncrement = atomicInteger.incrementAndGet();
System.out.println("線程:" + Thread.currentThread().getName() + " count=" + andIncrement);
}
});
}
executorService.shutdown();
Thread.sleep(100);
System.out.println("最終結果是 ：" + atomicInteger.get());
}
}
運行結果：
... 線程:pool-1-thread-1 count=1997 線程:pool-1-thread-1 count=1998 線程:pool-1-thread-1 count=1999 線程:pool-1-thread-2 count=315 線程:pool-1-thread-2 count=2000 最終結果是 ：2000
10. 如何檢測死鎖？怎麼預防死鎖？死鎖四個必要條件
死鎖是指多個線程因競爭資源而造成的一種互相等待的僵局。如圖感受一下：
「死鎖的四個必要條件：」
- 互斥：一次只有一個進程可以使用一個資源。其他進程不能訪問已分配給其他進程的資源。
- 佔有且等待：當一個進程在等待分配得到其他資源時，其繼續佔有已分配得到的資源。
- 非搶佔：不能強行搶佔進程中已佔有的資源。
- 循環等待：存在一個封閉的進程鏈，使得每個資源至少佔有此鏈中下一個進程所需要的一個資源。
「如何預防死鎖？」
- 加鎖順序（線程按順序辦事）
- 加鎖時限 （線程請求所加上權限，超時就放棄，同時釋放自己佔有的鎖）
- 死鎖檢測