多線程使用的主要目的在于：1、吞吐量：你做WEB，容器幫你做了多線程，但是他只能幫你做請求層面的。簡單的說，可能就是一個請求一個線程。或多個請求一個線程。如果是單線程，那同時只能處理一個用戶的請求。2、伸縮性：也就是說，你可以通過增加CPU核數(shù)來提升性能。如果是單線程，那程序執(zhí)行到死也就利用了單核，肯定沒辦法通過增加CPU核數(shù)來提升性能。 鑒于是做WEB的，第1點可能你幾乎不涉及。那這里我就講第二點吧。

舉個簡單的例子：

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

1. 讀取文件1 （10ms）
2. 處理1的數(shù)據(jù)（1ms）
3. 讀取文件2 （10ms）
4. 處理2的數(shù)據(jù)（1ms）
5. 讀取文件3 （10ms）
6. 處理3的數(shù)據(jù)（1ms）
7. 整合1、2、3的數(shù)據(jù)結果 （1ms）

單線程總共就需要34ms。 那如果你在這個請求內(nèi)，把ab、cd、ef分別分給3個線程去做，就只需要12ms了。 所以多線程不是沒怎么用，而是，你平常要善于發(fā)現(xiàn)一些可優(yōu)化的點。然后評估方案是否應該使用。假設還是上面那個相同的問題：但是每個步驟的執(zhí)行時間不一樣了。

1. 讀取文件1 （1ms）
2. 處理1的數(shù)據(jù)（1ms）
3. 讀取文件2 （1ms）
4. 處理2的數(shù)據(jù)（1ms）
5. 讀取文件3 （28ms）
6. 處理3的數(shù)據(jù)（1ms）
7. 整合1、2、3的數(shù)據(jù)結果 （1ms）

單線程總共就需要34ms。 如果還是按上面的劃分方案（上面方案和木桶原理一樣，耗時取決于最慢的那個線程的執(zhí)行速度），在這個例子中是第三個線程，執(zhí)行29ms。那么最后這個請求耗時是30ms。比起不用單線程，就節(jié)省了4ms。但是有可能線程調(diào)度切換也要花費個1、2ms。因此，這個方案顯得優(yōu)勢就不明顯了，還帶來程序復雜度提升。不太值得。 那么現(xiàn)在優(yōu)化的點，就不是第一個例子那樣的任務分割多線程完成。而是優(yōu)化文件3的讀取速度。可能是采用緩存和減少一些重復讀取。 首先，假設有一種情況，所有用戶都請求這個請求，那其實相當于所有用戶都需要讀取文件3。那你想想，100個人進行了這個請求，相當于你花在讀取這個文件上的時間就是28×100=2800ms了。那么，如果你把文件緩存起來，那只要第一個用戶的請求讀取了，第二個用戶不需要讀取了，從內(nèi)存取是很快速的，可能1ms都不到。

偽代碼：

publicclassMyServletextendsServlet{ privatestaticMapfileName2Data=newHashMap(); privatevoidprocessFile3(StringfName){ Stringdata=fileName2Data.get(fName); if(data==null){ data=readFromFile(fName);//耗時28ms fileName2Data.put(fName,data); } //processwithdata } } 看起來好像還不錯，建立一個文件名和文件數(shù)據(jù)的映射。如果讀取一個map中已經(jīng)存在的數(shù)據(jù)，那么就不不用讀取文件了。 可是問題在于，Servlet是并發(fā)，上面會導致一個很嚴重的問題，死循環(huán)。因為，HashMap在并發(fā)修改的時候，可能是導致循環(huán)鏈表的構成?。。。ň唧w你可以自行閱讀HashMap源碼）如果你沒接觸過多線程，可能到時候發(fā)現(xiàn)服務器沒請求也巨卡，也不知道什么情況！ 好的，那就用ConcurrentHashMap，正如他的名字一樣，他是一個線程安全的HashMap，這樣能輕松解決問題。

publicclassMyServletextendsServlet{ privatestaticConcurrentHashMapfileName2Data=newConcurrentHashMap(); privatevoidprocessFile3(StringfName){ Stringdata=fileName2Data.get(fName); if(data==null){ data=readFromFile(fName);//耗時28ms fileName2Data.put(fName,data); } //processwithdata } } 這樣真的解決問題了嗎，這樣雖然只要有用戶訪問過文件a，那另一個用戶想訪問文件a，也會從fileName2Data中拿數(shù)據(jù)，然后也不會引起死循環(huán)。最新 Java 面試題出爐！分享給你。 可是，如果你覺得這樣就已經(jīng)完了，那你把多線程也想的太簡單了，騷年！你會發(fā)現(xiàn)，1000個用戶首次訪問同一個文件的時候，居然讀取了1000次文件（這是最極端的，可能只有幾百）。What the ***in hell!!! 難道代碼錯了嗎，難道我就這樣過我的一生！ 好好分析下。Servlet是多線程的，那么

publicclassMyServletextendsServlet{ privatestaticConcurrentHashMapfileName2Data=newConcurrentHashMap(); privatevoidprocessFile3(StringfName){ Stringdata=fileName2Data.get(fName); //“偶然”--1000個線程同時到這里，同時發(fā)現(xiàn)data為null if(data==null){ data=readFromFile(fName);//耗時28ms fileName2Data.put(fName,data); } //processwithdata } } 上面注釋的“偶然”，這是完全有可能的，因此，這樣做還是有問題。 因此，可以自己簡單的封裝一個任務來處理。

publicclassMyServletextendsServlet{ privatestaticConcurrentHashMapfileName2Data=newConcurrentHashMap(); privatestaticExecutorServiceexec=Executors.newCacheThreadPool(); privatevoidprocessFile3(StringfName){ FutureTaskdata=fileName2Data.get(fName); //“偶然”--1000個線程同時到這里，同時發(fā)現(xiàn)data為null if(data==null){ data=newFutureTask(fName); FutureTaskold=fileName2Data.putIfAbsent(fName,data); if(old==null){ data=old; }else{ exec.execute(data); } } Stringd=data.get(); //processwithdata } privateFutureTasknewFutureTask(finalStringfile){ returnnewFutureTask(newCallable(){ publicStringcall(){ returnreadFromFile(file); } privateStringreadFromFile(Stringfile){return"";} } } } 以上所有代碼都是直接在bbs打出來的，不保證可以直接運行。 多線程最多的場景：web服務器本身；各種專用服務器（如游戲服務器）；

審核編輯 ：李倩