Tomcat的BIO和NIO一些問題

2021-09-26 07:58:05 字數 1608 閱讀 3998

最近一些朋友通過書籍找到我,問了一些關於tomcat中bio和nio的問題,這裡列一下方便需要的朋友。後續也將前面有朋友問的問題整理下。。

只把 tomcat 的 bio 模式改為 nio 模式,是否能提高伺服器的吞吐量?發現在配置一樣的情況下,兩種模式壓出來的吞吐量差不多。

要看你系統是不是整個都非同步化了,因為tomcat的nio只是將網路io非同步化了,就是接收和讀寫非同步化了,但是網路報文接受完後還是要交給業務執行緒池,如果你的業務是阻塞或者說較耗時的話是沒辦法提公升你整個的吞吐量的,除非將整個專案都非同步化,現在壓起來如果你的cpu如果還打滿的話就可以繼續優化,但如果bio都能打滿cpu就說明已經到物理極限了,沒啥好優化的了,只能在**層去優化了。

在做tomcat nio 模式壓測時發現併發量大時,一開始接收不了請求,到後面才慢慢恢復,這是什麼導致的?

應該不會接收不了,只是接收不過來,nio的接受執行緒一般是cpu數,一下很多請求可能需要一些時間來接收。

後來又能慢慢穩定,tps能夠上去是什麼是情況?

因為長連線,接收工作只做一次。

對比與 nio ,bio 一開始能接收的量比 nio 大,怎麼解釋?

bio接收是執行緒池裡面的執行緒接收的,也就是說你的執行緒池如果設為600,就有600個執行緒能接收,自然就大了,但是nio是只有cpu數個執行緒負責接收的。

nio 的優勢是什麼?是不是 nio 模式下 tomcat 預設能保持10000條連線,而 bio 模式則達不到。

簡單地說,nio 模式最大化壓榨了cpu,把時間片更好利用起來。通俗地說,bio hlod住連線不幹活也占用執行緒,nio hold住連線不幹活也沒關係,讓需要處理的連線執行就行了。

壓測時是短連線還是長連線?

一般工具都是長連線的,就像你用了連線池,池裡面的連線。基本不會有工具每請求一次都新建立 jdbc 連線,不然乙個連線光建立都得毫秒到秒級別。可以用 netstat 看下你的連線情況的。

nio 模式是不是更適合做 tcp 長連線,用少量執行緒 hold 住大量的連線,節省資源。但 tomcat 現在都是短連線,nio 抗併發並沒有比 bio 強?

nio 適合大量長連線,而且大部分只 hold 不處理的場景,如果你能將你的專案非同步化的話 nio 肯定比 bio 扛得多。你用 bio 其實壓測時是打不滿 cpu 的,所以採用 nio 來壓榨 cpu,如果你 bio 都能打滿 cpu,那就沒必要搞 nio 和非同步化了,因為物理極限了,沒啥好搞的了,只能去優化**。

bio 模式下將最大執行緒數不斷調大,直到打滿 cpu,這種情況和 nio 非同步比較,更傾向於哪一種?

達到峰值後會導致接收不了連線,作業系統層的連線佇列滿了則會拒絕連線。另外乙個是,你不可能開很多執行緒,bio 開太多執行緒可能會直接卡死,執行緒切換花銷很大,主要是要將阻塞的環節非同步出來,這樣執行緒就能高效幹活了。nio 模式我個人覺得還是比 bio 高效很多,因為 bio 模式光網路讀寫就可能塞很長時間了,而 nio 負責網路 io 的非同步化,其他非同步化要自己考慮。

以下是廣告

*****===廣告時間*****===

鄙人的新書《tomcat核心設計剖析》已經在京東銷售了,有需要的朋友可以到  進行預定。感謝各位朋友。

為什麼寫《tomcat核心設計剖析》

*************************

BIO和NIO的區別

bio 同步阻塞 每乙個io請求都會有乙個執行緒去處理,如果資料沒有準備就緒,執行緒會一直等待。直到資料讀取完畢執行緒才會釋放,在此期間,程序不回去做任何其他任務,這種模式會浪費一定的執行緒資源。nio 同步非阻塞 nio的優點在於首先基於快取讀寫檔案,能夠批量操作,然後用channel雙向讀寫資料...

我認識的BIO和NIO

簡介 bio 同步阻塞式io。實現模式為1個連線對應乙個執行緒。即每有1個新的請求時,就需要建立乙個新的執行緒去處理,並且執行緒永遠不會釋放。如果這個連線不去做任何事情的話,會造成資源浪費。nio 同步非阻塞式io。實現模式為1個請求對應乙個執行緒。即有乙個新的請求時,會註冊到作業系統tcp。而服務...

面試官 說一下NIO和BIO的區別

bio,面向流,只能讀或者只能寫,阻塞io nio,面向緩衝區,可以同時進行讀寫,非阻塞io 整個bio的繼承關係如上圖,每種流只能寫或者讀,整個bio流的設計用了裝飾者模式,如果你不清楚的話,可以看 面試官 說一下裝飾者模式的作用,以及哪些地方用到了裝飾者模式吧 本文不再介紹 nio涉及到的api...