阿里面試官總結40 個 Java 多線程問題


前言

這篇文章主要是對多線程的問題進行總結的句占,因此羅列了40個多線程的問題沪摄。

這些多線程的問題,有些來源于各大網(wǎng)站纱烘、有些來源于自己的思考杨拐。可能有些問題網(wǎng)上有擂啥、可能有些問題對應的答案也有哄陶、也可能有些各位網(wǎng)友也都看過,但是本文寫作的重心就是所有的問題都會按照自己的理解回答一遍哺壶,不會去看網(wǎng)上的答案屋吨,因此可能有些問題講的不對,能指正的希望大家不吝指教山宾。

40個問題匯總

1至扰、多線程有什么用?

一個可能在很多人看來很扯淡的一個問題:我會用多線程就好了资锰,還管它有什么用敢课?在我看來,這個回答更扯淡台妆。所謂”知其然知其所以然”翎猛,”會用”只是”知其然”,”為什么用”才是”知其所以然”接剩,只有達到”知其然知其所以然”的程度才可以說是把一個知識點運用自如切厘。OK,下面說說我對這個問題的看法:

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

隨著工業(yè)的進步懊缺,現(xiàn)在的筆記本疫稿、臺式機乃至商用的應用服務器至少也都是雙核的,4核鹃两、8核甚至16核的也都不少見遗座,如果是單線程的程序,那么在雙核CPU上就浪費了50%俊扳,在4核CPU上就浪費了75%途蒋。單核CPU上所謂的”多線程”那是假的多線程,同一時間處理器只會處理一段邏輯馋记,只不過線程之間切換得比較快号坡,看著像多個線程”同時”運行罷了懊烤。多核CPU上的多線程才是真正的多線程,它能讓你的多段邏輯同時工作宽堆,多線程腌紧,可以真正發(fā)揮出多核CPU的優(yōu)勢來,達到充分利用CPU的目的畜隶。

(2)防止阻塞

從程序運行效率的角度來看壁肋,單核CPU不但不會發(fā)揮出多線程的優(yōu)勢,反而會因為在單核CPU上運行多線程導致線程上下文的切換籽慢,而降低程序整體的效率浸遗。但是單核CPU我們還是要應用多線程,就是為了防止阻塞嗡综。試想乙帮,如果單核CPU使用單線程,那么只要這個線程阻塞了极景,比方說遠程讀取某個數(shù)據(jù)吧,對端遲遲未返回又沒有設置超時時間驾茴,那么你的整個程序在數(shù)據(jù)返回回來之前就停止運行了盼樟。多線程可以防止這個問題,多條線程同時運行锈至,哪怕一條線程的代碼執(zhí)行讀取數(shù)據(jù)阻塞晨缴,也不會影響其它任務的執(zhí)行。

(3)便于建模

這是另外一個沒有這么明顯的優(yōu)點了峡捡。假設有一個大的任務A击碗,單線程編程,那么就要考慮很多们拙,建立整個程序模型比較麻煩稍途。但是如果把這個大的任務A分解成幾個小任務,任務B砚婆、任務C械拍、任務D,分別建立程序模型装盯,并通過多線程分別運行這幾個任務坷虑,那就簡單很多了。

2埂奈、創(chuàng)建線程的方式

比較常見的一個問題了迄损,一般就是兩種:

(1)繼承Thread類

(2)實現(xiàn)Runnable接口

至于哪個好,不用說肯定是后者好账磺,因為實現(xiàn)接口的方式比繼承類的方式更靈活芹敌,也能減少程序之間的耦合度共屈,面向接口編程也是設計模式6大原則的核心。

3党窜、start()方法和run()方法的區(qū)別

只有調(diào)用了start()方法拗引,才會表現(xiàn)出多線程的特性,不同線程的run()方法里面的代碼交替執(zhí)行幌衣。如果只是調(diào)用run()方法矾削,那么代碼還是同步執(zhí)行的,必須等待一個線程的run()方法里面的代碼全部執(zhí)行完畢之后豁护,另外一個線程才可以執(zhí)行其run()方法里面的代碼哼凯。

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

有點深的問題了楚里,也看出一個Java程序員學習知識的廣度断部。

Runnable接口中的run()方法的返回值是void,它做的事情只是純粹地去執(zhí)行run()方法中的代碼而已班缎;Callable接口中的call()方法是有返回值的蝴光,是一個泛型,和Future达址、FutureTask配合可以用來獲取異步執(zhí)行的結果蔑祟。

這其實是很有用的一個特性,因為多線程相比單線程更難沉唠、更復雜的一個重要原因就是因為多線程充滿著未知性疆虚,某條線程是否執(zhí)行了?某條線程執(zhí)行了多久满葛?某條線程執(zhí)行的時候我們期望的數(shù)據(jù)是否已經(jīng)賦值完畢径簿?無法得知,我們能做的只是等待這條多線程的任務執(zhí)行完畢而已嘀韧。而Callable+Future/FutureTask卻可以獲取多線程運行的結果篇亭,可以在等待時間太長沒獲取到需要的數(shù)據(jù)的情況下取消該線程的任務,真的是非常有用乳蛾。

5暗赶、CyclicBarrier和CountDownLatch的區(qū)別

兩個看上去有點像的類,都在java.util.concurrent下肃叶,都可以用來表示代碼運行到某個點上蹂随,二者的區(qū)別在于:

(1)CyclicBarrier的某個線程運行到某個點上之后,該線程即停止運行因惭,直到所有的線程都到達了這個點岳锁,所有線程才重新運行;CountDownLatch則不是蹦魔,某線程運行到某個點上之后激率,只是給某個數(shù)值-1而已咳燕,該線程繼續(xù)運行

(2)CyclicBarrier只能喚起一個任務,CountDownLatch可以喚起多個任務

(3)CyclicBarrier可重用乒躺,CountDownLatch不可重用招盲,計數(shù)值為0該CountDownLatch就不可再用了

6、Volatile關鍵字的作用

一個非常重要的問題嘉冒,是每個學習曹货、應用多線程的Java程序員都必須掌握的。理解volatile關鍵字的作用的前提是要理解Java內(nèi)存模型讳推,這里就不講Java內(nèi)存模型了顶籽,可以參見第31點,volatile關鍵字的作用主要有兩個:

(1)多線程主要圍繞可見性和原子性兩個特性而展開银觅,使用volatile關鍵字修飾的變量礼饱,保證了其在多線程之間的可見性,即每次讀取到volatile變量究驴,一定是最新的數(shù)據(jù)

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

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

7芝雪、什么是線程安全

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

這個問題有值得一提的地方如筛,就是線程安全也是有幾個級別的:

(1)不可變

像String堡牡、Integer、Long這些杨刨,都是final類型的類晤柄,任何一個線程都改變不了它們的值,要改變除非新創(chuàng)建一個妖胀,因此這些不可變對象不需要任何同步手段就可以直接在多線程環(huán)境下使用

(2)絕對線程安全

不管運行時環(huán)境如何芥颈,調(diào)用者都不需要額外的同步措施惠勒。要做到這一點通常需要付出許多額外的代價,Java中標注自己是線程安全的類爬坑,實際上絕大多數(shù)都不是線程安全的纠屋,不過絕對線程安全的類,Java中也有盾计,比方說CopyOnWriteArrayList售担、CopyOnWriteArraySet

(3)相對線程安全

相對線程安全也就是我們通常意義上所說的線程安全,像Vector這種闯估,add灼舍、remove方法都是原子操作,不會被打斷涨薪,但也僅限于此骑素,如果有個線程在遍歷某個Vector、有個線程同時在add這個Vector刚夺,99%的情況下都會出現(xiàn)ConcurrentModificationException献丑,也就是fail-fast機制。

(4)線程非安全

這個就沒什么好說的了侠姑,ArrayList芯肤、LinkedList粪小、HashMap等都是線程非安全的類

8、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()方法也可以用于獲取線程堆棧泻红。這是一個實例方法谊路,因此此方法是和具體線程實例綁定的,每次獲取獲取到的是具體某個線程當前運行的堆棧惨恭,

9脱羡、一個線程如果出現(xiàn)了運行時異常會怎么樣

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

10态罪、如何在兩個線程之間共享數(shù)據(jù)

通過在線程之間共享對象就可以了,然后通過wait/notify/notifyAll沥割、await/signal/signalAll進行喚起和等待机杜,比方說阻塞隊列BlockingQueue就是為線程之間共享數(shù)據(jù)而設計的

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

這個問題常問蚀苛,sleep方法和wait方法都可以用來放棄CPU一定的時間腋舌,不同點在于如果線程持有某個對象的監(jiān)視器块饺,sleep方法不會放棄這個對象的監(jiān)視器,wait方法會放棄這個對象的監(jiān)視器

12淮腾、生產(chǎn)者消費者模型的作用是什么

這個問題很理論,但是很重要:

(1)通過平衡生產(chǎn)者的生產(chǎn)能力和消費者的消費能力來提升整個系統(tǒng)的運行效率徘禁,這是生產(chǎn)者消費者模型最重要的作用

(2)解耦,這是生產(chǎn)者消費者模型附帶的作用驶沼,解耦意味著生產(chǎn)者和消費者之間的聯(lián)系少回怜,聯(lián)系越少越可以獨自發(fā)展而不需要收到相互的制約

13、ThreadLocal有什么用

簡單說ThreadLocal就是一種以空間換時間的做法复旬,在每個Thread里面維護了一個以開地址法實現(xiàn)的ThreadLocal.ThreadLocalMap壁涎,把數(shù)據(jù)進行隔離,數(shù)據(jù)不共享庞溜,自然就沒有線程安全方面的問題了

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

這是JDK強制的漫试,wait()方法和notify()/notifyAll()方法在調(diào)用前都必須先獲得對象的鎖

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

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

16件炉、為什么要使用線程池

避免頻繁地創(chuàng)建和銷毀線程,達到線程對象的重用磕蛇。另外,使用線程池還可以根據(jù)項目靈活地控制并發(fā)的數(shù)目。

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

我也是在網(wǎng)上看到一道多線程面試題才知道有方法可以判斷某個線程是否持有對象監(jiān)視器:Thread類提供了一個holdsLock(Object obj)方法适肠,當且僅當對象obj的監(jiān)視器被某條線程持有的時候才會返回true敦跌,注意這是一個static方法柠傍,這意味著“某條線程”指的是當前線程。

18患整、synchronized和ReentrantLock的區(qū)別

synchronized是和if、else昌渤、for、while一樣的關鍵字履婉,ReentrantLock是類,這是二者的本質(zhì)區(qū)別已烤。既然ReentrantLock是類,那么它就提供了比synchronized更多更靈活的特性臣嚣,可以被繼承硅则、可以有方法、可以有各種各樣的類變量大审,ReentrantLock比synchronized的擴展性體現(xiàn)在幾點上:

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

(2)ReentrantLock可以獲取各種鎖的信息

(3)ReentrantLock可以靈活地實現(xiàn)多路通知

另外,二者的鎖機制其實也是不一樣的溶浴。ReentrantLock底層調(diào)用的是Unsafe的park方法加鎖,synchronized操作的應該是對象頭中mark word,這點我不能確定饥臂。

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

ConcurrentHashMap的并發(fā)度就是segment的大小,默認為16驰坊,這意味著最多同時可以有16條線程操作ConcurrentHashMap假勿,這也是ConcurrentHashMap對Hashtable的最大優(yōu)勢恶导,任何情況下邦泄,Hashtable能同時有兩條線程獲取Hashtable中的數(shù)據(jù)嗎顺囊?

20、ReadWriteLock是什么

首先明確一下,不是說ReentrantLock不好益愈,只是ReentrantLock某些時候有局限。如果使用ReentrantLock摸袁,可能本身是為了防止線程A在寫數(shù)據(jù)、線程B在讀數(shù)據(jù)造成的數(shù)據(jù)不一致,但這樣添谊,如果線程C在讀數(shù)據(jù)耳高、線程D也在讀數(shù)據(jù),讀數(shù)據(jù)是不會改變數(shù)據(jù)的,沒有必要加鎖修壕,但是還是加鎖了,降低了程序的性能。

因為這個壶冒,才誕生了讀寫鎖ReadWriteLock。ReadWriteLock是一個讀寫鎖接口,ReentrantReadWriteLock是ReadWriteLock接口的一個具體實現(xiàn)记罚,實現(xiàn)了讀寫的分離,讀鎖是共享的,寫鎖是獨占的刊驴,讀和讀之間不會互斥舅柜,讀和寫、寫和讀、寫和寫之間才會互斥,提升了讀寫的性能。

21芳悲、FutureTask是什么

這個其實前面有提到過,F(xiàn)utureTask表示一個異步運算的任務。FutureTask里面可以傳入一個Callable的具體實現(xiàn)類,可以對這個異步運算的任務的結果進行等待獲取拘领、判斷是否已經(jīng)完成笆凌、取消任務等操作样漆。當然鳍怨,由于FutureTask也是Runnable接口的實現(xiàn)類,所以FutureTask也可以放入線程池中。

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

這是一個比較偏實踐的問題蟆肆,這種問題我覺得挺有意義的枚冗。可以這么做:

(1)獲取項目的pid束世,jps或者ps -ef | grep java锈死,這個前面有講過

(2)top -H -p pid其屏,順序不能改變

這樣就可以打印出當前的項目,每條線程占用CPU時間的百分比熄云。注意這里打出的是LWP,也就是操作系統(tǒng)原生線程的線程號妙真,我筆記本山?jīng)]有部署Linux環(huán)境下的Java工程缴允,因此沒有辦法截圖演示,網(wǎng)友朋友們?nèi)绻臼鞘褂肔inux環(huán)境部署項目的話珍德,可以嘗試一下。

使用”top -H -p pid”+”jps pid”可以很容易地找到某條占用CPU高的線程的線程堆棧锈候,從而定位占用CPU高的原因薄料,一般是因為不當?shù)拇a操作導致了死循環(huán)。

最后提一點泵琳,”top -H -p pid”打出來的LWP是十進制的都办,”jps pid”打出來的本地線程號是十六進制的,轉(zhuǎn)換一下虑稼,就能定位到占用CPU高的線程的當前線程堆棧了。

23势木、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的對象鎖已經(jīng)被線程1鎖持有,線程2肯定是要等待線程1釋放lock1的對象鎖的

這樣,線程1″睡覺”睡完犀忱,線程2已經(jīng)獲取了lock2的對象鎖了募谎,線程1此時嘗試獲取lock2的對象鎖,便被阻塞峡碉,此時一個死鎖就形成了近哟。代碼就不寫了,占的篇幅有點多鲫寄,Java多線程7:死鎖這篇文章里面有吉执,就是上面步驟的代碼實現(xiàn)。

24地来、怎么喚醒一個阻塞的線程

如果線程是因為調(diào)用了wait()戳玫、sleep()或者join()方法而導致的阻塞,可以中斷線程未斑,并且通過拋出InterruptedException來喚醒它咕宿;如果線程遇到了IO阻塞,無能為力蜡秽,因為IO是操作系統(tǒng)實現(xiàn)的府阀,Java代碼并沒有辦法直接接觸到操作系統(tǒng)。

25芽突、不可變對象對多線程有什么幫助

前面有提到過的一個問題试浙,不可變對象保證了對象的內(nèi)存可見性,對不可變對象的讀取不需要進行額外的同步手段寞蚌,提升了代碼執(zhí)行效率田巴。

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

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

27壹哺、如果你提交任務時,線程池隊列已滿艘刚,這時會發(fā)生什么

如果你使用的LinkedBlockingQueue管宵,也就是無界隊列的話,沒關系攀甚,繼續(xù)添加任務到阻塞隊列中等待執(zhí)行啄糙,因為LinkedBlockingQueue可以近乎認為是一個無窮大的隊列,可以無限存放任務云稚;如果你使用的是有界隊列比方說ArrayBlockingQueue的話隧饼,任務首先會被添加到ArrayBlockingQueue中,ArrayBlockingQueue滿了静陈,則會使用拒絕策略RejectedExecutionHandler處理滿了的任務燕雁,默認是AbortPolicy诞丽。

28、Java中用到的線程調(diào)度算法是什么

搶占式拐格。一個線程用完CPU之后僧免,操作系統(tǒng)會根據(jù)線程優(yōu)先級、線程饑餓情況等數(shù)據(jù)算出一個總的優(yōu)先級并分配下一個時間片給某個線程執(zhí)行捏浊。

29懂衩、Thread.sleep(0)的作用是什么

這個問題和上面那個問題是相關的,我就連在一起了金踪。由于Java采用搶占式的線程調(diào)度算法浊洞,因此可能會出現(xiàn)某條線程常常獲取到CPU控制權的情況,為了讓某些優(yōu)先級比較低的線程也能獲取到CPU控制權胡岔,可以使用Thread.sleep(0)手動觸發(fā)一次操作系統(tǒng)分配時間片的操作法希,這也是平衡CPU控制權的一種操作。

30靶瘸、什么是自旋

很多synchronized里面的代碼只是一些很簡單的代碼苫亦,執(zhí)行時間非常快怨咪,此時等待的線程都加鎖可能是一種不太值得的操作屋剑,因為線程阻塞涉及到用戶態(tài)和內(nèi)核態(tài)切換的問題。既然synchronized里面的代碼執(zhí)行地非呈#快饼丘,不妨讓等待鎖的線程不要被阻塞,而是在synchronized的邊界做忙循環(huán)辽话,這就是自旋。如果做了多次忙循環(huán)發(fā)現(xiàn)還沒有獲得鎖卫病,再阻塞油啤,這樣可能是一種更好的策略。

31蟀苛、什么是Java內(nèi)存模型

Java內(nèi)存模型定義了一種多線程訪問Java內(nèi)存的規(guī)范益咬。Java內(nèi)存模型要完整講不是這里幾句話能說清楚的,我簡單總結一下Java內(nèi)存模型的幾部分內(nèi)容:

(1)Java內(nèi)存模型將內(nèi)存分為了主內(nèi)存和工作內(nèi)存帜平。類的狀態(tài)幽告,也就是類之間共享的變量,是存儲在主內(nèi)存中的裆甩,每次Java線程用到這些主內(nèi)存中的變量的時候冗锁,會讀一次主內(nèi)存中的變量,并讓這些內(nèi)存在自己的工作內(nèi)存中有一份拷貝嗤栓,運行自己線程代碼的時候冻河,用到這些變量箍邮,操作的都是自己工作內(nèi)存中的那一份。在線程代碼執(zhí)行完畢之后叨叙,會將最新的值更新到主內(nèi)存中去

(2)定義了幾個原子操作锭弊,用于操作主內(nèi)存和工作內(nèi)存中的變量

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

(4)happens-before,即先行發(fā)生原則擂错,定義了操作A必然先行發(fā)生于操作B的一些規(guī)則味滞,比如在同一個線程內(nèi)控制流前面的代碼一定先行發(fā)生于控制流后面的代碼、一個釋放鎖unlock的動作一定先行發(fā)生于后面對于同一個鎖進行鎖定lock的動作等等钮呀,只要符合這些規(guī)則剑鞍,則不需要額外做同步措施,如果某段代碼不符合所有的happens-before規(guī)則行楞,則這段代碼一定是線程非安全的

32攒暇、什么是CAS

CAS,全稱為Compare and Set子房,即比較-設置形用。假設有三個操作數(shù):內(nèi)存值V、舊的預期值A证杭、要修改的值B田度,當且僅當預期值A和內(nèi)存值V相同時,才會將內(nèi)存值修改為B并返回true解愤,否則什么都不做并返回false镇饺。當然CAS一定要volatile變量配合,這樣才能保證每次拿到的變量是主內(nèi)存中最新的那個值送讲,否則舊的預期值A對某條線程來說奸笤,永遠是一個不會變的值A,只要某次CAS操作失敗哼鬓,永遠都不可能成功监右。

33、什么是樂觀鎖和悲觀鎖

(1)樂觀鎖:就像它的名字一樣异希,對于并發(fā)間操作產(chǎn)生的線程安全問題持樂觀狀態(tài)健盒,樂觀鎖認為競爭不總是會發(fā)生,因此它不需要持有鎖称簿,將比較-設置這兩個動作作為一個原子操作嘗試去修改內(nèi)存中的變量扣癣,如果失敗則表示發(fā)生沖突,那么就應該有相應的重試邏輯憨降。

(2)悲觀鎖:還是像它的名字一樣父虑,對于并發(fā)間操作產(chǎn)生的線程安全問題持悲觀狀態(tài),悲觀鎖認為競爭總是會發(fā)生授药,因此每次對某資源進行操作時频轿,都會持有一個獨占的鎖垂涯,就像synchronized,不管三七二十一航邢,直接上了鎖就操作資源了耕赘。

34、什么是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ā)者可以根據(jù)自己的實現(xiàn)重寫tryLock和tryRelease方法昨忆,以實現(xiàn)自己的并發(fā)功能丁频。

35、單例模式的線程安全性

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

(1)餓漢式單例模式的寫法:線程安全

(2)懶漢式單例模式的寫法:非線程安全

(3)雙檢鎖單例模式的寫法:線程安全

36拢驾、Semaphore有什么作用

Semaphore就是一個信號量奖磁,它的作用是限制某段代碼塊的并發(fā)數(shù)。Semaphore有一個構造函數(shù)独旷,可以傳入一個int型整數(shù)n,表示某段代碼最多只有n個線程可以訪問寥裂,如果超出了n嵌洼,那么請等待,等到某個線程執(zhí)行完畢這段代碼塊封恰,下一個線程再進入麻养。由此可以看出如果Semaphore構造函數(shù)中傳入的int型整數(shù)n=1,相當于變成了一個synchronized了诺舔。

37鳖昌、Hashtable的size()方法中明明只有一條語句”return count”备畦,為什么還要做同步?

這是我之前的一個困惑许昨,不知道大家有沒有想過這個問題懂盐。某個方法中如果有多條語句,并且都在操作同一個類變量糕档,那么在多線程環(huán)境下不加鎖莉恼,勢必會引發(fā)線程安全問題,這很好理解速那,但是size()方法明明只有一條語句俐银,為什么還要加鎖?

關于這個問題端仰,在慢慢地工作捶惜、學習中,有了理解荔烧,主要原因有兩點:

(1)同一時間只能有一條線程執(zhí)行固定類的同步方法吱七,但是對于類的非同步方法,可以多條線程同時訪問茴晋。所以陪捷,這樣就有問題了,可能線程A在執(zhí)行Hashtable的put方法添加數(shù)據(jù)诺擅,線程B則可以正常調(diào)用size()方法讀取Hashtable中當前元素的個數(shù)市袖,那讀取到的值可能不是最新的,可能線程A添加了完了數(shù)據(jù)烁涌,但是沒有對size++苍碟,線程B就已經(jīng)讀取size了,那么對于線程B來說讀取到的size一定是不準確的撮执。而給size()方法加了同步之后微峰,意味著線程B調(diào)用size()方法只有在線程A調(diào)用put方法完畢之后才可以調(diào)用,這樣就保證了線程安全性

(2)CPU執(zhí)行代碼抒钱,執(zhí)行的不是Java代碼蜓肆,這點很關鍵,一定得記住谋币。Java代碼最終是被翻譯成匯編代碼執(zhí)行的仗扬,匯編代碼才是真正可以和硬件電路交互的代碼。即使你看到Java代碼只有一行蕾额,甚至你看到Java代碼編譯之后生成的字節(jié)碼也只有一行早芭,也不意味著對于底層來說這句語句的操作只有一個。一句”return count”假設被翻譯成了三句匯編語句執(zhí)行诅蝶,完全可能執(zhí)行完第一句退个,線程就切換了募壕。

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

這是一個非常刁鉆和狡猾的問題舱馅。請記住:線程類的構造方法黎烈、靜態(tài)塊是被new這個線程類所在的線程所調(diào)用的习柠,而run方法里面的代碼才是被線程自身所調(diào)用的。

如果說上面的說法讓你感到困惑照棋,那么我舉個例子资溃,假設Thread2中new了Thread1,main函數(shù)中new了Thread2烈炭,那么:

(1)Thread2的構造方法溶锭、靜態(tài)塊是main線程調(diào)用的,Thread2的run()方法是Thread2自己調(diào)用的

(2)Thread1的構造方法符隙、靜態(tài)塊是Thread2調(diào)用的趴捅,Thread1的run()方法是Thread1自己調(diào)用的

39、同步方法和同步塊霹疫,哪個是更好的選擇

同步塊拱绑,這意味著同步塊之外的代碼是異步執(zhí)行的,這比同步整個方法更提升代碼的效率丽蝎。請知道一條原則:同步的范圍越少越好猎拨。

借著這一條,我額外提一點屠阻,雖說同步的范圍越少越好红省,但是在Java虛擬機中還是存在著一種叫做鎖粗化的優(yōu)化方法,這種方法就是把同步范圍變大国觉。這是有用的吧恃,比方說StringBuffer,它是一個線程安全的類麻诀,自然最常用的append()方法是一個同步方法痕寓,我們寫代碼的時候會反復append字符串,這意味著要進行反復的加鎖->解鎖蝇闭,這對性能不利呻率,因為這意味著Java虛擬機在這條線程上要反復地在內(nèi)核態(tài)和用戶態(tài)之間進行切換,因此Java虛擬機會將多次append方法調(diào)用的代碼進行一個鎖粗化的操作丁眼,將多次的append的操作擴展到append方法的頭尾筷凤,變成一個大的同步塊昭殉,這樣就減少了加鎖–>解鎖的次數(shù)苞七,有效地提升了代碼執(zhí)行的效率藐守。

40、高并發(fā)蹂风、任務執(zhí)行時間短的業(yè)務怎樣使用線程池卢厂?并發(fā)不高、任務執(zhí)行時間長的業(yè)務怎樣使用線程池惠啄?并發(fā)高慎恒、業(yè)務執(zhí)行時間長的業(yè)務怎樣使用線程池?

這是我在并發(fā)編程網(wǎng)上看到的一個問題撵渡,把這個問題放在最后一個融柬,希望每個人都能看到并且思考一下,因為這個問題非常好趋距、非常實際粒氧、非常專業(yè)。關于這個問題节腐,個人看法是:

(1)高并發(fā)外盯、任務執(zhí)行時間短的業(yè)務,線程池線程數(shù)可以設置為CPU核數(shù)+1翼雀,減少線程上下文的切換

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

a)假如是業(yè)務時間長集中在IO操作上,也就是IO密集型的任務狼渊,因為IO操作并不占用CPU箱熬,所以不要讓所有的CPU閑下來,可以加大線程池中的線程數(shù)目囤锉,讓CPU處理更多的業(yè)務

b)假如是業(yè)務時間長集中在計算操作上坦弟,也就是計算密集型任務,這個就沒辦法了官地,和(1)一樣吧酿傍,線程池中的線程數(shù)設置得少一些,減少線程上下文的切換

(3)并發(fā)高驱入、業(yè)務執(zhí)行時間長赤炒,解決這種類型任務的關鍵不在于線程池而在于整體架構的設計,看看這些業(yè)務里面某些數(shù)據(jù)是否能做緩存是第一步亏较,增加服務器是第二步莺褒,至于線程池的設置,設置參考(2)雪情。最后遵岩,業(yè)務執(zhí)行時間長的問題,也可能需要分析一下,看看能不能使用中間件對任務進行拆分和解耦尘执。

Java高架構師舍哄、分布式架構、高可擴展誊锭、高性能表悬、高并發(fā)、性能優(yōu)化丧靡、Spring boot蟆沫、Redis、ActiveMQ温治、Nginx饭庞、Mycat、Netty熬荆、Jvm大型分布式項目實戰(zhàn)學習架構師視頻免費獲取架構群:854180697

群鏈接:地址

寫在最后:歡迎留言討論但绕,加關注,持續(xù)更新;炭础D笏场!

最后編輯于
?著作權歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末纬黎,一起剝皮案震驚了整個濱河市幅骄,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌本今,老刑警劉巖拆座,帶你破解...
    沈念sama閱讀 217,734評論 6 505
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異冠息,居然都是意外死亡挪凑,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,931評論 3 394
  • 文/潘曉璐 我一進店門逛艰,熙熙樓的掌柜王于貴愁眉苦臉地迎上來躏碳,“玉大人,你說我怎么就攤上這事散怖」矫啵” “怎么了?”我有些...
    開封第一講書人閱讀 164,133評論 0 354
  • 文/不壞的土叔 我叫張陵镇眷,是天一觀的道長咬最。 經(jīng)常有香客問我,道長欠动,這世上最難降的妖魔是什么永乌? 我笑而不...
    開封第一講書人閱讀 58,532評論 1 293
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上翅雏,老公的妹妹穿的比我還像新娘硝桩。我一直安慰自己,他們只是感情好枚荣,可當我...
    茶點故事閱讀 67,585評論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著啼肩,像睡著了一般橄妆。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上祈坠,一...
    開封第一講書人閱讀 51,462評論 1 302
  • 那天害碾,我揣著相機與錄音,去河邊找鬼赦拘。 笑死慌随,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的躺同。 我是一名探鬼主播阁猜,決...
    沈念sama閱讀 40,262評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼蹋艺!你這毒婦竟也來了剃袍?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,153評論 0 276
  • 序言:老撾萬榮一對情侶失蹤捎谨,失蹤者是張志新(化名)和其女友劉穎民效,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體涛救,經(jīng)...
    沈念sama閱讀 45,587評論 1 314
  • 正文 獨居荒郊野嶺守林人離奇死亡畏邢,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,792評論 3 336
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了检吆。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片舒萎。...
    茶點故事閱讀 39,919評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖蹭沛,靈堂內(nèi)的尸體忽然破棺而出逆甜,到底是詐尸還是另有隱情,我是刑警寧澤致板,帶...
    沈念sama閱讀 35,635評論 5 345
  • 正文 年R本政府宣布交煞,位于F島的核電站,受9級特大地震影響斟或,放射性物質(zhì)發(fā)生泄漏素征。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,237評論 3 329
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望御毅。 院中可真熱鬧根欧,春花似錦、人聲如沸端蛆。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,855評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽今豆。三九已至嫌拣,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間呆躲,已是汗流浹背异逐。 一陣腳步聲響...
    開封第一講書人閱讀 32,983評論 1 269
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留插掂,地道東北人灰瞻。 一個月前我還...
    沈念sama閱讀 48,048評論 3 370
  • 正文 我出身青樓,卻偏偏與公主長得像辅甥,于是被迫代替她去往敵國和親酝润。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 44,864評論 2 354

推薦閱讀更多精彩內(nèi)容