40個(gè)java多線程問題總結(jié)-java開發(fā)java經(jīng)驗(yàn)技巧

《40個(gè)java多線程問題總結(jié)-java開發(fā)java經(jīng)驗(yàn)技巧》由會員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在工程資料-天天文庫。

1、40個(gè)Java多線程問題總結(jié)-編程開發(fā)技術(shù)40個(gè)Java多線程問題總結(jié)原文出處：五刀的倉頡Java多線程分類中寫了21篇多線程的文章，21篇文章的內(nèi)容很多，個(gè)人認(rèn)為，學(xué)習(xí)，內(nèi)容越多、越雜的知識，越需要進(jìn)行深刻的總結(jié)，這樣才能記憶深刻，將知識變成自己的。這篇文章主耍是對多線程的問題進(jìn)行總結(jié)的，因此羅列了40個(gè)多線程的問題。這些多線程的問題，有些來源于各大網(wǎng)站、有些來源于門己的思考?？赡苡行﹩栴}網(wǎng)上冇、可能有些問題對應(yīng)的答案也有、也可能冇些各位網(wǎng)友也都看過，但是本文寫作的重心就是所有的問題都會按照自己的理解回答一遍，不會去看網(wǎng)上的答案，因此可能有些問題講的不對，能指正的希望大家不吝指教。4

2、0個(gè)問題匯總1、多線程有什么用?一個(gè)可能在很多人看來很扯淡的一個(gè)問題：我會用多線程就好了，還管它有什么用？在我看來，這個(gè)回答更扯淡。所謂”知其然知其所以然”，”會用”只是”知其然”，”為什么用”才是”知其所以然”，只有達(dá)到”知其然知其所以然”的程度才可以說是把一個(gè)知識點(diǎn)運(yùn)用自如。0K,下而說說我對這個(gè)問題的看法：(1)發(fā)揮多核CPU的優(yōu)勢隨著工業(yè)的進(jìn)步，現(xiàn)在的筆記木、臺式機(jī)乃至商用的應(yīng)用服務(wù)器至少也都是雙核的，4核、8核甚至16核的也都不少見，如果是單線程的程序，那么在雙核CPU上就浪費(fèi)了50%,在4核CPU上就浪費(fèi)了75%o單核CPU上所謂的”多線程”那是假的多線程，同一時(shí)間處理器只

3、會處理一段邏輯，只不過線程之間切換得比較快，看著像多個(gè)線程”同時(shí)”運(yùn)行罷了。多核CPU上的多線程才是真止的多線程，它能訃你的多段邏輯同時(shí)工作，多線程，可以真正發(fā)揮出多核CPU的優(yōu)勢來,達(dá)到充分利用CPU的目的。(2)防止阻塞從程序運(yùn)行效率的角度來看，單核CPU不但不會發(fā)揮出多線程的優(yōu)勢，反而會因?yàn)樵趩魏薈PU上運(yùn)行多線程導(dǎo)致線程上下文的切換，而降低程序整休的效率。但是單核CPU我們述是要應(yīng)用多線程，就是為了防止阻塞。試想，如果單核CPU使用單線程，那么只要這個(gè)線程阻塞了，比方說遠(yuǎn)程讀取某個(gè)數(shù)據(jù)吧，對端遲遲未返回又沒有設(shè)置超吋吋間，那么你的整個(gè)程序在數(shù)據(jù)返冋冋來之前就停止運(yùn)行To多線程可

4、以防止這個(gè)問題，多條線程同時(shí)運(yùn)行，哪怕一?條線程的代碼執(zhí)行讀取數(shù)據(jù)阻塞，也不會影響其它任務(wù)的執(zhí)行。(3)便于建模這是另外一個(gè)沒有這么明顯的優(yōu)點(diǎn)了。假設(shè)有一個(gè)大的任務(wù)A,單線程編程，那么就要考慮很多，建立整個(gè)程序模型比較麻煩。但是如果把這個(gè)大的任務(wù)A分解成幾個(gè)小任務(wù)，任務(wù)B、任務(wù)C、任務(wù)D,分別建立程序模型，并通過多線程分別運(yùn)行這幾個(gè)任務(wù)，那就簡單很多了。2、創(chuàng)建線程的方式比較常見的一個(gè)問題了，一般就是兩種：(1)繼承Thread類(2)實(shí)現(xiàn)Runnable接口至于哪個(gè)好,不用說肯定是后者好，因?yàn)閷?shí)現(xiàn)接口的方式比繼承類的方式更靈活,也能減少程序之間的耦合度，面向接口編程也是設(shè)計(jì)模式6大原

5、則的核心。3、start()方法和run()方法的區(qū)別只有調(diào)用了start()方法，才會表現(xiàn)出多線程的特性，不同線程的nm()方法里面的代碼交替執(zhí)行。如果只是調(diào)用run()方法，那么代碼還是同步執(zhí)行的，必須等待一個(gè)線程的run()方法里而的代碼全部執(zhí)行完畢之后，另外一個(gè)線程才可以執(zhí)行其rim()方法里面的代碼。4、Runnab1e接口和Callable接口的區(qū)別有點(diǎn)深的問題了，也看出一個(gè)匕陽程序員學(xué)習(xí)知識的廣度。Runnable接口屮的run()方法的返回值是void,它做的事情只是純粹地去執(zhí)行run()方法中的代碼而已；Callable接口中的call()方法是有返冋值的，是一個(gè)泛型

6、，和Future>FutureTask配合可以用來獲取異步執(zhí)行的結(jié)果。這其實(shí)是很有用的一個(gè)特性，因?yàn)槎嗑€程相比單線程更難、更復(fù)雜的一個(gè)重要原因就是因?yàn)槎嗑€程充滿著未知性，某條線程是否執(zhí)行了？某條線程執(zhí)行了多久？某條線程執(zhí)行的時(shí)候我們期槊的數(shù)據(jù)是否已經(jīng)賦值完畢？無法得知，我們能做的只是等待這條多線程的任務(wù)執(zhí)行完畢而已。而Callable+Future/FutureTask卻可以獲取多線程運(yùn)行的結(jié)果，可以在等待時(shí)間太長沒獲取到需要的數(shù)據(jù)的情況下取消該線程的任務(wù)，真的是非常有用。5、CyclicBarrier和CountDownLatch的區(qū)別兩個(gè)看上去有點(diǎn)像的類，都在java.util,c

7、oncurrent下，都口J以用來表示代碼運(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口J以喚起多個(gè)任務(wù)(3)CyclicBarrier可重用,Coun