netty中pipeline異常事件分析
異常處理的場景
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
throw new Exception("throw Exception");
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
System.out.println(cause.getMessage());
}
我們在handler的channelRead方法中主動拋出異常, 模擬程序中出現(xiàn)異常的場景, 經(jīng)測試會發(fā)現(xiàn), 程序最終會走到exceptionCaught方法中, 獲取異常對象并打印其信息
那么拋出異常之后, 是如何走到exceptionCaught方法的呢?
我們回顧之前小節(jié)channelRead事件的傳播流程, channelRead方法是在AbstractChannelHandlerContext類的invokeChannelRead方法中被調(diào)用
AbstractChannelHandlerContext.invokeChannelRead
private void invokeChannelRead(Object msg) {
if (invokeHandler()) {
try {
//調(diào)用了當前handler的channelRead方法, 其實就是head對象調(diào)用自身的channelRead方法
((ChannelInboundHandler) handler()).channelRead(this, msg);
} catch (Throwable t) {
//發(fā)生異常的時候在這里捕獲異常
notifyHandlerException(t);
}
} else {
fireChannelRead(msg);
}
}
這里不難看出, 當調(diào)用戶自定義的handler的channelRead方法發(fā)生異常之后, 會被捕獲, 并調(diào)用notifyHandlerException方法, 并傳入異常對象, 也就是我們示例中拋出的異常
AbstractChannelHandlerContext.notifyHandlerException(Throwable cause)
private void notifyHandlerException(Throwable cause) {
//代碼省略
invokeExceptionCaught(cause);
}
AbstractChannelHandlerContext.invokeExceptionCaught(final Throwable cause)
private void invokeExceptionCaught(final Throwable cause) {
if (invokeHandler()) {
try {
//當前handler調(diào)用exceptionCaught()方法
handler().exceptionCaught(this, cause);
} catch (Throwable error) {
//代碼省略
}
} else {
fireExceptionCaught(cause);
}
}
走到這里一切都明白了, 這里調(diào)用了當前handler的exceptionCaught方法, 也就是我們重寫的exceptionCaught方法
知道了為什么會走到exceptionCaught方法之后, 我們再進行剖析異常事件的傳播流程
兩種寫法
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
System.out.println(cause.getMessage());
}
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
//寫法1
ctx.fireChannelRead(cause);
//寫法2
ctx.pipeline().fireExceptionCaught(cause);
}
這兩種寫法我們并不陌生, 可能我們能直接猜到, 第一種寫法是從當前節(jié)點進行傳播, 第二種寫法則從頭結點或者尾節(jié)點進行轉(zhuǎn)播, 那么和傳播inbound事件或outbound事件有什么區(qū)別呢?我們先以第二種寫法為例, 剖析異常事件傳輸?shù)恼麄€流程
DefualtChannelPipeline.fireExceptionCaught
public final ChannelPipeline fireExceptionCaught(Throwable cause) {
AbstractChannelHandlerContext.invokeExceptionCaught(head, cause);
return this;
}
我們看到invokeExceptionCaught傳入了head節(jié)點, 我們可以猜測, 異常事件的傳播是從head節(jié)點開始的
AbstractChannelHandlerContext.invokeExceptionCaught(head, cause)
static void invokeExceptionCaught(final AbstractChannelHandlerContext next, final Throwable cause) {
ObjectUtil.checkNotNull(cause, "cause");
EventExecutor executor = next.executor();
if (executor.inEventLoop()) {
//執(zhí)行下一個節(jié)點的異常方法
next.invokeExceptionCaught(cause);
} else {
try {
executor.execute(new Runnable() {
@Override
public void run() {
next.invokeExceptionCaught(cause);
}
});
} catch (Throwable t) {
//忽略代碼
}
}
}
因為這里是傳入的是head節(jié)點, 所以這里的next指向head節(jié)點。
我們跟到invokeExceptionCaught方法中, 這里其實是headContext的父類AbstractChannelHandlerContext中的方法
AbstractChannelHandlerContext.invokeExceptionCaught(cause)
private void invokeExceptionCaught(final Throwable cause) {
if (invokeHandler()) {
try {
//當前handler調(diào)用exceptionCaught()方法
handler().exceptionCaught(this, cause);
} catch (Throwable error) {
//代碼省略
}
} else {
fireExceptionCaught(cause);
}
}
這里又是我們熟悉的邏輯, 調(diào)用當前handler的exceptionCaught方法, 因為當前handler是head, 所以首先會調(diào)用headContext的exceptionCaught方法
exceptionCaught方法
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
ctx.fireExceptionCaught(cause);
}
這里僅僅是繼續(xù)傳播異常事件, 這時候我們發(fā)現(xiàn), 這個寫法和我們剛才提到傳播異常事件的兩種寫法的第一種寫法一樣
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
//寫法1
ctx.fireChannelRead(cause);
//寫法2
ctx.pipeline().fireExceptionCaught(cause);
}
根據(jù)我們之前的學習, 我們知道第一種寫法是從當前節(jié)點傳播, 而第二種寫法是從頭傳播, 并且要求傳播事件一定要使用第一種寫法, 否則事件到這里會重新從頭傳播進而引發(fā)不可預知錯誤, 這個結論在異常傳播同樣適用, 同學們一定要注意這點
我們繼續(xù)跟fireExceptionCaught方法, 這里會走到AbstractChannelHandlerContex類的fireExceptionCaught方法
AbstractChannelHandlerContex.fireExceptionCaught
public ChannelHandlerContext fireExceptionCaught(final Throwable cause) {
//傳播異常事件的時候, 直接拿了當前節(jié)點的下一個節(jié)點
invokeExceptionCaught(next, cause);
return this;
}
這個時候我們發(fā)現(xiàn), 這里并沒有去獲取下一個的inbound節(jié)點還是outbound節(jié)點, 而是直接通過next拿到下一個節(jié)點, 這就說明在異常事件傳播的過程中是不區(qū)分inbound事件還是outbound事件的, 都是直接從head節(jié)點按照鏈表結構往下傳播
AbstractChannelHandlerContex.invokeExceptionCaught(next, cause)
static void invokeExceptionCaught(final AbstractChannelHandlerContext next, final Throwable cause) {
ObjectUtil.checkNotNull(cause, "cause");
EventExecutor executor = next.executor();
if (executor.inEventLoop()) {
next.invokeExceptionCaught(cause);
} else {
try {
executor.execute(new Runnable() {
@Override
public void run() {
next.invokeExceptionCaught(cause);
}
});
} catch (Throwable t) {
//代碼省略
}
}
}
這里又是我們熟悉的邏輯, 我們知道invokeExceptionCaught中執(zhí)行了next的exceptionCaught, 這里的next, 因為我們是從head節(jié)點開始剖析的, 所以這里很有可能就是用戶自定義的handler, 如果用戶沒有重寫exceptionCaught方法, 則會交給用戶handler的父類處理
我們以ChannelInboundHandlerAdapter為例看它的該方法實現(xiàn)
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
throws Exception {
ctx.fireExceptionCaught(cause);
}
我們看到這里繼續(xù)向下傳播了異常事件
走到這里我們會知道, 如果我們沒有重寫exceptionCaught方法, 異常事件會一直傳播到鏈表的底部, 就是tail節(jié)點
我們跟到TailConext的exceptionCaught方法
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
onUnhandledInboundException(cause);
}
我們看到最終這里釋放了異常對象,以上就是netty中pipeline異常事件分析的詳細內(nèi)容,更多關于netty pipeline異常事件的資料請關注腳本之家其它相關文章!
相關文章
解決IDEA報錯,無效的源發(fā)行版 無效的目標發(fā)行版:22問題
在項目編譯過程中,可能會出現(xiàn)“無效的源發(fā)行版”或“無效的目標發(fā)行版”的報錯信息,原因通常是編譯使用的JDK版本與項目設置的發(fā)布版本不一致,解決這類問題的辦法是統(tǒng)一JDK版本,具體操作為:在IDE的項目設置中(如File->ProjectStructure->ProjectSettings)2024-10-10
Java 的 FileFilter文件過濾與readline讀行操作實例代碼
這篇文章介紹了Java 的 FileFilter文件過濾與readline讀行操作實例代碼,有需要的朋友可以參考一下2013-09-09
mybatis查詢返回Map<String,Object>類型的講解
這篇文章主要介紹了mybatis查詢返回Map<String,Object>類型的講解,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-06-06
Java?SpringBoot項目如何優(yōu)雅的實現(xiàn)操作日志記錄
這篇文章主要介紹了Java?SpringBoot項目如何優(yōu)雅的實現(xiàn)操作日志記錄,文章圍繞主題展開詳細的內(nèi)容介紹,具有一定的參考價值,需要的朋友可以參考一下2022-08-08

