java多線程有哪些實(shí)際的應(yīng)用場景？

多線程使用的主要目的在于：

1、吞吐量：你做WEB，容器幫你做了多線程，但是他只能幫你做請(qǐng)求層面的。簡單的說，可能就是一個(gè)請(qǐng)求一個(gè)線程。或多個(gè)請(qǐng)求一個(gè)線程。如果是單線程，那同時(shí)只能處理一個(gè)用戶的請(qǐng)求。

2、伸縮性：也就是說，你可以通過增加CPU核數(shù)來提升性能。如果是單線程，那程序執(zhí)行到死也就利用了單核，肯定沒辦法通過增加CPU核數(shù)來提升性能。鑒于你是做WEB的，第1點(diǎn)可能你幾乎不涉及。那這里我就講第二點(diǎn)吧。

--舉個(gè)簡單的例子：假設(shè)有個(gè)請(qǐng)求，這個(gè)請(qǐng)求服務(wù)端的處理需要執(zhí)行3個(gè)很緩慢的IO操作（比如數(shù)據(jù)庫查詢或文件查詢），那么正常的順序可能是（括號(hào)里面代表執(zhí)行時(shí)間）：

a、讀取文件1 （10ms）

b、處理1的數(shù)據(jù)（1ms）

c、讀取文件2 （10ms）

d、處理2的數(shù)據(jù)（1ms）

e、讀取文件3 （10ms）

f、處理3的數(shù)據(jù)（1ms）

g、整合1、2、3的數(shù)據(jù)結(jié)果 （1ms）

單線程總共就需要34ms。

那如果你在這個(gè)請(qǐng)求內(nèi)，把a(bǔ)b、cd、ef分別分給3個(gè)線程去做，就只需要12ms了。

所以多線程不是沒怎么用，而是，你平常要善于發(fā)現(xiàn)一些可優(yōu)化的點(diǎn)。然后評(píng)估方案是否應(yīng)該使用。假設(shè)還是上面那個(gè)相同的問題：但是每個(gè)步驟的執(zhí)行時(shí)間不一樣了。

a、讀取文件1 （1ms）

b、處理1的數(shù)據(jù)（1ms）

c、讀取文件2 （1ms）

d、處理2的數(shù)據(jù)（1ms）

e、讀取文件3 （28ms）

f、處理3的數(shù)據(jù)（1ms）

g、整合1、2、3的數(shù)據(jù)結(jié)果 （1ms）單線程總共就需要34ms。

如果還是按上面的劃分方案（上面方案和木桶原理一樣，耗時(shí)取決于最慢的那個(gè)線程的執(zhí)行速度），在這個(gè)例子中是第三個(gè)線程，執(zhí)行29ms。那么最后這個(gè)請(qǐng)求耗時(shí)是30ms。比起不用單線程，就節(jié)省了4ms。但是有可能線程調(diào)度切換也要花費(fèi)個(gè)1、2ms。

因此，這個(gè)方案顯得優(yōu)勢就不明顯了，還帶來程序復(fù)雜度提升。不太值得。那么現(xiàn)在優(yōu)化的點(diǎn)，就不是第一個(gè)例子那樣的任務(wù)分割多線程完成。而是優(yōu)化文件3的讀取速度。可能是采用緩存和減少一些重復(fù)讀取。首先，假設(shè)有一種情況，所有用戶都請(qǐng)求這個(gè)請(qǐng)求，那其實(shí)相當(dāng)于所有用戶都需要讀取文件3。

那你想想，100個(gè)人進(jìn)行了這個(gè)請(qǐng)求，相當(dāng)于你花在讀取這個(gè)文件上的時(shí)間就是28×100=2800ms了。那么，如果你把文件緩存起來，那只要第一個(gè)用戶的請(qǐng)求讀取了，第二個(gè)用戶不需要讀取了，從內(nèi)存取是很快速的，可能1ms都不到。

看起來好像還不錯(cuò)，建立一個(gè)文件名和文件數(shù)據(jù)的映射。如果讀取一個(gè)map中已經(jīng)存在的數(shù)據(jù)，那么就不不用讀取文件了。可是問題在于，Servlet是并發(fā)，上面會(huì)導(dǎo)致一個(gè)很嚴(yán)重的問題，死循環(huán)。因?yàn)椋琀ashMap在并發(fā)修改的時(shí)候，可能是導(dǎo)致循環(huán)鏈表的構(gòu)成！！！（具體你可以自行閱讀HashMap源碼）如果你沒接觸過多線程，可能到時(shí)候發(fā)現(xiàn)服務(wù)器沒請(qǐng)求也巨卡，也不知道什么情況！好的，那就用ConcurrentHashMap，正如他的名字一樣，他是一個(gè)線程安全的HashMap，這樣能輕松解決問題。

這樣真的解決問題了嗎，這樣雖然只要有用戶訪問過文件a，那另一個(gè)用戶想訪問文件a，也會(huì)從fileName2Data中拿數(shù)據(jù)，然后也不會(huì)引起死循環(huán)。可是，如果你覺得這樣就已經(jīng)完了，那你把多線程也想的太簡單了，騷年！你會(huì)發(fā)現(xiàn)，1000個(gè)用戶首次訪問同一個(gè)文件的時(shí)候，居然讀取了1000次文件（這是最極端的，可能只有幾百）。What the fuckin hell!!!難道代碼錯(cuò)了嗎，難道我就這樣過我的一生！好好分析下。Servlet是多線程的，那么上面注釋的“偶然”，這是完全有可能的，因此，這樣做還是有問題。因此，可以自己簡單的封裝一個(gè)任務(wù)來處理。

以上所有代碼都是直接在bbs打出來的，不保證可以直接運(yùn)行。

多線程最多的場景：web服務(wù)器本身；各種專用服務(wù)器（如游戲服務(wù)器）；多線程的常見應(yīng)用場景：

1、后臺(tái)任務(wù)，例如：定時(shí)向大量（100w以上）的用戶發(fā)送郵件；

2、異步處理，例如：發(fā)微博、記錄日志等；

3、分布式計(jì)算

在java中，每一個(gè)線程有一塊工作內(nèi)存區(qū)，其中存放著被所有線程共享的主內(nèi)存中的變量的值的拷貝。當(dāng)線程執(zhí)行時(shí)，它在自己的工作內(nèi)存中操作這些變量。

為了存取一個(gè)共享的變量，一個(gè)線程通常先獲取鎖定并且清除它的工作內(nèi)存區(qū)，這保證該共享變量從所有線程的共享內(nèi)存區(qū)正確地裝入到線程的工作內(nèi)存區(qū)，當(dāng)線程解鎖時(shí)保證該工作內(nèi)存區(qū)中變量的值協(xié)會(huì)到共享內(nèi)存中。

當(dāng)一個(gè)線程使用某一個(gè)變量時(shí)，不論程序是否正確地使用線程同步操作，它獲取的值一定是由它本身或者其他線程存儲(chǔ)到變量中的值。例如，如果兩個(gè)線程把不同的值或者對(duì)象引用存儲(chǔ)到同一個(gè)共享變量中，那么該變量的值要么是這個(gè)線程的，要么是那個(gè)線程的，共享變量的值不會(huì)是由兩個(gè)線程的引用值組合而成。

一個(gè)變量時(shí)Java程序可以存取的一個(gè)地址，它不僅包括基本類型變量、引用類型變量，而且還包括數(shù)組類型變量。保存在主內(nèi)存區(qū)的變量可以被所有線程共享，但是一個(gè)線程存取另一個(gè)線程的參數(shù)或者局部變量時(shí)不可能的，所以開發(fā)人員不必?fù)?dān)心局部變量的線程安全問題。

由于每個(gè)線程都有自己的工作內(nèi)存區(qū)，因此當(dāng)一個(gè)線程改變自己的工作內(nèi)存中的數(shù)據(jù)時(shí)，對(duì)其他線程來說，可能是不可見的。為此，可以使用volatile關(guān)鍵字破事所有線程軍讀寫內(nèi)存中的變量，從而使得volatile變量在多線程間可見。

聲明為volatile的變量可以做到如下保證：

1、其他線程對(duì)變量的修改，可以及時(shí)反應(yīng)在當(dāng)前線程中；2、確保當(dāng)前線程對(duì)volatile變量的修改，能及時(shí)寫回到共享內(nèi)存中，并被其他線程所見；3、使用volatile聲明的變量，編譯器會(huì)保證其有序性。

同步關(guān)鍵字synchronized

同步關(guān)鍵字synchronized是Java語言中最為常用的同步方法之一。在JDK早期版本中，synchronized的性能并不是太好，值適合于鎖競爭不是特別激烈的場合。在JDK6中，synchronized和非公平鎖的差距已經(jīng)縮小。更為重要的是，synchronized更為簡潔明了，代碼可讀性和維護(hù)性比較好。

鎖定一個(gè)對(duì)象的方法：

當(dāng)method()方法被調(diào)用時(shí)，調(diào)用線程首先必須獲得當(dāng)前對(duì)象所，若當(dāng)前對(duì)象鎖被其他線程持有，這調(diào)用線程會(huì)等待，犯法結(jié)束后，對(duì)象鎖會(huì)被釋放，以上方法等價(jià)于下面的寫法：

其次，使用synchronized還可以構(gòu)造同步塊，與同步方法相比，同步塊可以更為精確控制同步代碼范圍。一個(gè)小的同步代碼非常有離與鎖的快進(jìn)快出，從而使系統(tǒng)擁有更高的吞吐量。

synchronized也可以用于static函數(shù)：

這個(gè)地方一定要注意，synchronized的鎖是加在當(dāng)前Class對(duì)象上，因此，所有對(duì)該方法的調(diào)用，都必須獲得Class對(duì)象的鎖。

雖然synchronized可以保證對(duì)象或者代碼段的線程安全，但是僅使用synchronized還是不足以控制擁有復(fù)雜邏輯的線程交互。為了實(shí)現(xiàn)多線程間的交互，還需要使用Object對(duì)象的wait()和notify()方法。

典型用法：

在使用wait()方法前，需要獲得對(duì)象鎖。在wait()方法執(zhí)行時(shí)，當(dāng)前線程或釋放obj的獨(dú)占鎖，供其他線程使用。

當(dāng)?shù)却趏bj上線程收到obj.notify()時(shí)，它就能重新獲得obj的獨(dú)占鎖，并繼續(xù)運(yùn)行。注意了，notify()方法是隨機(jī)喚起等待在當(dāng)前對(duì)象的某一個(gè)線程。

下面是一個(gè)阻塞隊(duì)列的實(shí)現(xiàn)：

synchronized配合wait()、notify()應(yīng)該是Java開發(fā)者必須掌握的基本技能。

Reentrantlock重入鎖

Reentrantlock稱為重入鎖。它比synchronized擁有更加強(qiáng)大的功能，它可以中斷、可定時(shí)。在高并發(fā)的情況下，它比synchronized有明顯的性能優(yōu)勢。

Reentrantlock提供了公平和非公平兩種鎖。公平鎖是對(duì)鎖的獲取是先進(jìn)先出，而非公平鎖是可以插隊(duì)的。當(dāng)然從性能上分析，非公平鎖的性能要好得多。因此，在無特殊需要，應(yīng)該優(yōu)選非公平鎖，但是synchronized提供鎖業(yè)不是絕對(duì)公平的。Reentrantlock在構(gòu)造的時(shí)候可以指定鎖是否公平。

在使用重入鎖時(shí)，一定要在程序最后釋放鎖。一般釋放鎖的代碼要寫在finally里。否則，如果程序出現(xiàn)異常，Loack就永遠(yuǎn)無法釋放了。synchronized的鎖是JVM最后自動(dòng)釋放的。

經(jīng)典使用方式如下：

Reentrantlock提供了非常豐富的鎖控制功能，靈活應(yīng)用這些控制方法，可以提高應(yīng)用程序的性能。不過這里并非是極力推薦使用Reentrantlock。重入鎖算是JDK中提供的高級(jí)開發(fā)工具。

ReadWriteLock讀寫鎖

讀寫分離是一種非常常見的數(shù)據(jù)處理思想。在sql中應(yīng)該算是必須用到的技術(shù)。ReadWriteLock是在JDK5中提供的讀寫分離鎖。讀寫分離鎖可以有效地幫助減少鎖競爭，以提升系統(tǒng)性能。讀寫分離使用場景主要是如果在系統(tǒng)中，讀操作次數(shù)遠(yuǎn)遠(yuǎn)大于寫操作。使用方式如下：

Condition對(duì)象

Conditiond對(duì)象用于協(xié)調(diào)多線程間的復(fù)雜協(xié)作。主要與鎖相關(guān)聯(lián)。通過Lock接口中的newCondition()方法可以生成一個(gè)與Lock綁定的Condition實(shí)例。Condition對(duì)象和鎖的關(guān)系就如用Object.wait()、Object.notify()兩個(gè)函數(shù)以及synchronized關(guān)鍵字一樣。

這里可以把ArrayBlockingQueue的源碼摘出來看一下：

此實(shí)例簡單實(shí)現(xiàn)了一個(gè)對(duì)象池，對(duì)象池最大容量為100。因此，當(dāng)同時(shí)有100個(gè)對(duì)象請(qǐng)求時(shí)，對(duì)象池就會(huì)出現(xiàn)資源短缺，未能獲得資源的線程就需要等待。當(dāng)某個(gè)線程使用對(duì)象完畢后，就需要將對(duì)象返回給對(duì)象池。此時(shí)，由于可用資源增加，因此，可以激活一個(gè)等待該資源的線程。

ThreadLocal線程局部變量

在剛開始接觸ThreadLocal，筆者很難理解這個(gè)線程局部變量的使用場景。當(dāng)現(xiàn)在回過頭去看，ThreadLocal是一種多線程間并發(fā)訪問變量的解決方案。與synchronized等加鎖的方式不同，ThreadLocal完全不提供鎖，而使用了以空間換時(shí)間的手段，為每個(gè)線程提供變量的獨(dú)立副本，以保障線程安全，因此它不是一種數(shù)據(jù)共享的解決方案。

ThreadLocal是解決線程安全問題一個(gè)很好的思路，ThreadLocal類中有一個(gè)Map，用于存儲(chǔ)每一個(gè)線程的變量副本，Map中元素的鍵為線程對(duì)象，而值對(duì)應(yīng)線程的變量副本，由于Key值不可重復(fù)，每一個(gè)“線程對(duì)象”對(duì)應(yīng)線程的“變量副本”，而到達(dá)了線程安全。

特別值得注意的地方，從性能上說，ThreadLocal并不具有絕對(duì)的又是，在并發(fā)量不是很高時(shí)，也行加鎖的性能會(huì)更好。但作為一套與鎖完全無關(guān)的線程安全解決方案，在高并發(fā)量或者所競爭激烈的場合，使用ThreadLocal可以在一定程度上減少鎖競爭。

下面是一個(gè)ThreadLocal的簡單使用：

輸出結(jié)果：

輸出的結(jié)果信息可以發(fā)現(xiàn)每個(gè)線程所產(chǎn)生的序號(hào)雖然都共享同一個(gè)TestNum實(shí)例，但它們并沒有發(fā)生相互干擾的情況，而是各自產(chǎn)生獨(dú)立的序列號(hào)，這是因?yàn)門hreadLocal為每一個(gè)線程提供了單獨(dú)的副本。

鎖的性能和優(yōu)化

“鎖”是最常用的同步方法之一。在平常開發(fā)中，經(jīng)常能看到很多同學(xué)直接把鎖加很大一段代碼上。還有的同學(xué)只會(huì)用一種鎖方式解決所有共享問題。顯然這樣的編碼是讓人無法接受的。特別的在高并發(fā)的環(huán)境下，激烈的鎖競爭會(huì)導(dǎo)致程序的性能下降德更加明顯。因此合理使用鎖對(duì)程序的性能直接相關(guān)。

1、線程的開銷

在多核情況下，使用多線程可以明顯提高系統(tǒng)的性能。但是在實(shí)際情況中，使用多線程的方式會(huì)額外增加系統(tǒng)的開銷。相對(duì)于單核系統(tǒng)任務(wù)本身的資源消耗外，多線程應(yīng)用還需要維護(hù)額外多線程特有的信息。比如，線程本身的元數(shù)據(jù)，線程調(diào)度，線程上下文的切換等。

2、減小鎖持有時(shí)間

在使用鎖進(jìn)行并發(fā)控制的程序中，當(dāng)鎖發(fā)生競爭時(shí)，單個(gè)線程對(duì)鎖的持有時(shí)間與系統(tǒng)性能有著直接的關(guān)系。如果線程持有鎖的時(shí)間很長，那么相對(duì)地，鎖的競爭程度也就越激烈。因此，在程序開發(fā)過程中，應(yīng)該盡可能地減少對(duì)某個(gè)鎖的占有時(shí)間，以減少線程間互斥的可能。比如下面這一段代碼：

此實(shí)例如果只有mutexMethod()方法是有同步需要的，而在beforeMethod(),和afterMethod()并不需要做同步控制。如果beforeMethod(),和afterMethod()分別是重量級(jí)的方法，則會(huì)花費(fèi)較長的CPU時(shí)間。在這個(gè)時(shí)候，如果并發(fā)量較大時(shí)，使用這種同步方案會(huì)導(dǎo)致等待線程大量增加。因?yàn)楫?dāng)前執(zhí)行的線程只有在執(zhí)行完所有任務(wù)后，才會(huì)釋放鎖。

下面是優(yōu)化后的方案，只在必要的時(shí)候進(jìn)行同步，這樣就能明顯減少線程持有鎖的時(shí)間，提高系統(tǒng)的吞吐量。代碼如下：

3、減少鎖粒度

減小鎖粒度也是一種削弱多線程鎖競爭的一種有效手段，這種技術(shù)典型的使用場景就是ConcurrentHashMap這個(gè)類。在普通的HashMap中每當(dāng)對(duì)集合進(jìn)行add()操作或者get()操作時(shí)，總是獲得集合對(duì)象的鎖。這種操作完全是一種同步行為，因?yàn)殒i是在整個(gè)集合對(duì)象上的，因此，在高并發(fā)時(shí)，激烈的鎖競爭會(huì)影響到系統(tǒng)的吞吐量。

如果看過源碼的同學(xué)應(yīng)該知道HashMap是數(shù)組+鏈表的方式做實(shí)現(xiàn)的。ConcurrentHashMap在HashMap的基礎(chǔ)上將整個(gè)HashMap分成若干個(gè)段(Segment)，每個(gè)段都是一個(gè)子HashMap。如果需要在增加一個(gè)新的表項(xiàng)，并不是將這個(gè)HashMap加鎖，二十搜線根據(jù)hashcode得到該表項(xiàng)應(yīng)該被存放在哪個(gè)段中，然后對(duì)該段加鎖，并完成put()操作。這樣，在多線程環(huán)境中，如果多個(gè)線程同時(shí)進(jìn)行寫入操作，只要被寫入的項(xiàng)不存在同一個(gè)段中，那么線程間便可以做到真正的并行。具體的實(shí)現(xiàn)希望讀者自己花點(diǎn)時(shí)間讀一讀ConcurrentHashMap這個(gè)類的源碼，這里就不再做過多描述了。

4、鎖分離

在前面提起過ReadWriteLock讀寫鎖，那么讀寫分離的延伸就是鎖的分離。同樣可以在JDK中找到鎖分離的源碼LinkedBlockingQueue。

這里需要說明一下的就是，take()和put()函數(shù)是相互獨(dú)立的，它們之間不存在鎖競爭關(guān)系。只需要在take()和put()各自方法內(nèi)部分別對(duì)takeLock和putLock發(fā)生競爭。從而，削弱了鎖競爭的可能性。

5、鎖粗化

上面說到的減小鎖時(shí)間和粒度，這樣做就是為了滿足每個(gè)線程持有鎖的時(shí)間盡量短。但是，在粒度上應(yīng)該把握一個(gè)度，如果對(duì)用一個(gè)鎖不停地進(jìn)行請(qǐng)求、同步和釋放，其本身也會(huì)消耗系統(tǒng)寶貴的資源，反而加大了系統(tǒng)開銷。

我們需要知道的是，虛擬機(jī)在遇到一連串連續(xù)的對(duì)同一鎖不斷進(jìn)行請(qǐng)求和釋放的操作時(shí)，便會(huì)把所有的鎖操作整合成對(duì)鎖的一次請(qǐng)求，從而減少對(duì)鎖的請(qǐng)求同步次數(shù)，這樣的操作叫做鎖的粗化。下面是一段整合實(shí)例演示：

JVM整合后的形式：

因此，這樣的整合給我們開發(fā)人員對(duì)鎖粒度的把握給出了很好的演示作用。

無鎖的并行計(jì)算

上面花了很大篇幅在說鎖的事情，同時(shí)也提到過鎖是會(huì)帶來一定的上下文切換的額外資源開銷，在高并發(fā)時(shí)，”鎖“的激烈競爭可能會(huì)成為系統(tǒng)瓶頸。因此，這里可以使用一種非阻塞同步方法。這種無鎖方式依然能保證數(shù)據(jù)和程序在高并發(fā)環(huán)境下保持多線程間的一致性。

1、非阻塞同步/無鎖非阻塞同步方式其實(shí)在前面的ThreadLocal中已經(jīng)有所體現(xiàn)，每個(gè)線程擁有各自獨(dú)立的變量副本，因此在并行計(jì)算時(shí)，無需相互等待。這里筆者主要推薦一種更為重要的、基于比較并交換（Compare And Swap）CAS算法的無鎖并發(fā)控制方法。

CAS算法的過程：它包含3個(gè)參數(shù)CAS(V,E,N)。V表示要更新的變量，E表示預(yù)期值，N表示新值。僅當(dāng)V值等于E值時(shí)，才會(huì)將V的值設(shè)為N，如果V值和E值不同，則說明已經(jīng)有其他線程做了更新，則當(dāng)前線程什么都不做。最后CAS返回當(dāng)前V的真實(shí)值。CAS操作時(shí)抱著樂觀的態(tài)度進(jìn)行的，它總是認(rèn)為自己可以成功完成操作。當(dāng)多個(gè)線程同時(shí)使用CAS操作一個(gè)變量時(shí)，只有一個(gè)會(huì)勝出，并成功更新，其余俊輝失敗。失敗的線程不會(huì)被掛起，僅是被告知失敗，并且允許再次嘗試，當(dāng)然也允許失敗的線程放棄操作。基于這樣的原理，CAS操作及時(shí)沒有鎖，也可以發(fā)現(xiàn)其他線程對(duì)當(dāng)前線程的干擾，并且進(jìn)行恰當(dāng)?shù)奶幚怼?/p>

2、原子量操作

JDK的java.util.concurrent.atomic包提供了使用無鎖算法實(shí)現(xiàn)的原子操作類，代碼內(nèi)部主要使用了底層native代碼的實(shí)現(xiàn)。有興趣的同學(xué)可以繼續(xù)跟蹤一下native層面的代碼。這里就不貼表層的代碼實(shí)現(xiàn)了。

下面主要以一個(gè)例子來展示普通同步方法和無鎖同步的性能差距：

測試結(jié)果如下：

相信這樣的測試結(jié)果將內(nèi)部鎖和非阻塞同步算法的性能差異體現(xiàn)的非常明顯。因此我更推薦直接視同atomic下的這個(gè)原子類。

希望以上我的回答能幫到大家！