1. synchronized的實現(xiàn)原理以及鎖優(yōu)化躏尉？

synchronized的實現(xiàn)原理

1. synchronized作用于「方法」或者「代碼塊」，保證被修飾的代碼在同一時間只能被一個線程訪問不翩。
2. synchronized修飾代碼塊時盟戏，JVM采用「monitorenter咖杂、monitorexit」兩個指令來實現(xiàn)同步
3. synchronized修飾同步方法時，JVM采用「ACC_SYNCHRONIZED」標(biāo)記符來實現(xiàn)同步
4. monitorenter铭腕、monitorexit或者ACC_SYNCHRONIZED都是「基于Monitor實現(xiàn)」的
5. 實例對象里有對象頭银择，對象頭里面有Mark Word，Mark Word指針指向了「monitor」
6. Monitor其實是一種「同步工具」累舷，也可以說是一種「同步機(jī)制」浩考。
7. 在Java虛擬機(jī)（HotSpot）中，Monitor是由「ObjectMonitor實現(xiàn)」的被盈。ObjectMonitor體現(xiàn)出Monitor的工作原理~

ObjectMonitor() { _header = NULL; _count = 0; // 記錄線程獲取鎖的次數(shù) _waiters = 0, _recursions = 0; //鎖的重入次數(shù) _object = NULL; _owner = NULL; // 指向持有ObjectMonitor對象的線程 _WaitSet = NULL; // 處于wait狀態(tài)的線程析孽，會被加入到_WaitSet _WaitSetLock = 0 ; _Responsible = NULL ; _succ = NULL ; _cxq = NULL ; FreeNext = NULL ; _EntryList = NULL ; // 處于等待鎖block狀態(tài)的線程，會被加入到該列表 _SpinFreq = 0 ; _SpinClock = 0 ; OwnerIsThread = 0 ; }

ObjectMonitor的幾個關(guān)鍵屬性 _count只怎、_recursions袜瞬、_owner、_WaitSet身堡、 _EntryList 體現(xiàn)了monitor的工作原理

鎖優(yōu)化

在討論鎖優(yōu)化前邓尤，先看看JAVA對象頭(32位JVM)中Mark Word的結(jié)構(gòu)圖吧~

Mark Word存儲對象自身的運(yùn)行數(shù)據(jù)，如「哈希碼贴谎、GC分代年齡汞扎、鎖狀態(tài)標(biāo)志、偏向時間戳（Epoch）」 等擅这，為什么區(qū)分「偏向鎖澈魄、輕量級鎖、重量級鎖」等幾種鎖狀態(tài)呢仲翎？

?

在JDK1.6之前痹扇，synchronized的實現(xiàn)直接調(diào)用ObjectMonitor的enter和exit，這種鎖被稱之為「重量級鎖」谭确。從JDK6開始帘营，HotSpot虛擬機(jī)開發(fā)團(tuán)隊對Java中的鎖進(jìn)行優(yōu)化票渠，如增加了適應(yīng)性自旋逐哈、鎖消除、鎖粗化问顷、輕量級鎖和偏向鎖等優(yōu)化策略昂秃。

?

1. 偏向鎖：在無競爭的情況下禀梳，把整個同步都消除掉，CAS操作都不做肠骆。
2. 輕量級鎖：在沒有多線程競爭時算途，相對重量級鎖，減少操作系統(tǒng)互斥量帶來的性能消耗蚀腿。但是嘴瓤，如果存在鎖競爭，除了互斥量本身開銷莉钙，還額外有CAS操作的開銷廓脆。
3. 自旋鎖：減少不必要的CPU上下文切換。在輕量級鎖升級為重量級鎖時磁玉，就使用了自旋加鎖的方式
4. 鎖粗化：將多個連續(xù)的加鎖停忿、解鎖操作連接在一起，擴(kuò)展成一個范圍更大的鎖蚊伞。

?

舉個例子席赂，買門票進(jìn)動物園。老師帶一群小朋友去參觀时迫，驗票員如果知道他們是個集體颅停，就可以把他們看成一個整體（鎖租化），一次性驗票過别垮，而不需要一個個找他們驗票便监。

?

1. 鎖消除:虛擬機(jī)即時編譯器在運(yùn)行時，對一些代碼上要求同步碳想，但是被檢測到不可能存在共享數(shù)據(jù)競爭的鎖進(jìn)行削除烧董。

有興趣的朋友們可以看看我這篇文章： Synchronized解析——如果你愿意一層一層剝開我的心[1]

2. ThreadLocal原理，使用注意點胧奔，應(yīng)用場景有哪些逊移？

回答四個主要點：

1. ThreadLocal是什么?
2. ThreadLocal原理
3. ThreadLocal使用注意點
4. ThreadLocal的應(yīng)用場景

ThreadLocal是什么?

ThreadLocal，即線程本地變量龙填。如果你創(chuàng)建了一個ThreadLocal變量胳泉，那么訪問這個變量的每個線程都會有這個變量的一個本地拷貝，多個線程操作這個變量的時候岩遗，實際是操作自己本地內(nèi)存里面的變量扇商，從而起到線程隔離的作用，避免了線程安全問題宿礁。

//創(chuàng)建一個ThreadLocal變量 static ThreadLocal<String> localVariable = new ThreadLocal<>();

ThreadLocal原理

ThreadLocal內(nèi)存結(jié)構(gòu)圖：

由結(jié)構(gòu)圖是可以看出：

1. Thread對象中持有一個ThreadLocal.ThreadLocalMap的成員變量案铺。
2. ThreadLocalMap內(nèi)部維護(hù)了Entry數(shù)組，每個Entry代表一個完整的對象梆靖，key是ThreadLocal本身控汉，value是ThreadLocal的泛型值笔诵。

對照著幾段關(guān)鍵源碼來看，更容易理解一點哈~

public class Thread implements Runnable { //ThreadLocal.ThreadLocalMap是Thread的屬性 ThreadLocal.ThreadLocalMap threadLocals = null; }

ThreadLocal中的關(guān)鍵方法set()和get()

public void set(T value) { Thread t = Thread.currentThread(); //獲取當(dāng)前線程t ThreadLocalMap map = getMap(t); //根據(jù)當(dāng)前線程獲取到ThreadLocalMap if (map != null) map.set(this, value); //K姑子，V設(shè)置到ThreadLocalMap中 else createMap(t, value); //創(chuàng)建一個新的ThreadLocalMap } public T get() { Thread t = Thread.currentThread();//獲取當(dāng)前線程t ThreadLocalMap map = getMap(t);//根據(jù)當(dāng)前線程獲取到ThreadLocalMap if (map != null) { //由this（即ThreadLoca對象）得到對應(yīng)的Value乎婿，即ThreadLocal的泛型值 ThreadLocalMap.Entry e = map.getEntry(this); if (e != null) { @SuppressWarnings("unchecked") T result = (T)e.value; return result; } } return setInitialValue(); }

ThreadLocalMap的Entry數(shù)組

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的實現(xiàn)原理」？如下街佑，最好是能結(jié)合以上結(jié)構(gòu)圖一起說明哈~

?

1. Thread類有一個類型為ThreadLocal.ThreadLocalMap的實例變量threadLocals谢翎，即每個線程都有一個屬于自己的ThreadLocalMap。
2. ThreadLocalMap內(nèi)部維護(hù)著Entry數(shù)組沐旨，每個Entry代表一個完整的對象岳服，key是ThreadLocal本身，value是ThreadLocal的泛型值希俩。
3. 每個線程在往ThreadLocal里設(shè)置值的時候吊宋，都是往自己的ThreadLocalMap里存，讀也是以某個ThreadLocal作為引用颜武，在自己的map里找對應(yīng)的key璃搜，從而實現(xiàn)了線程隔離。

?

ThreadLocal 內(nèi)存泄露問題

先看看一下的TreadLocal的引用示意圖哈鳞上，

ThreadLocalMap中使用的 key 為 ThreadLocal 的弱引用这吻，如下

?

弱引用：只要垃圾回收機(jī)制一運(yùn)行，不管JVM的內(nèi)存空間是否充足篙议，都會回收該對象占用的內(nèi)存唾糯。

?

弱引用比較容易被回收。因此鬼贱，如果ThreadLocal（ThreadLocalMap的Key）被垃圾回收器回收了移怯，但是因為ThreadLocalMap生命周期和Thread是一樣的，它這時候如果不被回收这难，就會出現(xiàn)這種情況：ThreadLocalMap的key沒了舟误，value還在，這就會「造成了內(nèi)存泄漏問題」姻乓。

如何「解決內(nèi)存泄漏問題」嵌溢？使用完ThreadLocal后，及時調(diào)用remove()方法釋放內(nèi)存空間蹋岩。

ThreadLocal的應(yīng)用場景

1. 數(shù)據(jù)庫連接池
2. 會話管理中使用

3. synchronized和ReentrantLock的區(qū)別赖草？

我記得校招的時候，這道面試題出現(xiàn)的頻率還是挺高的~可以從鎖的實現(xiàn)剪个、功能特點秧骑、性能等幾個維度去回答這個問題，

1. 「鎖的實現(xiàn)：」 synchronized是Java語言的關(guān)鍵字，基于JVM實現(xiàn)腿堤。而ReentrantLock是基于JDK的API層面實現(xiàn)的（一般是lock()和unlock()方法配合try/finally 語句塊來完成。）
2. 「性能：」 在JDK1.6鎖優(yōu)化以前如暖，synchronized的性能比ReenTrantLock差很多笆檀。但是JDK6開始，增加了適應(yīng)性自旋盒至、鎖消除等酗洒，兩者性能就差不多了。
3. 「功能特點：」 ReentrantLock 比 synchronized 增加了一些高級功能枷遂，如等待可中斷樱衷、可實現(xiàn)公平鎖、可實現(xiàn)選擇性通知酒唉。

?

1. ReentrantLock提供了一種能夠中斷等待鎖的線程的機(jī)制矩桂，通過lock.lockInterruptibly()來實現(xiàn)這個機(jī)制。
2. ReentrantLock可以指定是公平鎖還是非公平鎖痪伦。而synchronized只能是非公平鎖侄榴。所謂的公平鎖就是先等待的線程先獲得鎖。
3. synchronized與wait()和notify()/notifyAll()方法結(jié)合實現(xiàn)等待/通知機(jī)制网沾，ReentrantLock類借助Condition接口與newCondition()方法實現(xiàn)癞蚕。
4. ReentrantLock需要手工聲明來加鎖和釋放鎖，一般跟finally配合釋放鎖辉哥。而synchronized不用手動釋放鎖桦山。

?

4. 說說CountDownLatch與CyclicBarrier區(qū)別

1. CountDownLatch：一個或者多個線程，等待其他多個線程完成某件事情之后才能執(zhí)行;
2. CyclicBarrier：多個線程互相等待醋旦，直到到達(dá)同一個同步點恒水，再繼續(xù)一起執(zhí)行。

   

舉個例子吧：

?

1. CountDownLatch：假設(shè)老師跟同學(xué)約定周末在公園門口集合饲齐，等人齊了再發(fā)門票寇窑。那么，發(fā)門票（這個主線程）箩张，需要等各位同學(xué)都到齊（多個其他線程都完成）甩骏，才能執(zhí)行。
2. CyclicBarrier:多名短跑運(yùn)動員要開始田徑比賽先慷，只有等所有運(yùn)動員準(zhǔn)備好饮笛，裁判才會鳴槍開始，這時候所有的運(yùn)動員才會疾步如飛论熙。

?

5. Fork/Join框架的理解

?

Fork/Join框架是Java7提供的一個用于并行執(zhí)行任務(wù)的框架福青，是一個把大任務(wù)分割成若干個小任務(wù)，最終匯總每個小任務(wù)結(jié)果后得到大任務(wù)結(jié)果的框架。

?

Fork/Join框架需要理解兩個點无午，「分而治之」和「工作竊取算法」媒役。

「分而治之」

以上Fork/Join框架的定義，就是分而治之思想的體現(xiàn)啦

「工作竊取算法」

把大任務(wù)拆分成小任務(wù)宪迟，放到不同隊列執(zhí)行酣衷，交由不同的線程分別執(zhí)行時。有的線程優(yōu)先把自己負(fù)責(zé)的任務(wù)執(zhí)行完了次泽，其他線程還在慢慢悠悠處理自己的任務(wù)穿仪，這時候為了充分提高效率，就需要工作盜竊算法啦~

工作盜竊算法就是意荤，「某個線程從其他隊列中竊取任務(wù)進(jìn)行執(zhí)行的過程」啊片。一般就是指做得快的線程（盜竊線程）搶慢的線程的任務(wù)來做，同時為了減少鎖競爭玖像，通常使用雙端隊列紫谷，即快線程和慢線程各在一端。

6. 為什么我們調(diào)用start()方法時會執(zhí)行run()方法捐寥，為什么我們不能直接調(diào)用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執(zhí)行start方法，會另起一條線程執(zhí)行thread的run方法上真，這才起到多線程的效果~ 「為什么我們不能直接調(diào)用run()方法咬腋？」 如果直接調(diào)用Thread的run()方法，其方法還是運(yùn)行在主線程中睡互，沒有起到多線程效果根竿。

7. CAS？CAS 有什么缺陷就珠，如何解決寇壳？

CAS,Compare and Swap，比較并交換妻怎；

?

CAS 涉及3個操作數(shù)壳炎，內(nèi)存地址值V，預(yù)期原值A(chǔ)逼侦，新值B匿辩； 如果內(nèi)存位置的值V與預(yù)期原A值相匹配，就更新為新值B榛丢，否則不更新

?

CAS有什么缺陷铲球？

「ABA 問題」

?

并發(fā)環(huán)境下，假設(shè)初始條件是A晰赞，去修改數(shù)據(jù)時稼病，發(fā)現(xiàn)是A就會執(zhí)行修改选侨。但是看到的雖然是A，中間可能發(fā)生了A變B然走，B又變回A的情況援制。此時A已經(jīng)非彼A，數(shù)據(jù)即使成功修改芍瑞，也可能有問題晨仑。

?

可以通過AtomicStampedReference「解決ABA問題」，它啄巧，一個帶有標(biāo)記的原子引用類，通過控制變量值的版本來保證CAS的正確性掌栅。

「循環(huán)時間長開銷」

?

自旋CAS秩仆，如果一直循環(huán)執(zhí)行，一直不成功猾封，會給CPU帶來非常大的執(zhí)行開銷澄耍。

?

很多時候，CAS思想體現(xiàn)晌缘，是有個自旋次數(shù)的齐莲，就是為了避開這個耗時問題~

「只能保證一個變量的原子操作×谆」

?

CAS 保證的是對一個變量執(zhí)行操作的原子性选酗，如果對多個變量操作時，CAS 目前無法直接保證操作的原子性的岳枷。

?

可以通過這兩個方式解決這個問題：

?

1. 使用互斥鎖來保證原子性芒填；
2. 將多個變量封裝成對象，通過AtomicReference來保證原子性空繁。

?

有興趣的朋友可以看看我之前的這篇實戰(zhàn)文章哈~ CAS樂觀鎖解決并發(fā)問題的一次實踐[2]

9. 如何保證多線程下i++ 結(jié)果正確殿衰？

1. 使用循環(huán)CAS，實現(xiàn)i++原子操作
2. 使用鎖機(jī)制盛泡，實現(xiàn)i++原子操作
3. 使用synchronized闷祥，實現(xiàn)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 { //創(chuàng)建線程池 ExecutorService executorService = Executors.newFixedThreadPool(2); for (int i = 0; i < 1000; i++) { executorService.execute(() -> { for (int j = 0; j < 2; j++) { //自增并返回當(dāng)前值 int andIncrement = atomicInteger.incrementAndGet(); System.out.println("線程:" + Thread.currentThread().getName() + " count=" + andIncrement); } }); } executorService.shutdown(); Thread.sleep(100); System.out.println("最終結(jié)果是 ：" + atomicInteger.get()); } }

運(yùn)行結(jié)果：

... 線程: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 最終結(jié)果是 ：2000

10. 如何檢測死鎖傲诵？怎么預(yù)防死鎖凯砍？死鎖四個必要條件

死鎖是指多個線程因競爭資源而造成的一種互相等待的僵局。如圖感受一下：「死鎖的四個必要條件：」

1. 互斥：一次只有一個進(jìn)程可以使用一個資源拴竹。其他進(jìn)程不能訪問已分配給其他進(jìn)程的資源果覆。
2. 占有且等待：當(dāng)一個進(jìn)程在等待分配得到其他資源時，其繼續(xù)占有已分配得到的資源殖熟。
3. 非搶占：不能強(qiáng)行搶占進(jìn)程中已占有的資源局待。
4. 循環(huán)等待：存在一個封閉的進(jìn)程鏈，使得每個資源至少占有此鏈中下一個進(jìn)程所需要的一個資源。

「如何預(yù)防死鎖钳榨？」

1. 加鎖順序（線程按順序辦事）
2. 加鎖時限 （線程請求所加上權(quán)限舰罚，超時就放棄，同時釋放自己占有的鎖）
3. 死鎖檢測

參考與感謝

牛頓說薛耻，我之所以看得遠(yuǎn)营罢，是因為我站在巨人的肩膀上~ 謝謝以下各位前輩哈~

1. 面試必問的CAS，你懂了嗎饼齿？[3]
2. Java多線程：死鎖[4]
3. ReenTrantLock可重入鎖（和synchronized的區(qū)別）總結(jié)[5]
4. 聊聊并發(fā)（八）——Fork/Join 框架介紹[6]