????????這篇文章主要是對多線程的問題進行總結的，因此羅列了40個多線程的問題嵌施。

這些多線程的問題，有些來源于各大網站莽鸭、有些來源于自己的思考吗伤。可能有些問題網上有硫眨、可能有些問題對應的答案也有足淆、也可能有些各位網友也都看過，但是本文寫作的重心就是所有的問題都會按照自己的理解回答一遍礁阁，不會去看網上的答案巧号，因此可能有些問題講的不對，能指正的希望大家不吝指教姥闭。在這里也向大家推薦一個java架構師交流群：860170416丹鸿，里面各行各業(yè)的java大牛都在里面每天進行技術交流，有興趣的可以加群認識一下棚品，交流行業(yè)經驗靠欢，不懂的問題還可以在群里發(fā)出來廊敌，大家?guī)湍憬獯稹?/p>

多線程有什么用？

????????一個可能在很多人看來很扯淡的一個問題：我會用多線程就好了门怪，還管它有什么用骡澈？在我看來，這個回答更扯淡掷空。所謂"知其然知其所以然"肋殴，"會用"只是"知其然"，"為什么用"才是"知其所以然"坦弟，只有達到"知其然知其所以然"的程度才可以說是把一個知識點運用自如护锤。OK，下面說說我對這個問題的看法：

1.發(fā)揮多核CPU的優(yōu)勢

隨著工業(yè)的進步减拭，現在的筆記本蔽豺、臺式機乃至商用的應用服務器至少也都是雙核的螟深，4核款违、8核甚至16核的也都不少見腊瑟，如果是單線程的程序渴析，那么在雙核CPU上就浪費了50%岸晦，在4核CPU上就浪費了75%樊卓。單核CPU上所謂的"多線程"那是假的多線程壁畸，同一時間處理器只會處理一段邏輯茅郎，只不過線程之間切換得比較快癣朗，看著像多個線程"同時"運行罷了拾因。多核CPU上的多線程才是真正的多線程，它能讓你的多段邏輯同時工作旷余，多線程绢记，可以真正發(fā)揮出多核CPU的優(yōu)勢來，達到充分利用CPU的目的正卧。

2.防止阻塞

????????從程序運行效率的角度來看蠢熄，單核CPU不但不會發(fā)揮出多線程的優(yōu)勢，反而會因為在單核CPU上運行多線程導致線程上下文的切換炉旷，而降低程序整體的效率签孔。但是單核CPU我們還是要應用多線程，就是為了防止阻塞窘行。試想饥追，如果單核CPU使用單線程，那么只要這個線程阻塞了罐盔，比方說遠程讀取某個數據吧但绕，對端遲遲未返回又沒有設置超時時間，那么你的整個程序在數據返回回來之前就停止運行了翘骂。多線程可以防止這個問題壁熄，多條線程同時運行帚豪，哪怕一條線程的代碼執(zhí)行讀取數據阻塞碳竟，也不會影響其它任務的執(zhí)行草丧。

3.便于建模

????????這是另外一個沒有這么明顯的優(yōu)點了。假設有一個大的任務A莹桅，單線程編程昌执，那么就要考慮很多，建立整個程序模型比較麻煩诈泼。但是如果把這個大的任務A分解成幾個小任務懂拾，任務B、任務C铐达、任務D岖赋，分別建立程序模型，并通過多線程分別運行這幾個任務瓮孙，那就簡單很多了唐断。

創(chuàng)建線程的方式

比較常見的一個問題了，一般就是兩種：

1.繼承Thread類

2.實現Runnable接口

至于哪個好杭抠，不用說肯定是后者好脸甘，因為實現接口的方式比繼承類的方式更靈活，也能減少程序之間的耦合度偏灿，面向接口編程也是設計模式6大原則的核心丹诀。

其實還有第3種，點擊這里了解更多翁垂。

start()方法和run()方法的區(qū)別

????????只有調用了start()方法铆遭，才會表現出多線程的特性，不同線程的run()方法里面的代碼交替執(zhí)行沿猜。如果只是調用run()方法枚荣，那么代碼還是同步執(zhí)行的，必須等待一個線程的run()方法里面的代碼全部執(zhí)行完畢之后邢疙，另外一個線程才可以執(zhí)行其run()方法里面的代碼棍弄。

Runnable接口和Callable接口的區(qū)別

????????有點深的問題了，也看出一個Java程序員學習知識的廣度疟游。

Runnable接口中的run()方法的返回值是void呼畸，它做的事情只是純粹地去執(zhí)行run()方法中的代碼而已；Callable接口中的call()方法是有返回值的颁虐，是一個泛型蛮原，和Future、FutureTask配合可以用來獲取異步執(zhí)行的結果另绩。

這其實是很有用的一個特性儒陨，因為多線程相比單線程更難花嘶、更復雜的一個重要原因就是因為多線程充滿著未知性，某條線程是否執(zhí)行了蹦漠？某條線程執(zhí)行了多久椭员？某條線程執(zhí)行的時候我們期望的數據是否已經賦值完畢？無法得知笛园，我們能做的只是等待這條多線程的任務執(zhí)行完畢而已隘击。而Callable+Future/FutureTask卻可以獲取多線程運行的結果，可以在等待時間太長沒獲取到需要的數據的情況下取消該線程的任務研铆，真的是非常有用埋同。

CyclicBarrier和CountDownLatch的區(qū)別

????????兩個看上去有點像的類，都在java.util.concurrent下棵红，都可以用來表示代碼運行到某個點上凶赁，二者的區(qū)別在于：

1）CyclicBarrier的某個線程運行到某個點上之后，該線程即停止運行逆甜，直到所有的線程都到達了這個點虱肄，所有線程才重新運行；CountDownLatch則不是忆绰，某線程運行到某個點上之后浩峡，只是給某個數值-1而已，該線程繼續(xù)運行错敢。

2）CyclicBarrier只能喚起一個任務翰灾，CountDownLatch可以喚起多個任務。

3) CyclicBarrier可重用稚茅，CountDownLatch不可重用纸淮，計數值為0該CountDownLatch就不可再用了。

volatile關鍵字的作用

????????一個非常重要的問題亚享，是每個學習咽块、應用多線程的Java程序員都必須掌握的。理解volatile關鍵字的作用的前提是要理解Java內存模型欺税，這里就不講Java內存模型了侈沪，可以參見第31點，volatile關鍵字的作用主要有兩個：

1）多線程主要圍繞可見性和原子性兩個特性而展開晚凿，使用volatile關鍵字修飾的變量亭罪，保證了其在多線程之間的可見性，即每次讀取到volatile變量歼秽，一定是最新的數據应役。

2）代碼底層執(zhí)行不像我們看到的高級語言----Java程序這么簡單，它的執(zhí)行是Java代碼-->字節(jié)碼-->根據字節(jié)碼執(zhí)行對應的C/C++代碼-->C/C++代碼被編譯成匯編語言-->和硬件電路交互，現實中箩祥，為了獲取更好的性能JVM可能會對指令進行重排序院崇，多線程下可能會出現一些意想不到的問題。使用volatile則會對禁止語義重排序袍祖，當然這也一定程度上降低了代碼執(zhí)行效率底瓣。

從實踐角度而言，volatile的一個重要作用就是和CAS結合盲泛，保證了原子性键耕，詳細的可以參見java.util.concurrent.atomic包下的類，比如AtomicInteger屈雄，更多詳情請點擊這里進行學習。

什么是線程安全

又是一個理論的問題酒奶，各式各樣的答案有很多，我給出一個個人認為解釋地最好的：如果你的代碼在多線程下執(zhí)行和在單線程下執(zhí)行永遠都能獲得一樣的結果惋嚎，那么你的代碼就是線程安全的。

這個問題有值得一提的地方另伍，就是線程安全也是有幾個級別的：

1.不可變

像String、Integer温艇、Long這些，都是final類型的類勺爱，任何一個線程都改變不了它們的值，要改變除非新創(chuàng)建一個琐鲁，因此這些不可變對象不需要任何同步手段就可以直接在多線程環(huán)境下使用

2.絕對線程安全

不管運行時環(huán)境如何人灼，調用者都不需要額外的同步措施。要做到這一點通常需要付出許多額外的代價挡毅，Java中標注自己是線程安全的類，實際上絕大多數都不是線程安全的，不過絕對線程安全的類取逾，Java中也有，比方說CopyOnWriteArrayList苹支、CopyOnWriteArraySet

3.相對線程安全

相對線程安全也就是我們通常意義上所說的線程安全砾隅，像Vector這種，add债蜜、remove方法都是原子操作晴埂，不會被打斷，但也僅限于此寻定，如果有個線程在遍歷某個Vector儒洛、有個線程同時在add這個Vector，99%的情況下都會出現ConcurrentModificationException狼速，也就是fail-fast機制琅锻。

4.線程非安全

這個就沒什么好說的了，ArrayList向胡、LinkedList恼蓬、HashMap等都是線程非安全的類，點擊這里了解為什么不安全僵芹。

Java中如何獲取到線程dump文件

????????死循環(huán)处硬、死鎖、阻塞拇派、頁面打開慢等問題荷辕，打線程dump是最好的解決問題的途徑。所謂線程dump也就是線程堆棧攀痊，獲取到線程堆棧有兩步：

1）獲取到線程的pid桐腌，可以通過使用jps命令，在Linux環(huán)境下還可以使用ps -ef | grep java

2）打印線程堆棧苟径，可以通過使用jstack pid命令案站，在Linux環(huán)境下還可以使用kill -3 pid

另外提一點，Thread類提供了一個getStackTrace()方法也可以用于獲取線程堆棧棘街。這是一個實例方法蟆盐，因此此方法是和具體線程實例綁定的，每次獲取獲取到的是具體某個線程當前運行的堆棧遭殉。

一個線程如果出現了運行時異常會怎么樣

如果這個異常沒有被捕獲的話石挂，這個線程就停止執(zhí)行了痹愚。另外重要的一點是：如果這個線程持有某個某個對象的監(jiān)視器，那么這個對象監(jiān)視器會被立即釋放

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

????????通過在線程之間共享對象就可以了窖式，然后通過wait/notify/notifyAll动壤、await/signal/signalAll進行喚起和等待琼懊，比方說阻塞隊列BlockingQueue就是為線程之間共享數據而設計的

sleep方法和wait方法有什么區(qū)別

????????這個問題常問哼丈，sleep方法和wait方法都可以用來放棄CPU一定的時間，不同點在于如果線程持有某個對象的監(jiān)視器翅溺，sleep方法不會放棄這個對象的監(jiān)視器，wait方法會放棄這個對象的監(jiān)視器

生產者消費者模型的作用是什么

這個問題很理論吨拍，但是很重要：

1）通過平衡生產者的生產能力和消費者的消費能力來提升整個系統(tǒng)的運行效率网杆，這是生產者消費者模型最重要的作用

2）解耦碳却，這是生產者消費者模型附帶的作用昼浦，解耦意味著生產者和消費者之間的聯系少，聯系越少越可以獨自發(fā)展而不需要收到相互的制約

ThreadLocal有什么用

簡單說ThreadLocal就是一種以空間換時間的做法鸟蟹，在每個Thread里面維護了一個以開地址法實現的ThreadLocal.ThreadLocalMap建钥，把數據進行隔離熊经，數據不共享，自然就沒有線程安全方面的問題了

為什么wait()方法和notify()/notifyAll()方法要在同步塊中被調用

????????這是JDK強制的悉盆，wait()方法和notify()/notifyAll()方法在調用前都必須先獲得對象的鎖

wait()方法和notify()/notifyAll()方法在放棄對象監(jiān)視器時有什么區(qū)別

wait()方法和notify()/notifyAll()方法在放棄對象監(jiān)視器的時候的區(qū)別在于：wait()方法立即釋放對象監(jiān)視器焕盟，notify()/notifyAll()方法則會等待線程剩余代碼執(zhí)行完畢才會放棄對象監(jiān)視器脚翘。

為什么要使用線程池

????????避免頻繁地創(chuàng)建和銷毀線程来农，達到線程對象的重用沃于。另外海诲，使用線程池還可以根據項目靈活地控制并發(fā)的數目特幔。點擊這里學習線程池詳解。

怎么檢測一個線程是否持有對象監(jiān)視器

我也是在網上看到一道多線程面試題才知道有方法可以判斷某個線程是否持有對象監(jiān)視器：Thread類提供了一個holdsLock(Object obj)方法薄风，當且僅當對象obj的監(jiān)視器被某條線程持有的時候才會返回true遭赂，注意這是一個static方法撇他，這意味著"某條線程"指的是當前線程逆粹。

synchronized和ReentrantLock的區(qū)別

????????synchronized是和if炫惩、else他嚷、for芭毙、while一樣的關鍵字退敦，ReentrantLock是類侈百，這是二者的本質區(qū)別钝域。既然ReentrantLock是類例证，那么它就提供了比synchronized更多更靈活的特性迷捧，可以被繼承漠秋、可以有方法膛堤、可以有各種各樣的類變量，ReentrantLock比synchronized的擴展性體現在幾點上：

（1）ReentrantLock可以對獲取鎖的等待時間進行設置，這樣就避免了死鎖

（2）ReentrantLock可以獲取各種鎖的信息

（3）ReentrantLock可以靈活地實現多路通知

另外燕耿，二者的鎖機制其實也是不一樣的誉帅。ReentrantLock底層調用的是Unsafe的park方法加鎖右莱，synchronized操作的應該是對象頭中mark word慢蜓，這點我不能確定。

ConcurrentHashMap的并發(fā)度是什么

????????ConcurrentHashMap的并發(fā)度就是segment的大小氛悬，默認為16如捅，這意味著最多同時可以有16條線程操作ConcurrentHashMap，這也是ConcurrentHashMap對Hashtable的最大優(yōu)勢己肮，任何情況下谎僻，Hashtable能同時有兩條線程獲取Hashtable中的數據嗎戈稿？

ReadWriteLock是什么

????????首先明確一下讶舰，不是說ReentrantLock不好跳昼，只是ReentrantLock某些時候有局限鹅颊。如果使用ReentrantLock，可能本身是為了防止線程A在寫數據锚烦、線程B在讀數據造成的數據不一致涮俄，但這樣彻亲，如果線程C在讀數據吮廉、線程D也在讀數據宦芦，讀數據是不會改變數據的，沒有必要加鎖曼氛，但是還是加鎖了，降低了程序的性能徽级。

因為這個餐抢，才誕生了讀寫鎖ReadWriteLock旷痕。ReadWriteLock是一個讀寫鎖接口欺抗，ReentrantReadWriteLock是ReadWriteLock接口的一個具體實現强重，實現了讀寫的分離，讀鎖是共享的佃声，寫鎖是獨占的圾亏，讀和讀之間不會互斥志鹃，讀和寫弄跌、寫和讀尝苇、寫和寫之間才會互斥糠溜，提升了讀寫的性能非竿。

FutureTask是什么

????????這個其實前面有提到過红柱，FutureTask表示一個異步運算的任務。FutureTask里面可以傳入一個Callable的具體實現類韧骗，可以對這個異步運算的任務的結果進行等待獲取袍暴、判斷是否已經完成隶症、取消任務等操作蚂会。當然胁住，由于FutureTask也是Runnable接口的實現類，所以FutureTask也可以放入線程池中躲叼。

Linux環(huán)境下如何查找哪個線程使用CPU最長

????????這是一個比較偏實踐的問題枫慷，這種問題我覺得挺有意義的或听∷裥觯可以這么做：

（1）獲取項目的pid缸濒，jps或者ps -ef | grep java庇配，這個前面有講過

（2）top -H -p pid，順序不能改變

這樣就可以打印出當前的項目耀鸦，每條線程占用CPU時間的百分比袖订。注意這里打出的是LWP，也就是操作系統(tǒng)原生線程的線程號上沐，我筆記本山沒有部署Linux環(huán)境下的Java工程奄容，因此沒有辦法截圖演示昂勒，網友朋友們如果公司是使用Linux環(huán)境部署項目的話戈盈，可以嘗試一下谆刨。

????????使用"top -H -p pid"+"jps pid"可以很容易地找到某條占用CPU高的線程的線程堆棧痊夭，從而定位占用CPU高的原因，一般是因為不當的代碼操作導致了死循環(huán)虹曙。

最后提一點酝碳，"top -H -p pid"打出來的LWP是十進制的疏哗，"jps pid"打出來的本地線程號是十六進制的返奉，轉換一下衡瓶，就能定位到占用CPU高的線程的當前線程堆棧了牲证。

Java編程寫一個會導致死鎖的程序

????????第一次看到這個題目坦袍，覺得這是一個非常好的問題捂齐。很多人都知道死鎖是怎么一回事兒：線程A和線程B相互等待對方持有的鎖導致程序無限死循環(huán)下去。當然也僅限于此了包颁，問一下怎么寫一個死鎖的程序就不知道了娩嚼，這種情況說白了就是不懂什么是死鎖岳悟，懂一個理論就完事兒了贵少，實踐中碰到死鎖的問題基本上是看不出來的堆缘。

真正理解什么是死鎖吼肥，這個問題其實不難潜沦，幾個步驟：

1.兩個線程里面分別持有兩個Object對象：lock1和lock2。這兩個lock作為同步代碼塊的鎖涝影；

2.線程1的run()方法中同步代碼塊先獲取lock1的對象鎖燃逻，Thread.sleep(xxx)伯襟，時間不需要太多姆怪，50毫秒差不多了，然后接著獲取lock2的對象鎖俺附。這么做主要是為了防止線程1啟動一下子就連續(xù)獲得了lock1和lock2兩個對象的對象鎖

3.線程2的run)(方法中同步代碼塊先獲取lock2的對象鎖事镣，接著獲取lock1的對象鎖璃哟，當然這時lock1的對象鎖已經被線程1鎖持有随闪，線程2肯定是要等待線程1釋放lock1的對象鎖的蕴掏。這樣调鲸，線程1"睡覺"睡完藐石，線程2已經獲取了lock2的對象鎖了于微，線程1此時嘗試獲取lock2的對象鎖，便被阻塞驱证，此時一個死鎖就形成了抹锄。代碼就不寫了伙单，占的篇幅有點多吻育，Java多線程7：死鎖這篇文章里面有淤井，就是上面步驟的代碼實現。

怎么喚醒一個阻塞的線程

????????如果線程是因為調用了wait()缎除、sleep()或者join()方法而導致的阻塞器罐，可以中斷線程轰坊，并且通過拋出InterruptedException來喚醒它肴沫；如果線程遇到了IO阻塞颤芬，無能為力站蝠，因為IO是操作系統(tǒng)實現的卓鹿，Java代碼并沒有辦法直接接觸到操作系統(tǒng)吟孙。

不可變對象對多線程有什么幫助

????????前面有提到過的一個問題杰妓，不可變對象保證了對象的內存可見性巷挥，對不可變對象的讀取不需要進行額外的同步手段，提升了代碼執(zhí)行效率吸占。

什么是多線程的上下文切換

????????多線程的上下文切換是指CPU控制權由一個已經正在運行的線程切換到另外一個就緒并等待獲取CPU執(zhí)行權的線程的過程矾屯。

如果你提交任務時件蚕，線程池隊列已滿，這時會發(fā)生什么

????????這里區(qū)分一下：

1）如果使用的是無界隊列LinkedBlockingQueue牵啦，也就是無界隊列的話哈雏，沒關系裳瘪，繼續(xù)添加任務到阻塞隊列中等待執(zhí)行彭羹，因為LinkedBlockingQueue可以近乎認為是一個無窮大的隊列泪酱，可以無限存放任務

2）如果使用的是有界隊列比如ArrayBlockingQueue墓阀，任務首先會被添加到ArrayBlockingQueue中岂津，ArrayBlockingQueue滿了，會根據maximumPoolSize的值增加線程數量橱乱，如果增加了線程數量還是處理不過來泳叠，ArrayBlockingQueue繼續(xù)滿茶宵，那么則會使用拒絕策略RejectedExecutionHandler處理滿了的任務乌庶，默認是AbortPolicy

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

????????搶占式。一個線程用完CPU之后螃征，操作系統(tǒng)會根據線程優(yōu)先級盯滚、線程饑餓情況等數據算出一個總的優(yōu)先級并分配下一個時間片給某個線程執(zhí)行。

Thread.sleep(0)的作用是什么

????????這個問題和上面那個問題是相關的内列，我就連在一起了话瞧。由于Java采用搶占式的線程調度算法寝姿，因此可能會出現某條線程常常獲取到CPU控制權的情況会油，為了讓某些優(yōu)先級比較低的線程也能獲取到CPU控制權翻翩，可以使用Thread.sleep(0)手動觸發(fā)一次操作系統(tǒng)分配時間片的操作嫂冻，這也是平衡CPU控制權的一種操作塞椎。

什么是自旋

????????很多synchronized里面的代碼只是一些很簡單的代碼案狠，執(zhí)行時間非常快吹零，此時等待的線程都加鎖可能是一種不太值得的操作灿椅，因為線程阻塞涉及到用戶態(tài)和內核態(tài)切換的問題茫蛹。既然synchronized里面的代碼執(zhí)行得非秤ね荩快窃蹋，不妨讓等待鎖的線程不要被阻塞，而是在synchronized的邊界做忙循環(huán)匈辱，這就是自旋杀迹。如果做了多次忙循環(huán)發(fā)現還沒有獲得鎖树酪，再阻塞续语，這樣可能是一種更好的策略。

什么是Java內存模型

????????Java內存模型定義了一種多線程訪問Java內存的規(guī)范滥朱。Java內存模型要完整講不是這里幾句話能說清楚的徙邻，我簡單總結一下Java內存模型的幾部分內容：

1.Java內存模型將內存分為了主內存和工作內存畸裳。類的狀態(tài)怖糊，也就是類之間共享的變量，是存儲在主內存中的丰嘉，每次Java線程用到這些主內存中的變量的時候饮亏，會讀一次主內存中的變量路幸，并讓這些內存在自己的工作內存中有一份拷貝付翁，運行自己線程代碼的時候，用到這些變量砰识，操作的都是自己工作內存中的那一份。在線程代碼執(zhí)行完畢之后初斑，會將最新的值更新到主內存中去

????????2.定義了幾個原子操作见秤，用于操作主內存和工作內存中的變量

????????3.定義了volatile變量的使用規(guī)則

????????4.happens-before鹃答，即先行發(fā)生原則测摔，定義了操作A必然先行發(fā)生于操作B的一些規(guī)則避咆，比如在同一個線程內控制流前面的代碼一定先行發(fā)生于控制流后面的代碼、一個釋放鎖unlock的動作一定先行發(fā)生于后面對于同一個鎖進行鎖定lock的動作等等黄琼，只要符合這些規(guī)則整慎，則不需要額外做同步措施裤园，如果某段代碼不符合所有的happens-before規(guī)則拧揽，則這段代碼一定是線程非安全的

什么是CAS

CAS淤袜，全稱為Compare and Swap，即比較-替換铡羡。假設有三個操作數：內存值V烦周、舊的預期值A、要修改的值B漱贱，當且僅當預期值A和內存值V相同時蚜退，才會將內存值修改為B并返回true钻注，否則什么都不做并返回false。當然CAS一定要volatile變量配合捆交，這樣才能保證每次拿到的變量是主內存中最新的那個值品追，否則舊的預期值A對某條線程來說肉瓦，永遠是一個不會變的值A，只要某次CAS操作失敗胃惜，永遠都不可能成功泞莉。更多CAS詳情請點擊這里學習。

什么是樂觀鎖和悲觀鎖

1.樂觀鎖：就像它的名字一樣船殉，對于并發(fā)間操作產生的線程安全問題持樂觀狀態(tài)鲫趁，樂觀鎖認為競爭不總是會發(fā)生，因此它不需要持有鎖利虫，將比較-替換這兩個動作作為一個原子操作嘗試去修改內存中的變量挨厚，如果失敗則表示發(fā)生沖突，那么就應該有相應的重試邏輯糠惫。

????????2.悲觀鎖：還是像它的名字一樣，對于并發(fā)間操作產生的線程安全問題持悲觀狀態(tài)慌申，悲觀鎖認為競爭總是會發(fā)生，因此每次對某資源進行操作時，都會持有一個獨占的鎖法瑟，就像synchronized麻掸，不管三七二十一，直接上了鎖就操作資源了讶隐。

什么是AQS

????????簡單說一下AQS籽孙，AQS全稱為AbstractQueuedSychronizer瓜客，翻譯過來應該是抽象隊列同步器。

????????如果說java.util.concurrent的基礎是CAS的話，那么AQS就是整個Java并發(fā)包的核心了贴浙，ReentrantLock盯质、CountDownLatch、Semaphore等等都用到了它蔚袍。AQS實際上以雙向隊列的形式連接所有的Entry渠脉，比方說ReentrantLock鳞青，所有等待的線程都被放在一個Entry中并連成雙向隊列胶惰，前面一個線程使用ReentrantLock好了坊饶，則雙向隊列實際上的第一個Entry開始運行。

????????AQS定義了對雙向隊列所有的操作脓杉，而只開放了tryLock和tryRelease方法給開發(fā)者使用蕉堰，開發(fā)者可以根據自己的實現重寫tryLock和tryRelease方法须教，以實現自己的并發(fā)功能。

單例模式的線程安全性

老生常談的問題了，首先要說的是單例模式的線程安全意味著：某個類的實例在多線程環(huán)境下只會被創(chuàng)建一次出來。單例模式有很多種的寫法，我總結一下：

1.餓漢式單例模式的寫法：線程安全

2.懶漢式單例模式的寫法：非線程安全

3.雙檢鎖單例模式的寫法：線程安全

Semaphore有什么作用

Semaphore就是一個信號量，它的作用是限制某段代碼塊的并發(fā)數屈扎。Semaphore有一個構造函數，可以傳入一個int型整數n，表示某段代碼最多只有n個線程可以訪問闯传，如果超出了n共缕，那么請等待，等到某個線程執(zhí)行完畢這段代碼塊，下一個線程再進入魂毁。由此可以看出如果Semaphore構造函數中傳入的int型整數n=1垮斯，相當于變成了一個synchronized了曙旭。

?Hashtable的size()方法中明明只有一條語句"return count"，為什么還要做同步购对？

????????這是我之前的一個困惑贴见，不知道大家有沒有想過這個問題。某個方法中如果有多條語句，并且都在操作同一個類變量酥宴，那么在多線程環(huán)境下不加鎖，勢必會引發(fā)線程安全問題，這很好理解顾彰，但是size()方法明明只有一條語句，為什么還要加鎖建丧？

關于這個問題，在慢慢地工作、學習中福澡，有了理解册踩，主要原因有兩點：

1.同一時間只能有一條線程執(zhí)行固定類的同步方法挤渔，但是對于類的非同步方法，可以多條線程同時訪問鸟整。所以，這樣就有問題了钳垮，可能線程A在執(zhí)行Hashtable的put方法添加數據向瓷，線程B則可以正常調用size()方法讀取Hashtable中當前元素的個數哺徊，那讀取到的值可能不是最新的疗垛，可能線程A添加了完了數據破婆，但是沒有對size++嚎朽，線程B就已經讀取size了，那么對于線程B來說讀取到的size一定是不準確的咖耘。而給size()方法加了同步之后凰慈，意味著線程B調用size()方法只有在線程A調用put方法完畢之后才可以調用触创，這樣就保證了線程安全性

2.CPU執(zhí)行代碼，執(zhí)行的不是Java代碼，這點很關鍵熊痴，一定得記住许赃。Java代碼最終是被翻譯成機器碼執(zhí)行的咳胃，機器碼才是真正可以和硬件電路交互的代碼冗栗。即使你看到Java代碼只有一行，甚至你看到Java代碼編譯之后生成的字節(jié)碼也只有一行次绘，也不意味著對于底層來說這句語句的操作只有一個。一句"return count"假設被翻譯成了三句匯編語句執(zhí)行征椒，一句匯編語句和其機器碼做對應，完全可能執(zhí)行完第一句瓢省，線程就切換了。

線程類的構造方法、靜態(tài)塊是被哪個線程調用的

????????這是一個非常刁鉆和狡猾的問題当凡。請記壮自蕖：線程類的構造方法席镀、靜態(tài)塊是被new這個線程類所在的線程所調用的缺厉，而run方法里面的代碼才是被線程自身所調用的。

如果說上面的說法讓你感到困惑伍宦，那么我舉個例子芽死，假設Thread2中new了Thread1，main函數中new了Thread2次洼，那么：

1.Thread2的構造方法关贵、靜態(tài)塊是main線程調用的，Thread2的run()方法是Thread2自己調用的

2.Thread1的構造方法卖毁、靜態(tài)塊是Thread2調用的揖曾，Thread1的run()方法是Thread1自己調用的

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

同步塊亥啦，這意味著同步塊之外的代碼是異步執(zhí)行的炭剪，這比同步整個方法更提升代碼的效率。請知道一條原則：同步的范圍越小越好翔脱。

借著這一條奴拦，我額外提一點，雖說同步的范圍越少越好届吁，但是在Java虛擬機中還是存在著一種叫做鎖粗化的優(yōu)化方法错妖，這種方法就是把同步范圍變大。這是有用的疚沐，比方說StringBuffer暂氯，它是一個線程安全的類，自然最常用的append()方法是一個同步方法亮蛔，我們寫代碼的時候會反復append字符串痴施，這意味著要進行反復的加鎖->解鎖，這對性能不利究流，因為這意味著Java虛擬機在這條線程上要反復地在內核態(tài)和用戶態(tài)之間進行切換辣吃，因此Java虛擬機會將多次append方法調用的代碼進行一個鎖粗化的操作，將多次的append的操作擴展到append方法的頭尾芬探，變成一個大的同步塊神得，這樣就減少了加鎖-->解鎖的次數，有效地提升了代碼執(zhí)行的效率灯节。

高并發(fā)循头、任務執(zhí)行時間短的業(yè)務怎樣使用線程池绵估？并發(fā)不高、任務執(zhí)行時間長的業(yè)務怎樣使用線程池卡骂？并發(fā)高国裳、業(yè)務執(zhí)行時間長的業(yè)務怎樣使用線程池？

????????這是我在并發(fā)編程網上看到的一個問題全跨，把這個問題放在最后一個缝左，希望每個人都能看到并且思考一下，因為這個問題非常好浓若、非常實際渺杉、非常專業(yè)。關于這個問題挪钓，個人看法是：

1.高并發(fā)是越、任務執(zhí)行時間短的業(yè)務，線程池線程數可以設置為CPU核數+1碌上，減少線程上下文的切換

2.并發(fā)不高倚评、任務執(zhí)行時間長的業(yè)務要區(qū)分開看：

a.假如是業(yè)務時間長集中在IO操作上，也就是IO密集型的任務馏予，因為IO操作并不占用CPU天梧，所以不要讓所有的CPU閑下來，可以加大線程池中的線程數目霞丧，讓CPU處理更多的業(yè)務

b.假如是業(yè)務時間長集中在計算操作上呢岗，也就是計算密集型任務，這個就沒辦法了蛹尝，和（1）一樣吧后豫，線程池中的線程數設置得少一些，減少線程上下文的切換

c.并發(fā)高箩言、業(yè)務執(zhí)行時間長硬贯，解決這種類型任務的關鍵不在于線程池而在于整體架構的設計焕襟，看看這些業(yè)務里面某些數據是否能做緩存是第一步陨收，增加服務器是第二步，至于線程池的設置鸵赖，設置參考其他有關線程池的文章务漩。最后，業(yè)務執(zhí)行時間長的問題它褪，也可能需要分析一下饵骨，看看能不能使用中間件對任務進行拆分和解耦。

java的那些年微信號： java1024_

福利送上不謝：

1茫打、關注java的那些年公眾號居触，每期分享java技術干貨

2妖混、關注java的那些年能查看更多歷史干貨

3、點關注的轮洋，今年都脫單