多線程模型適用於處理短連接,且連接的打開關閉非常頻繁的情形,但不適合處理長連接,原因是什麼?

汪有飛

首先我們至少得知道什麼連接吧?

網絡通信的七層協議自不必說,是我們入門互聯網一開始就要學習的,HTTP協議是應用層協議,傳輸層和網絡層分別為TCP,IP協議!

也就是說我們建立連接起碼需要TCP協議的三次握手,認證通過之後client和server之間才能保證數據傳輸,才算是連接上了,而斷開連接的時候需要四次揮手,是一個連接斷連(close)的過程!





那麼短連接和長連接又有什麼區別呢?

短連接:經過client發起連接,開始認證(三次握手),數據傳輸,連接關閉(close)!

長連接:經過client發起連接,開始認證,數據傳輸,探測連接,數據傳輸。。。。連接關閉!

短連接追求的是每次通信之後,就斷開連接,能避免長時間連接對server性能的開銷,而長連接是在建立之後,只有客戶端發起關閉請求,或者服務端探測不到客戶端的響應以後才進行連接的關閉,這樣長連接就不需要多次的創建和銷燬連接,節省創建開銷!

再看看多線程,JAVA的多線程模型如果對於每一次的連接都需要創建一個線程來維護連接,如果為長連接的時候,線程不能釋放,按照每個線程1M的內存消耗,8G的服務器頂多也只能支撐幾千個連接,更多的連接請求將把服務器撐爆!

而如果處理短鏈接,最好使用線程池,避免關閉連接的時候線程釋放不及時,造成內存洩露,使用線程池可以保證線程複用,在一定量的連接裡,性能更好!

單就連接來看,因為IP協議的限制,最大的連接數為2的48次方,但是假設單單的連接使用內存來看,假設只使用了10k內存,那麼一臺8g內存的機器也只能支持百萬連接,再加上程序保持連接的線程,線程中的對象消耗等,高併發狀況下的可處理連接就少的可憐了,所以多線程處理短連接更有優勢一些!

當然現在的web服務器處理長連接的方法多如牛毛,避免大量線程創建的方法避不開reactor模型,比如netty框架

區別於多線程的處理方式,reactor模型使用一個線程(當然現在也會加上監控線程啥的),不斷的輪詢連接,有數據傳輸的情況下才進行處理,性能極好!

這種多路複用的模型很是複雜,不在這個回答的範圍內,改天分享!更多的技術分享,敬請關注。。。


分享到:


相關文章: