前言

并發(fā)編程是面試中必問(wèn)的知識(shí)點(diǎn)之一，所以本文整理了一些最為常見(jiàn)的并發(fā)面試題，一起來(lái)看吧~

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

synchronized的實(shí)現(xiàn)原理

• synchronized作用于「方法」或者「代碼塊」，保證被修飾的代碼在同一時(shí)間只能被一個(gè)線程訪問(wèn)。

• synchronized修飾代碼塊時(shí)，JVM采用「monitorenter、monitorexit」兩個(gè)指令來(lái)實(shí)現(xiàn)同步

• synchronized修飾同步方法時(shí)，JVM采用「ACC_SYNCHRONIZED」標(biāo)記符來(lái)實(shí)現(xiàn)同步

• monitorenter、monitorexit或者ACC_SYNCHRONIZED都是「基于Monitor實(shí)現(xiàn)」的

• 實(shí)例對(duì)象里有對(duì)象頭，對(duì)象頭里面有Mark Word，Mark Word指針指向了「monitor」

• Monitor其實(shí)是一種「同步工具」，也可以說(shuō)是一種「同步機(jī)制」。

• 在Java虛擬機(jī)（HotSpot）中，Monitor是由「ObjectMonitor實(shí)現(xiàn)」的。ObjectMonitor體現(xiàn)出Monitor的工作原理~

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

ObjectMonitor的幾個(gè)關(guān)鍵屬性 _count、_recursions、_owner、_WaitSet、 _EntryList 體現(xiàn)了monitor的工作原理

鎖優(yōu)化

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

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

?

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

?

• 偏向鎖：在無(wú)競(jìng)爭(zhēng)的情況下，把整個(gè)同步都消除掉，CAS操作都不做。

• 輕量級(jí)鎖：在沒(méi)有多線程競(jìng)爭(zhēng)時(shí)，相對(duì)重量級(jí)鎖，減少操作系統(tǒng)互斥量帶來(lái)的性能消耗。但是，如果存在鎖競(jìng)爭(zhēng)，除了互斥量本身開(kāi)銷，還額外有CAS操作的開(kāi)銷。

• 自旋鎖：減少不必要的CPU上下文切換。在輕量級(jí)鎖升級(jí)為重量級(jí)鎖時(shí)，就使用了自旋加鎖的方式

• 鎖粗化：將多個(gè)連續(xù)的加鎖、解鎖操作連接在一起，擴(kuò)展成一個(gè)范圍更大的鎖。

?

舉個(gè)例子，買門(mén)票進(jìn)動(dòng)物園。老師帶一群小朋友去參觀，驗(yàn)票員如果知道他們是個(gè)集體，就可以把他們看成一個(gè)整體（鎖租化），一次性驗(yàn)票過(guò)，而不需要一個(gè)個(gè)找他們驗(yàn)票。

?

• 鎖消除:虛擬機(jī)即時(shí)編譯器在運(yùn)行時(shí)，對(duì)一些代碼上要求同步，但是被檢測(cè)到不可能存在共享數(shù)據(jù)競(jìng)爭(zhēng)的鎖進(jìn)行削除。

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

2. ThreadLocal原理，使用注意點(diǎn)，應(yīng)用場(chǎng)景有哪些？

回答四個(gè)主要點(diǎn)：

• ThreadLocal是什么?

• ThreadLocal原理

• ThreadLocal使用注意點(diǎn)

• ThreadLocal的應(yīng)用場(chǎng)景

ThreadLocal是什么?

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

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

ThreadLocal原理

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

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

• Thread對(duì)象中持有一個(gè)ThreadLocal.ThreadLocalMap的成員變量。

• ThreadLocalMap內(nèi)部維護(hù)了Entry數(shù)組，每個(gè)Entry代表一個(gè)完整的對(duì)象，key是ThreadLocal本身，value是ThreadLocal的泛型值。

對(duì)照著幾段關(guān)鍵源碼來(lái)看，更容易理解一點(diǎ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)前線程tThreadLocalMap?map?=?getMap(t);??//根據(jù)當(dāng)前線程獲取到ThreadLocalMapif?(map?!=?null)map.set(this,?value);?//K，V設(shè)置到ThreadLocalMap中elsecreateMap(t,?value);?//創(chuàng)建一個(gè)新的ThreadLocalMap}public?T?get()?{Thread?t?=?Thread.currentThread();//獲取當(dāng)前線程tThreadLocalMap?map?=?getMap(t);//根據(jù)當(dāng)前線程獲取到ThreadLocalMapif?(map?!=?null)?{//由this（即ThreadLoca對(duì)象）得到對(duì)應(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的實(shí)現(xiàn)原理」？如下，最好是能結(jié)合以上結(jié)構(gòu)圖一起說(shuō)明哈~

?

• Thread類有一個(gè)類型為T(mén)hreadLocal.ThreadLocalMap的實(shí)例變量threadLocals，即每個(gè)線程都有一個(gè)屬于自己的ThreadLocalMap。

• ThreadLocalMap內(nèi)部維護(hù)著Entry數(shù)組，每個(gè)Entry代表一個(gè)完整的對(duì)象，key是ThreadLocal本身，value是ThreadLocal的泛型值。

• 每個(gè)線程在往ThreadLocal里設(shè)置值的時(shí)候，都是往自己的ThreadLocalMap里存，讀也是以某個(gè)ThreadLocal作為引用，在自己的map里找對(duì)應(yīng)的key，從而實(shí)現(xiàn)了線程隔離。

?

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

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

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

?

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

?

弱引用比較容易被回收。因此，如果ThreadLocal（ThreadLocalMap的Key）被垃圾回收器回收了，但是因?yàn)門(mén)hreadLocalMap生命周期和Thread是一樣的，它這時(shí)候如果不被回收，就會(huì)出現(xiàn)這種情況：ThreadLocalMap的key沒(méi)了，value還在，這就會(huì)「造成了內(nèi)存泄漏問(wèn)題」。

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

ThreadLocal的應(yīng)用場(chǎng)景

• 數(shù)據(jù)庫(kù)連接池

• 會(huì)話管理中使用

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

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

• 「鎖的實(shí)現(xiàn)：」 synchronized是Java語(yǔ)言的關(guān)鍵字，基于JVM實(shí)現(xiàn)。而ReentrantLock是基于JDK的API層面實(shí)現(xiàn)的（一般是lock()和unlock()方法配合try/finally 語(yǔ)句塊來(lái)完成。）

• 「性能：」 在JDK1.6鎖優(yōu)化以前，synchronized的性能比ReenTrantLock差很多。但是JDK6開(kāi)始，增加了適應(yīng)性自旋、鎖消除等，兩者性能就差不多了。

• 「功能特點(diǎn)：」 ReentrantLock 比 synchronized 增加了一些高級(jí)功能，如等待可中斷、可實(shí)現(xiàn)公平鎖、可實(shí)現(xiàn)選擇性通知。

?

• ReentrantLock提供了一種能夠中斷等待鎖的線程的機(jī)制，通過(guò)lock.lockInterruptibly()來(lái)實(shí)現(xiàn)這個(gè)機(jī)制。

• ReentrantLock可以指定是公平鎖還是非公平鎖。而synchronized只能是非公平鎖。所謂的公平鎖就是先等待的線程先獲得鎖。

• synchronized與wait()和notify()/notifyAll()方法結(jié)合實(shí)現(xiàn)等待/通知機(jī)制，ReentrantLock類借助Condition接口與newCondition()方法實(shí)現(xiàn)。

• ReentrantLock需要手工聲明來(lái)加鎖和釋放鎖，一般跟finally配合釋放鎖。而synchronized不用手動(dòng)釋放鎖。

?

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

• CountDownLatch：一個(gè)或者多個(gè)線程，等待其他多個(gè)線程完成某件事情之后才能執(zhí)行;

• CyclicBarrier：多個(gè)線程互相等待，直到到達(dá)同一個(gè)同步點(diǎn)，再繼續(xù)一起執(zhí)行。

舉個(gè)例子吧：

?

• CountDownLatch：假設(shè)老師跟同學(xué)約定周末在公園門(mén)口集合，等人齊了再發(fā)門(mén)票。那么，發(fā)門(mén)票（這個(gè)主線程），需要等各位同學(xué)都到齊（多個(gè)其他線程都完成），才能執(zhí)行。

• CyclicBarrier:多名短跑運(yùn)動(dòng)員要開(kāi)始田徑比賽，只有等所有運(yùn)動(dòng)員準(zhǔn)備好，裁判才會(huì)鳴槍開(kāi)始，這時(shí)候所有的運(yùn)動(dòng)員才會(huì)疾步如飛。

?

5. Fork/Join框架的理解

?

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

?

Fork/Join框架需要理解兩個(gè)點(diǎn)，「分而治之」和「工作竊取算法」。

「分而治之」

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

「工作竊取算法」

把大任務(wù)拆分成小任務(wù)，放到不同隊(duì)列執(zhí)行，交由不同的線程分別執(zhí)行時(shí)。有的線程優(yōu)先把自己負(fù)責(zé)的任務(wù)執(zhí)行完了，其他線程還在慢慢悠悠處理自己的任務(wù)，這時(shí)候?yàn)榱顺浞痔岣咝?#xff0c;就需要工作盜竊算法啦~

工作盜竊算法就是，「某個(gè)線程從其他隊(duì)列中竊取任務(wù)進(jìn)行執(zhí)行的過(guò)程」。一般就是指做得快的線程（盜竊線程）搶慢的線程的任務(wù)來(lái)做，同時(shí)為了減少鎖競(jìng)爭(zhēng)，通常使用雙端隊(duì)列，即快線程和慢線程各在一端。

6. 為什么我們調(diào)用start()方法時(shí)會(huì)執(zhí)行run()方法，為什么我們不能直接調(diào)用run()方法？

看看Thread的start方法說(shuō)明哈~

????/***?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方法，會(huì)另起一條線程執(zhí)行thread的run方法，這才起到多線程的效果~ 「為什么我們不能直接調(diào)用run()方法？」如果直接調(diào)用Thread的run()方法，其方法還是運(yùn)行在主線程中，沒(méi)有起到多線程效果。

7. CAS？CAS 有什么缺陷，如何解決？

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

?

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

?

CAS有什么缺陷？

「ABA 問(wèn)題」

?

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

?

可以通過(guò)AtomicStampedReference「解決ABA問(wèn)題」，它，一個(gè)帶有標(biāo)記的原子引用類，通過(guò)控制變量值的版本來(lái)保證CAS的正確性。

「循環(huán)時(shí)間長(zhǎng)開(kāi)銷」

?

自旋CAS，如果一直循環(huán)執(zhí)行，一直不成功，會(huì)給CPU帶來(lái)非常大的執(zhí)行開(kāi)銷。

?

很多時(shí)候，CAS思想體現(xiàn)，是有個(gè)自旋次數(shù)的，就是為了避開(kāi)這個(gè)耗時(shí)問(wèn)題~

「只能保證一個(gè)變量的原子操作。」

?

CAS 保證的是對(duì)一個(gè)變量執(zhí)行操作的原子性，如果對(duì)多個(gè)變量操作時(shí)，CAS 目前無(wú)法直接保證操作的原子性的。

?

可以通過(guò)這兩個(gè)方式解決這個(gè)問(wèn)題：

?

• 使用互斥鎖來(lái)保證原子性；

• 將多個(gè)變量封裝成對(duì)象，通過(guò)AtomicReference來(lái)保證原子性。

?

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

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

• 使用循環(huán)CAS，實(shí)現(xiàn)i++原子操作

• 使用鎖機(jī)制，實(shí)現(xiàn)i++原子操作

• 使用synchronized，實(shí)現(xiàn)i++原子操作

沒(méi)有代碼demo，感覺(jué)是沒(méi)有靈魂的~ 如下：

/***??@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. 如何檢測(cè)死鎖？怎么預(yù)防死鎖？死鎖四個(gè)必要條件

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

• 互斥：一次只有一個(gè)進(jìn)程可以使用一個(gè)資源。其他進(jìn)程不能訪問(wèn)已分配給其他進(jìn)程的資源。

• 占有且等待：當(dāng)一個(gè)進(jìn)程在等待分配得到其他資源時(shí)，其繼續(xù)占有已分配得到的資源。

• 非搶占：不能強(qiáng)行搶占進(jìn)程中已占有的資源。

• 循環(huán)等待：存在一個(gè)封閉的進(jìn)程鏈，使得每個(gè)資源至少占有此鏈中下一個(gè)進(jìn)程所需要的一個(gè)資源。

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

• 加鎖順序（線程按順序辦事）

• 加鎖時(shí)限 （線程請(qǐng)求所加上權(quán)限，超時(shí)就放棄，同時(shí)釋放自己占有的鎖）

• 死鎖檢測(cè)

參考與感謝

牛頓說(shuō)，我之所以看得遠(yuǎn)，是因?yàn)槲艺驹诰奕说募绨蛏蟸 謝謝以下各位前輩哈~

• 面試必問(wèn)的CAS，你懂了嗎？^[3]

• Java多線程：死鎖^[4]

• ReenTrantLock可重入鎖（和synchronized的區(qū)別）總結(jié)^[5]

• 聊聊并發(fā)（八）——Fork/Join 框架介紹^[6]

Reference

[1]

Synchronized解析——如果你愿意一層一層剝開(kāi)我的心: https://juejin.im/post/5d5374076fb9a06ac76da894#comment

[2]

CAS樂(lè)觀鎖解決并發(fā)問(wèn)題的一次實(shí)踐: https://juejin.im/post/5d0616ade51d457756536791

[3]

面試必問(wèn)的CAS，你懂了嗎？: https://blog.csdn.net/v123411739/article/details/79561458

[4]

Java多線程：死鎖: https://www.cnblogs.com/xiaoxi/p/8311034.html

[5]

ReenTrantLock可重入鎖（和synchronized的區(qū)別）總結(jié): https://blog.csdn.net/qq838642798/article/details/65441415

[6]

聊聊并發(fā)（八）——Fork/Join 框架介紹: https://www.infoq.cn/article/fork-join-introduction

往期推薦

被問(wèn)哭了，一位小姐姐的阿里面經(jīng)！(附部分答案)

不要一把梭了，這才是SQL優(yōu)化的正確姿勢(shì)！|原創(chuàng)干貨

關(guān)注下方二維碼，每一天都有干貨！

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的最常见并发面试题整理！（速度收藏）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。