您好,登錄后才能下訂單哦!
這篇“Netty的Handler鏈調用機制是什么及怎么組織”文章的知識點大部分人都不太理解,所以小編給大家總結了以下內容,內容詳細,步驟清晰,具有一定的借鑒價值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來看看這篇“Netty的Handler鏈調用機制是什么及怎么組織”文章吧。
Netty是一款基于NIO的異步事件驅動網絡應用框架,其核心概念之一就是Handler。而Handler是Netty中處理事件的核心組件,用于處理入站和出站的數據流,實現業務邏輯和網絡協議的處理。
在Netty中,Handler是一個接口,主要分為兩種:ChannelInboundHandler
(入站Handler)和ChannelOutBoundHandler
(出站Handler),如下圖所示。
ChannelInboundHandler
:處理從網絡通道中讀取到的數據,包括解碼、反序列化、消息分發等操作;
ChannelOutboundHandler
:可以負責將處理結果編碼、加密并通過網絡通道發送出去等
為了方便事件在各個Handler中處理與傳遞,在Netty中,每一個ChannelHandler
被封裝為一個ChannelHandlerContext
ChannelHandlerContext
提供了對ChannelHandler
的訪問,以及它前后相鄰的ChannelHandler
的訪問。在ChannelHandlerContext
的抽象實現類AbstractChannelHandlerContext
,可以很清楚的看到,它擁有next
和prev
兩個屬性,分別對應下一個和上一個ChannelHandlerContext
在Netty中,一個完整的處理鏈路可以由多個ChannelHandlerContext
組成,這些ChannelHandlerContext
形成一個管道(Pipeline) ,通過管道串聯起來,形成完整的數據處理流程。在數據流經過管道中的每個ChannelHandlerContext
時,都可以對數據進行一些特定的處理。
在ChannelPipeline
的源碼中,我們可以看到這樣的一段注釋
這可能容易讓人產生認為Pipeline
中維護了兩條鏈表,其中一條用于處理出站事件,另外一條處理入站事件。
實際上,Pipeline
是維護了一條雙向鏈表,當數據從入站方向流經處理程序鏈時,數據從雙向鏈表的head
向后面遍歷,依次將事件交由后面一個handler
處理,當數據從出站方向流經處理程序鏈時,數據從雙向鏈表的tail
向前面遍歷,依次將事件交由下一個handler
處理。
ChannelPipeline
如何調度 handler
上面提到,Pipeline
中維護了一個由handler
雙向鏈表。那么,當事件進入pipeline
中時,ChannelPipeline
是如何調用這些 handler
的呢 ?
當一個請求進入時,pipeline
會首先調用 ChannelContext
的 fireXXX()
方法(下面以 fireChannelRead()
為例),在 fireChannelRead()
中,會調用 invokeChannelRead(head, msg)
并將包裝著下一個要執行的 handler
的ChannelContext
傳入
事件第一個經過的一定是 head
,因此在下面的代碼中,invokeChannelRead()
傳入的是 head
@Override public final ChannelPipeline fireChannelRead(Object msg) { AbstractChannelHandlerContext.invokeChannelRead(head, msg); return this; }
進入invokeChannelRead()
,后會調用handler
真正的channelRead(this, msg)
方法進行業務處理
private void invokeChannelRead(Object msg) { if (invokeHandler()) { try { ((ChannelInboundHandler) handler()).channelRead(this, msg); } catch (Throwable t) { notifyHandlerException(t); } } else { fireChannelRead(msg); } }
進行業務處理之后,channelRead()
會執行ctx.fireChannelRead(msg)
,通過這行代碼將處理過的消息傳遞給下一個處理器進行處理
@Override public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { ctx.fireChannelRead(msg); }
從下面的代碼可以看到,fireChannelRead()
方法與上面 1 中唯一不同的是,調用了findContextInbound()
方法來尋找下一個 handler
在findContextInbound()
中,我們可以發現,它使用了一個 do while
循環來尋找下一個 handler
,這個循環當下一個 handler
的類型同為 inbound
時,會被返回。因此,當事件入站時,每次進行事件處理的handler
都是 ChannelInboundHandler
。(出站同理)
至此,fireChannelRead()
調用當前AbstractChannelHandlerContext
的invokeChannelRead()
回到 2
@Override public ChannelHandlerContext fireChannelRead(final Object msg) { invokeChannelRead(findContextInbound(), msg); return this; } private AbstractChannelHandlerContext findContextInbound() { AbstractChannelHandlerContext ctx = this; do { ctx = ctx.next; } while (!ctx.inbound); return ctx; }
從這點可以看出:一般情況下,我們需要在處理程序鏈中的每個handler
調用 ctx.fireChannelRead(msg)
,以確保將事件傳遞給下一個處理程序。如果在handler
中未調用 ctx.fireChannelRead(msg)
,則該事件將被截獲并停留在當前handler
中,不會傳遞到下一個處理程序。
以上就是關于“Netty的Handler鏈調用機制是什么及怎么組織”這篇文章的內容,相信大家都有了一定的了解,希望小編分享的內容對大家有幫助,若想了解更多相關的知識內容,請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。