關(guān)于多線程的問(wèn)題及答案一

關(guān)于多線程的問(wèn)題及答案


這些多線程的問(wèn)題,有些來(lái)源于各大網(wǎng)站、有些來(lái)源于自己的思考??赡苡行﹩?wèn)題網(wǎng)上有、可能有些問(wèn)題對(duì)應(yīng)的答案也有、也可能有些各位網(wǎng)友也都看過(guò),但是本文寫作的重心就是所有的問(wèn)題都會(huì)按照自己的理解回答一遍,不會(huì)去看網(wǎng)上的答案,因此可能有些問(wèn)題講的不對(duì),能指正的希望大家不吝指教。

1、多線程有什么用?

一個(gè)可能在很多人看來(lái)很扯淡的一個(gè)問(wèn)題:我會(huì)用多線程就好了,還管它有什么用?在我看來(lái),這個(gè)回答更扯淡。所謂"知其然知其所以然","會(huì)用"只是"知其然","為什么用"才是"知其所以然",只有達(dá)到"知其然知其所以然"的程度才可以說(shuō)是把一個(gè)知識(shí)點(diǎn)運(yùn)用自如。OK,下面說(shuō)說(shuō)我對(duì)這個(gè)問(wèn)題的看法:

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

隨著工業(yè)的進(jìn)步,現(xiàn)在的筆記本、臺(tái)式機(jī)乃至商用的應(yīng)用服務(wù)器至少也都是雙核的,4核、8核甚至16核的也都不少見,如果是單線程的程序,那么在雙核CPU上就浪費(fèi)了50%,在4核CPU上就浪費(fèi)了75%。單核CPU上所謂的"多線程"那是假的多線程,同一時(shí)間處理器只會(huì)處理一段邏輯,只不過(guò)線程之間切換得比較快,看著像多個(gè)線程"同時(shí)"運(yùn)行罷了。多核CPU上的多線程才是真正的多線程,它能讓你的多段邏輯同時(shí)工作,多線程,可以真正發(fā)揮出多核CPU的優(yōu)勢(shì)來(lái),達(dá)到充分利用CPU的目的。

2)防止阻塞

從程序運(yùn)行效率的角度來(lái)看,單核CPU不但不會(huì)發(fā)揮出多線程的優(yōu)勢(shì),反而會(huì)因?yàn)樵趩魏薈PU上運(yùn)行多線程導(dǎo)致線程上下文的切換,而降低程序整體的效率。但是單核CPU我們還是要應(yīng)用多線程,就是為了防止阻塞。試想,如果單核CPU使用單線程,那么只要這個(gè)線程阻塞了,比方說(shuō)遠(yuǎn)程讀取某個(gè)數(shù)據(jù)吧,對(duì)端遲遲未返回又沒有設(shè)置超時(shí)時(shí)間,那么你的整個(gè)程序在數(shù)據(jù)返回回來(lái)之前就停止運(yùn)行了。多線程可以防止這個(gè)問(wèn)題,多條線程同時(shí)運(yùn)行,哪怕一條線程的代碼執(zhí)行讀取數(shù)據(jù)阻塞,也不會(huì)影響其它任務(wù)的執(zhí)行。

3)便于建模

這是另外一個(gè)沒有這么明顯的優(yōu)點(diǎn)了。假設(shè)有一個(gè)大的任務(wù)A,單線程編程,那么就要考慮很多,建立整個(gè)程序模型比較麻煩。但是如果把這個(gè)大的任務(wù)A分解成幾個(gè)小任務(wù),任務(wù)B、任務(wù)C、任務(wù)D,分別建立程序模型,并通過(guò)多線程分別運(yùn)行這幾個(gè)任務(wù),那就簡(jiǎn)單很多了。

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

比較常見的一個(gè)問(wèn)題了,一般就是兩種:

1)繼承Thread類

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

至于哪個(gè)好,不用說(shuō)肯定是后者好,因?yàn)閷?shí)現(xiàn)接口的方式比繼承類的方式更靈活,也能減少程序之間的耦合度,面向接口編程也是設(shè)計(jì)模式6大原則的核心。

其實(shí)還有第3種,點(diǎn)擊了解更多。

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

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

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

有點(diǎn)深的問(wèn)題了,也看出一個(gè)Java程序員學(xué)習(xí)知識(shí)的廣度。

Runnable接口中的run()方法的返回值是void,它做的事情只是純粹地去執(zhí)行run()方法中的代碼而已;Callable接口中的call()方法是有返回值的,是一個(gè)泛型,和Future、FutureTask配合可以用來(lái)獲取異步執(zhí)行的結(jié)果。

這其實(shí)是很有用的一個(gè)特性,因?yàn)?b>多線程相比單線程更難、更復(fù)雜的一個(gè)重要原因就是因?yàn)槎嗑€程充滿著未知性,某條線程是否執(zhí)行了?某條線程執(zhí)行了多久?某條線程執(zhí)行的時(shí)候我們期望的數(shù)據(jù)是否已經(jīng)賦值完畢?無(wú)法得知,我們能做的只是等待這條多線程的任務(wù)執(zhí)行完畢而已。而Callable+Future/FutureTask卻可以獲取多線程運(yùn)行的結(jié)果,可以在等待時(shí)間太長(zhǎng)沒獲取到需要的數(shù)據(jù)的情況下取消該線程的任務(wù),真的是非常有用。

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

兩個(gè)看上去有點(diǎn)像的類,都在java.util.concurrent下,都可以用來(lái)表示代碼運(yùn)行到某個(gè)點(diǎn)上,二者的區(qū)別在于:

1)CyclicBarrier的某個(gè)線程運(yùn)行到某個(gè)點(diǎn)上之后,該線程即停止運(yùn)行,直到所有的線程都到達(dá)了這個(gè)點(diǎn),所有線程才重新運(yùn)行;CountDownLatch則不是,某線程運(yùn)行到某個(gè)點(diǎn)上之后,只是給某個(gè)數(shù)值-1而已,該線程繼續(xù)運(yùn)行。

2)CyclicBarrier只能喚起一個(gè)任務(wù),CountDownLatch可以喚起多個(gè)任務(wù)。

3) CyclicBarrier可重用,CountDownLatch不可重用,計(jì)數(shù)值為0該CountDownLatch就不可再用了。

6、volatile關(guān)鍵字的作用

一個(gè)非常重要的問(wèn)題,是每個(gè)學(xué)習(xí)、應(yīng)用多線程的Java程序員都必須掌握的。理解volatile關(guān)鍵字的作用的前提是要理解Java內(nèi)存模型,這里就不講Java內(nèi)存模型了,可以參見第31點(diǎn),volatile關(guān)鍵字的作用主要有兩個(gè):

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

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

從實(shí)踐角度而言,volatile的一個(gè)重要作用就是和CAS結(jié)合,保證了原子性,詳細(xì)的可以參見java.util.concurrent.atomic包下的類,比如AtomicInteger,更多詳情請(qǐng)點(diǎn)擊進(jìn)行學(xué)習(xí)。

7、什么是線程安全

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

這個(gè)問(wèn)題有值得一提的地方,就是線程安全也是有幾個(gè)級(jí)別的:

1)不可變

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

2)絕對(duì)線程安全

不管運(yùn)行時(shí)環(huán)境如何,調(diào)用者都不需要額外的同步措施。要做到這一點(diǎn)通常需要付出許多額外的代價(jià),Java中標(biāo)注自己是線程安全的類,實(shí)際上絕大多數(shù)都不是線程安全的,不過(guò)絕對(duì)線程安全的類,Java中也有,比方說(shuō)CopyOnWriteArrayList、CopyOnWriteArraySet

3)相對(duì)線程安全

相對(duì)線程安全也就是我們通常意義上所說(shuō)的線程安全,像Vector這種,add、remove方法都是原子操作,不會(huì)被打斷,但也僅限于此,如果有個(gè)線程在遍歷某個(gè)Vector、有個(gè)線程同時(shí)在add這個(gè)Vector,99%的情況下都會(huì)出現(xiàn)ConcurrentModificationException,也就是fail-fast機(jī)制

4)線程非安全

這個(gè)就沒什么好說(shuō)的了,ArrayList、LinkedList、HashMap等都是線程非安全的類,點(diǎn)擊了解為什么不安全。

所謂技多不壓身,我們所讀過(guò)的每一本書,所學(xué)過(guò)的每一門語(yǔ)言,在未來(lái)指不定都能給我們意想不到的回饋呢。其實(shí)做為一個(gè)開發(fā)者,有一個(gè)學(xué)習(xí)的氛圍跟一個(gè)交流圈子特別重要這里我推薦一個(gè)Java學(xué)習(xí)交流群342016322,不管你是小白還是大牛歡迎入駐,大家一起交流成長(zhǎng)

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 前言 個(gè)人認(rèn)為,學(xué)習(xí),內(nèi)容越多、越雜的知識(shí),越需要進(jìn)行深刻的總結(jié),這樣才能記憶深刻,將知識(shí)變成自己的。這篇文章主要...
    堯淳閱讀 741評(píng)論 0 17
  • 前言 Java多線程分類中寫了21篇多線程的文章,21篇文章的內(nèi)容很多,個(gè)人認(rèn)為,學(xué)習(xí),內(nèi)容越多、越雜的知識(shí),越需...
    jackcooper閱讀 696評(píng)論 1 16
  • 前言 個(gè)人認(rèn)為,學(xué)習(xí),內(nèi)容越多、越雜的知識(shí),越需要進(jìn)行深刻的總結(jié),這樣才能記憶深刻,將知識(shí)變成自己的。這篇文章主要...
    touch_The_Sky閱讀 438評(píng)論 0 2
  • 前言 這篇文章主要是對(duì)多線程的問(wèn)題進(jìn)行總結(jié)的,因此羅列了40個(gè)多線程的問(wèn)題。 這些多線程的問(wèn)題,有些來(lái)源于各大網(wǎng)站...
    java成功之路閱讀 861評(píng)論 0 9
  • 一個(gè)布袋子 掛在墻上 有一天 它有了好看的蝴蝶結(jié) 雖然只能擁有一瞬間 但是它很開心了 喏,我有蝴蝶結(jié)咯 布袋子說(shuō) ...
    有思想的大烏龜閱讀 128評(píng)論 0 0

友情鏈接更多精彩內(nèi)容