從JAVA多線程理解到集羣分佈式和網絡設計的淺析

對於JAVA多線程的應用很是普遍，如今的系統沒有多線程幾乎什麼也作不了，不少時候咱們在何種場合如何應用多線程成爲一種首先須要選擇的問題，另外關於java多線程的知識也是很是的多，本文中先介紹和說明一些經常使用的，在後續文章中若是有必要再說明更加複雜的吧，本文主要說明多線程的一下幾個內容：

一、在應用開發中何時選擇多線程？

2、多線程應該注意些什麼？

3、狀態轉換控制，如何解決死鎖？

4、如何設計一個具備可擴展性的多線程處理器？

五、多線程聯想：在多主機下的擴展-集羣？

六、WEB應用的多線程以及長鏈接原理。

 

一、在應用開發中何時選擇多線程。

在前序的文章中已經簡單說起到過一些關於多線程應用的文章，經過對web的一些線程控制對下載流量的控制，其實那只是雕蟲小技，也存在不少的問題須要去解決，不過面對用戶量不大的人羣通常問題不大而已。

多線程在生活中的體現就是將多個一樣不少事情交給多我的來並行的完成，而中間有一個主線程起到調度者的做用，運行者能夠強制依賴於主線程的存在而存在，也可讓主線程依賴於自身；曾經我聽不少人說過若是你的機器是單CPU，多線程沒有意義，其實我並不這麼認爲，覺得內單個CPU只能證實在線程被調度的瞬間只能同時執行一條最底層的命令，而並不表明不能夠在CPU的徵用上提升效率，一個是內存級別的，而另外一個是CPU級別的，效率上仍然存在很大差距的；（這個可讓一個程序單線程去循環10億次（每次自增1），和讓十個線程獨立運行1億次也是一樣的動做，記住這裏不要將每條數據System.out.println出來，一個是機器扛不住，另外一個是這裏會對測試數據產生影響，由於這個方法我前面的文章中已經說明會產生阻塞，尤爲是在併發狀況下的阻塞，即便在單CPU下結果確定也是有很大差距的，我這暫時沒有單核的PC機器，因此無法獲得一些測試結果數據給你們，請有條件的朋友本身測試一下）。

在如今的系統中無時無刻都離不開多線程的思想，包括集羣、分佈式均可以理解爲多線程的一種原理，那麼什麼是多線程的原理呢？多線程和多進程的是什麼呢？

其實要實現分佈最簡單的思想就是多進程，其實相似於在系統分隔過程當中的一種垂直分隔，將不一樣業務的系統分佈在不一樣的節點上運行，他們彼此互不干擾，而多進程的申請、釋放資源各方面的開銷都很大，並且佔用資源並不是CPU級別的，而線程是屬於進程內部更細節的內容，一個進程內部能夠分配N個線程，這些線程會並行的徵用CPU資源，若是你的機器是多核的處理器，併發將會帶來異常的性能提高，其實原理上就是在有限的資源下，如何發揮出最大的性能優點（可是必定是資源有必定餘量的狀況下，正所謂作事不能作得太絕）。

在java中經常使用於實現多線程的方法有3中：

一、繼承於Thread類，重寫run方法

二、實現Runable接口，實現run方法

三、實現Callable接口，實現call方法（具備返回值）

至於調用的方法多種多樣，能夠直接用start啓動，也可使用java.util.concurrent.Executors來建立線程池來完成，建立的線程池也主要分爲：

一、Executors.newSingleThreadScheduledExecutor() 建立一個順序執行的線程池，你在run方法內部無需使用synchronized來同步，由於它自己是順序的。

二、Executors.newCachedThreadPool()建立一個線程池，線程會並行的去執行它。

三、Executors.newFixedThreadPool(10)建立大小爲10的一個線程池，這個線程池最多建立長度爲10的隊列，若是超過10個，就最多有10個線程在執行，便可以控制線程的數量，也可讓其並行執行。

 

若是你的系統是一個WEB應用，建議儘可能不要再web應用中作多線程，由於這部分線程控制主要是由web容器控制的，若是在非得必要的狀況下創建，儘可能創建較少，或者儘可能將能夠不太頻繁調度的線程使用完後直接釋放掉，哪怕下次重建也無所謂。

若是你的多線程序是獨立運行的，專門用於接受和和處理一些消息，那麼我相信最少有一個線程是不斷探測的（有不少程序會先休眠一點時間，如：TimeUnit.MINUTES.sleep(SLEEP_TIME)此方法是按照毫秒級進行休眠一段時間），這類程序，最好將線程設置爲後臺線程（setDaemon(true)，必定要在線程調用run以前調用該方法有效），後臺線程和非後臺線程最大的區別在於：後臺線程在全部非後臺線程死掉後，後臺線程自動會被殺死和回收；而正如你寫其餘的多線程程序，即便你的main方法完成（主線程），可是在main中申請的子線程沒有完成，程序仍然不會結束。

總的來講，其實幾乎每時每刻寫的代碼都是多線程的，只是不少事情容器幫助咱們完成了，即便編寫本地的AWT、SWING，也在不少控制處理中式異步的，只是這種異步相對較少，更多的異步能夠由程序去編寫，自定義的多線程通常用於在獨立於前段容器應用的後臺處理中。爲何相似web應用的前端會把多線程早就處理好呢，一個是由於爲了減小程序和bug，另一個就是要寫好多線程的確不容易，這樣會使得程序員去關心更多沒有必要關心的東西，也須要程序員擁有很高的水準，可是若是要成爲好的程序員就必定要懂多線程，咱們接下來以幾個問題入手，再進行說明：

若是一個系統專門用於時鐘處理、觸發器處理，這個系統多是分佈式的，那麼在一個系統內部應該如何編寫呢？另外多線程中編寫的過程當中咱們最鬱悶的事情、也是最難琢磨補丁的是什麼：多線程如今的運行情況是怎樣的？個人這個線程不能死掉，若是死掉了我怎麼發現？發現到瞭如何處理（自動、人工、難道重啓）？

帶着這些問題，咱們引出了文章下面的一些話題。

 

2、多線程應該注意些什麼？

多線程用起來爽，出現問題你就不是那麼爽了，簡單說來，多線程你最納悶的就是它的問題；可是不要懼怕它，你懼怕它就永遠不能征服它，呵呵，只要摸清楚一些脾氣，咱們總有辦法征服它的。

◆明白多線程有狀態信息，和之間的轉換規則？

◆多線程通常在什麼狀況下會出現焊住或者死掉的現象？

◆多線程焊住或者死掉如何捕獲和處理？

這裏僅僅是提出問題，提出問題後，在說到問題以前，先說起一下擴展知識點，下面的章節來講明這些問題。

開源多線程調度任務框架中的一個很好選擇是：Quartz，有關它的文章能夠到http://wenku.baidu.com/view/3220792eb4daa58da0114a01.html

下載這個文檔，這個文檔也講述了大部分該框架的使用方法，不過因爲該框架自己的封裝層次較多，因此不少底層的實現內容並非那麼明顯，並且對於線程池的管理基本是透明的，本身只能經過一些其餘的手段獲得這些內容。

因此拿到這個框架首先學習好它的特性後，進一步就是看如何進一步封裝它獲得最適合你項目的內容。

另外多線程在數據結構選項上也有不少技巧，關於多線程併發資源共享上的數據結構選型專門來和你們探討，由於技巧的確不少，尤爲是jdk 1.6之後提出了不少的數據結構，它參考了相似於oracle的版本號原理，在內存中作了數據複製以及原子拷貝的方法，實現了即保證一致性讀寫又在很大程度上下降了併發的徵用；另外還有對於樂觀鎖機制，也是高性能的多線程設計中很是重要知識體系。

 

3、狀態轉換控制，如何解決死鎖。

3.1.java默認線程的狀態有哪些？（所謂默認線程就是本身沒有重寫）

NEW ：剛剛建立的線程，什麼也沒有作，也就是尚未使用start命令啓動的線程。

BLOCKED ：阻塞或者叫梗阻，也就是線程此時因爲鎖或者某些網絡緣由形成阻塞，有焊住的跡象。

WAITING：等待鎖狀態，它在等待對一個資源的notify，即資源的一個鎖機會，這個狀態通常和一個靜態資源綁定，並在使用中有synchronzed關鍵字的包裝，當使用obj.wait()方法時，當前線程就會等待obj對象上的一個notify方法，這個對象多是this，若是是this的話那麼在方法體上面通常就會有一個synchronized關鍵字。

TIME_WAITDE:基於時間的等待，當線程使用了sleep命令後，就會處於時間等待狀態，時間到的時候，恢復到running狀態。

RUNNING：運行狀態，即線程正在處於運行之中（當線程被梗阻）。

TERMINATED：線程已經完成，此時線程的isAlive()返回爲false。

通常默認的線程狀態就是這些，部分容器或者框架會把線程的狀態等進行進一步的封裝操做，線程的名稱和狀態的內容會有不少的變化，不過只要找好對應的原理也不會脫離於這個本質。

3.1.線程通常在什麼狀況下會死掉？

鎖，相互交叉派對，最終致使死鎖；多是程序中本身致使，編寫共享緩存以及自定義的一部分脫離於容器的線程池管理這裏就須要注意了；還有就是有多是分佈式的一些共享文件或者分佈式數據庫的鎖致使。

網絡梗阻，網絡不怕沒有，也不怕太快，就怕時快時慢，如今的話叫太不給力了，傷不起啊！而國內如今每每還就是這樣不給力；當去網絡通訊調用內容的時候（包括數據庫交互通常也是經過網絡的），就很容易產生焊住的現象，也就是假死，此時很難斷定線程究竟是怎麼了，除非有提早的監控預案。

其餘狀況下線程還會死掉嗎？就我我的的經驗來講還沒遇到過，但並不是毫不可能，我想在常規的同一個JVM內部操做的線程會死掉的機率只有系統掛掉，否則SUN的java虛擬機也太不讓人信任了；至少從這一點上咱們能夠決定在絕大部分狀況下線程阻塞的主要緣由是上述兩個主要來源。

在明白絕大部分緣由的基礎上，這裏已經提出了問題並初步分析了問題，那麼繼續來如何解決這些問題，或者說將問題的機率下降到很是低的程度（由於沒有百分百的高可用性環境，咱們只是要儘可能去作到它儘可能完美，亞馬遜的雲計算也有宕機的驚人時刻，呵呵）。

3.1. 多線程焊住或者死掉如何捕獲和處理？

說到捕獲，學習java朋友確定第一想到的是try catch，可是線程假死根本不會拋異常，如何知道線程死掉了呢？

這須要從咱們的設計層面下手，對於後來java提供的線程池也能夠比較放心的使用，可是對於不少很是複雜的線程管理，須要咱們本身來設計管理。如何捕獲咱們用一個生活中的例子來舉例，下一長中將它反饋到實際的系統設計上。

首先多線程本身死掉了它確定不知道，就想一我的本身喝醉了或者被被人打暈了同樣，呵呵，那麼如何才能知道它的現狀了？提出兩種現實思路，一個是有一個跟班的人，而另外一種是它上面有一個領導帶一羣人出來玩，下面人丟了一個它確定要去找。

先看看第一種思路，跟班那個我假如他平時什麼也不作，就跟在前者後面，當發現前者倒下，本身立刻跟上去頂替工做，這也是系統架構上常常採用的冗餘主從切換，可能一主多從；而云計算也是在基礎上的進一步作的異地分流切換和資源動態調度（也就是事情少了，這些人能夠去作其餘的事情或者睡覺養精神而且爲國家節約糧食，當這邊的事情忙不過來，會有作其它事情的人或者待命的人來幫着作這些事情；甚至於此地遭到地震洪水類天災什麼的，異地還有機構能夠頂替一樣的工做內容，這樣讓對外的服務永遠不斷間斷下來，也就是傳說中的24*7的高可用性服務），可是這樣冗餘太大，成本將會很是巨大。

再看看第二種服務，上面有一個老大，它過一小會看看這幫小弟在作什麼，是否是遇到了困難，那裏忙它在上面動態調配這資源；好像這種模式很好呢？小弟要是多了，它就忙不過來了，由於資源的分配是須要提早明白下面資源的細節的，否則這個領導不是好領導；那麼再細想下去，咱們能夠用多個老大，每一個老大帶領一個小團隊，團隊之間能夠資源調配，可是團隊內部能夠由老大本身掌控一切，老大的上面還有個老總它只關心於老大再作什麼，而不須要關心小弟們的行爲，這樣你們的事情就平均起來了；那麼問題了又出來了，小弟的問題是能夠透明的看到了，要是那個老大出事了甚至於老總出事了怎麼辦？此時結合第一種思想，咱們此時就只須要再老總下面掛一個跟班的，集合兩種模式的特徵，也就是小弟不須要配跟班的，這樣就節約了很大的成本（由於葉子節點的數量是最多的），而上面的節點咱們須要有跟班的，若是想最大程度節約成本，只須要讓主節點配置一個或者多個跟班就能夠，可是這樣恢復成本就上去了，由於恢復信息須要逐層找到內容才行，通常咱們沒有必要在這個基礎上再進一步去節約成本。

這些是現實的東西，如何結合到計算機系統架構中，再回到本文的多線程設計上，第四章中一塊兒來探討一下。

 

4、如何設計一個具備可擴展性的多線程處理器。

其實在第三章中，已經從生活的管理模式上找到了不少的解決方案，這也是我我的在解決問題上慣用的手段，由於我的認爲再複雜的數學算法也沒有人性自己的複雜，生活中的種種手段若用於計算機中可能會獲得不少神奇的效果。

若是本身不使用任何開源技術，要作一個多線程處理的框架應該從何下手，在上面分析的基礎上，咱們通常會將一個專門處理多線程的系統至少分解爲主次二層，也就是主線程引導多個運行線程去處理問題；好了，此時咱們須要解決如下幾個問題：

a)多個線程處理的內容是相似的，如何控制併發徵用數據或者說下降併發熱點的粒度。

方法1：hash散列思想將會是優秀的原則，按照數據特徵進行分解數據框，每一個框的數據規則按照一種hash規則分佈，hash散列對於編程容易遍歷，並且計算速度很是迅速，幾乎能夠忽略掉定位分組的時間，但結構擴展過程比較麻煩，但在多線程設計中通常不須要考慮這個問題。

方法2：range分佈，range範 圍分佈數據是提早讓管理者知道數據的大體分佈狀況，並按照一種較爲平均的規則交給下面的運做線程去去處理本身範圍內的數據，相互之間的數據也是沒有任何交叉的，其擴展性較好，能夠任意擴展，若是分解的數量不受控制的話，分解過多，會形成定位範圍比較慢一點，可是多線程設計中也通常不用考慮這個問題，由於程序是由本身編寫的。

方法3：位圖分佈，即數據具備位圖規則，通常是狀態，這種數據按照位圖分佈後，線程能夠設立爲位圖個數，找到本身的位圖段數據便可作操做，而不須要作進一步的更新，可是每每位圖數量有限，而須要處理的數據量很大，一個線程處理一個位圖下的全部數據也每每力不從心，若多個線程處理一個位圖又會重蹈覆轍。

三種方法各自有優缺點，因此咱們每每採用組合模式來說真個系統的架構達到比較完美的狀態，固然沒有完美的東西，只有最適應於當前應用環境的架構，因此設計前須要考慮不少預見性問題；關於這種數據分佈更多的用於架構，可是架構的基礎也來源於程序設計思想，二者思想都是一致的，有關架構和數據存儲分佈，後面有機會單獨討論。

b)線程死掉如何發現(以及處理)：

管理線程除有運行動做的線程外，還有1~N跟班，個數根據實際狀況決定，至少要有一個當管理線程掛掉能夠立刻頂替工做，另外還有應當有一個線兩程去按期檢測線程的運行狀況，因爲它只負責這件事情，因此很簡單，並且這一組中的線程誰死掉均可以相互替換工做並重啓新的線程去替代，這個檢測的週期不用太快、也不用太慢，只要應用能夠接受就能夠，由於掛掉些東西，應用阻塞一點時間是很是正常的事情。

發現線程有阻塞現象，在執行中找到了某種之外而阻塞，致使的緣由咱們上面已經分析過，解決的方法通常是在探測幾回（這個次數通常是基於配置的）後發現都是處於阻塞狀態，就基本能夠認爲它是錯誤的了；錯誤的狀況此時須要給該線程執行一個interrupt()方法，此時線程內部的執行會自動的拋出一個異常，也就是理解執行線程的內容的時候尤爲是帶有網絡操做的時候須要帶上一個try catch，執行部分都在try中，當出現假死等現狀的時候，外部探測到使用一個interrupt()方法，運行程序就會跳轉到catch之中，這個裏面就不存在徵用資源的問題，而快速的將本身的須要回滾的內容執行完，並認爲線程執行結束，相應的資源也會獲得釋放，而使用stop方法之因此如今不推薦是由於它不會釋放資源，會致使不少的問題。

另外寫代碼以前若是涉及到一些網絡操做，必定要對你所使用的網絡交互程序有不少的深刻認識，如socket交互時，通常狀況下若是對方因爲網絡緣由（通常是有IP當時端口不對或者網段的協議不通）致使在啓動鏈接對方時，socket鏈接對方好幾分鐘後纔會顯示是超時鏈接，這是默認的，因此你須要提早設置一個啓動鏈接超時保證網絡是能夠通訊的，再進行執行（注意socket裏面還有一個超時是鏈接後不斷的時間，前者爲鏈接以前設置的一個啓動鏈接超時時間，通常這個時間很短，通常是2秒就很長了，由於2秒都鏈接不上這個網絡就基本鏈接不上了，然後者是運行，有些交互可能長達幾小時也有可能，但相似這種交互建議採用異步交互，以保證穩定運行）。

C）若是啓動和管理二級管理線程組：

上面有一個主線程來控制啓動和關閉，這裏能夠將這些線程在start前的setDaemon(true)，那麼該線程將會被設立爲後臺線程，所謂後臺線程就是當主線程執行完畢釋放資源後，被主線程建立的這些線程將會自動釋放資源並死掉，若是一個線程被設置爲後臺線程，若在其run方法內部建立的其餘子線程，將會自動被建立爲後臺線程（若是在構造方法中建立則不是這樣）。

管理線程也能夠像二級線程同樣來管理子節點，只要你的程序不怕寫得夠複雜，雖然須要使用很是好的代碼來編寫，而且須要經過很複雜的測試纔會穩定運行，可是一旦成功，這個框架將會是很是漂亮和穩定，並且也是高可用的。

 

五、多線程在多主機下的擴展-集羣

其實咱們在上面以及說起了一些分佈式的知識，也能夠叫作數據的分區知識（在網絡環境利用PC實現相似於同一個主機上的分區模式，基本就能夠稱爲數據是分佈式存儲的）。

可是這裏提到的集羣和這個有一些區別，能夠說分佈式中包含了集羣的概念，可是通常集羣的概念也有不少的區別，而且要分app集羣和數據庫集羣。

集羣通常是指同一個機組下多個節點（同一臺機器也能夠部署多個節點），這些節點幾乎去完成一樣的事情，或者說相似的事情，這就和多線程扯在一塊兒了，多線程也正是如此，對比來看就是多線程調度在多主機羣組下的實現，因此參照app集羣來講，通常有一個管理節點，它幾乎幹不多的事情，由於咱們不想讓它掛掉，由於他雖然乾的事情少，可是卻很是重要，一個是從它那裏能夠獲得每個節點的一些應用部署和配置，以及狀態等等信息；另外是代理節點或者叫作分發節點，它幾乎在管理節點的控制之下只作分發的，固然要保證session一致性。

集羣在多線程中的另外一個體現就是掛掉一臺，其他的能夠頂替，而不會致使全盤死掉；而集羣組至關於一個大的線程組，相關牽制管理，也相互能夠失敗切換，而多個業務會或者多種工具項會劃分爲不一樣的集羣組，這就相似於咱們設計線程中的三層線程模式的中多組線程組的模式，每組線程組內部都有本身個性化的屬性和共享屬性。

而面對數據庫集羣，就相對比app集羣要複雜，app在垂直擴展時幾乎只會受到分發節點能力的限制，而這部分是能夠調整的，因此它在垂直擴展的過程當中很是方便，而數據庫集羣則不同，它必須保證事務一致性，並實現事務級別切換和必定程度上的網格計算能力，中間比較複雜的也在內存這塊，由於它的數據讀入到內存中要將多個主機的內存配置得像一個內存同樣（經過心跳完成），並且須要獲得動態擴展的能力，這也是數據庫集羣下擴展性收到限制發展的一個緣由之一。

App難道沒有和數據庫同樣的困難嗎？有，可是粒度相對較小，app集羣通常不須要考慮事務，由於一個用戶的session通常在不出現宕機的狀況下，是不會出現複製要求的，而是一直會訪問指定的一臺機器，因此它們之間幾乎不須要通訊；而耦合的粒度在於應用自己的設計，有部分應用系統會本身寫代碼將一些內容初始化注入到內存中，或者注入到app本地的一個文件中做爲文件緩存；這樣當這些數據發生改變時他們先改數據庫，再修改內存或者通知內存失效；數據庫因爲集羣使用心跳鏈接，因此保持一致性，而app這邊的數據因爲只修改掉了自身的內存相關信息，沒有修改掉其餘機器的內存信息，因此必然致使訪問其餘數據的機器上的內容是不一致的；至於這部分的解決方案，根據實際項目而定，有經過通訊完成的，也有經過共享緩衝區完成（但這種方式又回到共享池資源徵用產生的鎖了），也有經過其餘方式完成。

大型系統架構最終數據分佈，集中式管理，分佈式存儲計算，業務級別橫向切割，同業務下app垂直分隔，數據級別散列+range+位圖分佈結構，異地分流容災，待命機組和資源調配的整合，這一切的基礎都來源於多線程的設計思想架構在分佈式機組上的實現。

六、WEB應用的多線程以及長鏈接原理

WEB應用中會對一些特殊的業務服務作特殊的服務器定製，相似一些高併發訪問系統甚至於專門用於瞬間高併發的系統（不少時候系統不怕高併發，而是怕瞬間高併發）但他們的訪問每每比較簡單，主要用於事務的處理以及數據的一致性保障，他們在數據的處理上要求在數據庫端也不容許有太大的計算量，計算通常在app中去完成，數據庫通常只是作存、取、事務一致性動做，這類通常屬於特殊的OLTP系統；還有大分類一類是屬於併發量不算太大，但每次處理的數據和計算每每比較多，一把說的是OLAP類的系統，而數據的來源通常是OLTP，OLAP每次處理的數據量可能會很是大，通常在類型收集和統計上進行數據dump，須要將OLTP中的數據按照某種業務規則方面查詢和檢索的方法提取出來組織爲有效信息存儲在另外一個地方，這個地方有可能仍是數據庫，但也有可能不是（數據庫的計算能力雖然是數據上最強的可是它在實際應用中它是最慢的一種東西，由於數據庫更多的是須要保證不少事務一致性和鎖機制問題，以及一些中間解析和優化等等產生的開銷是很是大的，並且應用程序與之交互過程是須要經過網絡完成，因此不少數據在實際的應用中並不必定非要用數據庫）；這兩類系統在設計和架構上都有很大的區別，但普通系統二者都有特徵，可是都不是那麼極端，因此不用考慮太多，這裏須要提到的是一類很是特殊的系統，是實時性推送數據並高併發的系統，到目前爲止我我的不知道將它歸併到哪一類系統中，這的確很特殊的一類系統。

這類系統如：高併發訪問中，並且須要將同一個平臺下的數據讓客戶端較爲實時的獲得內容，這類網站不太可能一次獲取很是多的內容到客戶端再訪問，而確定是經過不少異步交互過程來完成的，下面簡單說下這個異步交互。

Web異步交互的全部框架基礎都是ajax，其他的相似框架都是在這個基礎上完成的；那麼此時ajax應該如何來控制交互才能獲得幾乎接近於實時的內容呢？難道經過客戶端不斷去刷新相同的URL？那要是客戶端很是多，相似於一個大型網站，可能服務器端很快會宕機，除非用比正常狀況高出不少倍的服務器成本去作，並且更多的服務器可能在架構上也須要改造才能發揮出他們的性能（由於在服務器的架構上，1 + 1永遠是小於2的性能，更多的服務器在開銷）。

想到的另外一種辦法就是從服務器端向客戶端推送數據，那麼問題是如何推送，這類操做是基於一種長鏈接機制完成，長鏈接即不斷開的鏈接，客戶端採用ajax與後端通訊時，後端的反饋信息只要不曾斷開就可視爲一種長鏈接的機制；不少是經過socket與服務器端通訊，也可使用ajax，不過ajax須要在其上面作不少的處理才行。

服務器端也是必須使用對應的策略，如今較多的是javaNIO，相對BIO性能要低一點，可是也是很不錯的，它在獲取到用戶請求時並非立刻爲用戶請求分配線程去處理，而是將請求進行排隊，而排隊的過程能夠本身去控制粒度，而線程也將做爲線程池的隊列進行分配處理，也就是服務器端對客戶端的請求是異步響應（注意這裏不是ajax單純的異步交互，而是服務器端對請求的異步響應），它對不少請求的響應並不是及時，當發生數據變化時，服務器第一時間經過請求列表獲取到客戶端session列表並與之輸出內容，相似於服務器端主動推送數據向客戶端；而異步交互的好處是服務器端並不會爲每個客戶端分配或新申請一個線程，這樣會致使高併發時引發的資源分配不過來致使的內存溢出現象；解決了上述兩個問題後，另外還有一個問題須要解決的是，當一個線程在處理一個請求任務時，因爲線程處理一個任務完成前除非死掉或者焊住，不然是不會斷開下來的，這個是確定的（咱們能夠將一些大任務切割爲一些小任務，線程就處理的速度就會快不少了），可是有一個問題是，服務器端的這個線程可能很快處理好了須要處理的數據內容並向客戶端推送，可是客戶端因爲各種網絡通訊問題，致使遲遲不能接受完成，此時該線程也會被佔用些沒必要要的時間，那麼是否在這個中間須要進一步作一層斷點傳送的緩存呢？緩存不只僅是屬於在斷點數據須要時取代應用服務器的內容，異步斷點向客戶端輸出信息，同時將應用服務器處理的時間幾乎所有集中在數據和業務處理，而不是輸出網絡上的不少佔用，有關網絡緩存有不少種作法，後續有機會和你們一塊兒探討關於網絡緩存的知識吧。