一文搞定Netty寫數(shù)據(jù)高性能原理
? 點(diǎn)擊上方“JavaEdge”，關(guān)注公眾號
1 寫數(shù)據(jù)的核心問題
| 快遞場景(包裹) | Netty寫數(shù)據(jù)(數(shù)據(jù)) |
|---|---|
| 攬收到倉庫 | write:寫到一個(gè)buffer |
| 從倉庫發(fā)貨 | flush:把buffer里的數(shù)據(jù)發(fā)送出去 |
| 攬收到倉庫并立馬發(fā)貨( 加急件) | writeAndFlush: 寫到buffer, 立馬發(fā)送 |
| 攬收與發(fā)貨之間有個(gè)緩沖的倉庫 | Write和Flush之間有個(gè)ChannelOutboundBuffer |
1.1 寫炸了
對方倉庫爆倉時(shí)，送不了的時(shí)候，會停止送，協(xié)商等電話通知什么時(shí)候好了,再送。
Netty寫數(shù)據(jù)，寫不進(jìn)去時(shí)，會停止寫，然后注冊一個(gè) OP_WRITE事件，來通知什么時(shí)候可以寫進(jìn)去了再寫。
1.2 挺能寫的
發(fā)送快遞時(shí)，對方倉庫都直接收下，這個(gè)時(shí)候再發(fā)送快遞時(shí)，可以嘗試發(fā)送更多的快遞試試，這樣效果更好。
Netty批量寫數(shù)據(jù)時(shí)，如果嘗試寫的都寫進(jìn)去了，接下來會嘗試寫更多(調(diào)整maxBytesPerGatheringWrite)
1.3 我還能寫
發(fā)送快遞時(shí)，發(fā)到某個(gè)地方的快遞特別多，我們會連續(xù)發(fā)，但是快遞車畢竟有限，也會考慮下其他地方
Netty只要有數(shù)據(jù)要寫，且能寫的出去，則一直嘗試，直到寫不出去或滿16次(writeSpinCount)
寫16次還沒有寫完，就直接 schedule 一個(gè) task 來繼續(xù)寫，而不是用注冊寫事件來觸發(fā)，更簡潔有力。
1.4 寫不過來了
攬收太多，發(fā)送來不及時(shí)，爆倉，這個(gè)時(shí)候會出個(gè)告示牌:收不下了，最好過2天再來郵寄吧。
Netty待寫數(shù)據(jù)太多，超過一定的水位線(writeBufferWaterMark.high()) ，會將可寫的標(biāo)志位改成 false，讓應(yīng)用端自己做決定要不要發(fā)送數(shù)據(jù)（寫）了（很真實(shí)，將責(zé)任推給用戶）。
2 核心流程
Write - 寫數(shù)據(jù)到buffer :
ChannelOutboundBuffer#addMessage
Flush -發(fā)送buffer里面的數(shù)據(jù):
AbstractChannel.AbstractUnsafe#flush
準(zhǔn)備數(shù)據(jù): ChannelOutboundBuffer#addFlush
寫完了更新狀態(tài)
發(fā)送: NioSocketChannel#doWrite
3 寫數(shù)據(jù)的根本
Single write
sun.nio.ch.SocketChannelmpl#write(java.nio.ByteBuffer)
gathering write（批量寫）
sun.nio.ch.SocketChannelmpl#write(java.nio.ByteBuffer[], int, int)
寫數(shù)據(jù)寫不進(jìn)去時(shí)，會停止寫，注冊一個(gè)?OP_WRITE?事件，來通知什么時(shí)候可以寫進(jìn)去了。
OP_WRITE不代表有數(shù)據(jù)可寫，而是可以寫進(jìn)去，所以正常情況下不要注冊它，否則會一直觸發(fā)。
channelHandlerContext.channel().write()
從TailContext開始執(zhí)行
channelHandlerContext.write()
從當(dāng)前的Context開始
往期推薦
目前交流群已有?800+人，旨在促進(jìn)技術(shù)交流，可關(guān)注公眾號添加筆者微信邀請進(jìn)群
喜歡文章，點(diǎn)個(gè)“在看、點(diǎn)贊、分享”素質(zhì)三連支持一下~