Netty分布式pipeline管道異常傳播事件源碼解析
講完了inbound事件和outbound事件的傳輸流程, 這一小節(jié)剖析異常事件的傳輸流程
傳播異常事件
簡單的異常處理的場景
@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方法中主動(dòng)拋出異常, 模擬程序中出現(xiàn)異常的場景, 經(jīng)測試會(huì)發(fā)現(xiàn), 程序最終會(huì)走到exceptionCaught方法中, 獲取異常對象并打印其信息
那么拋出異常之后, 是如何走到exceptionCaught方法的呢?
我們回顧之前小節(jié)channelRead事件的傳播流程, channelRead方法是在AbstractChannelHandlerContext類的invokeChannelRead方法中被調(diào)用
我們跟到invokeChannelRead這個(gè)方法
private void invokeChannelRead(Object msg) {
if (invokeHandler()) {
try {
//調(diào)用了當(dāng)前handler的channelRead方法, 其實(shí)就是head對象調(diào)用自身的channelRead方法
((ChannelInboundHandler) handler()).channelRead(this, msg);
} catch (Throwable t) {
//發(fā)生異常的時(shí)候在這里捕獲異常
notifyHandlerException(t);
}
} else {
fireChannelRead(msg);
}
}這里不難看出, 當(dāng)調(diào)用戶自定義的handler的channelRead方法發(fā)生異常之后, 會(huì)被捕獲, 并調(diào)用notifyHandlerException方法, 并傳入異常對象, 也就是我們示例中拋出的異常
我們跟到fireChannelRead方法中:
private void notifyHandlerException(Throwable cause) {
//代碼省略
invokeExceptionCaught(cause);
}再繼續(xù)跟到invokeExceptionCaught方法中:
private void invokeExceptionCaught(final Throwable cause) {
if (invokeHandler()) {
try {
//當(dāng)前handler調(diào)用exceptionCaught()方法
handler().exceptionCaught(this, cause);
} catch (Throwable error) {
//代碼省略
}
} else {
fireExceptionCaught(cause);
}
}走到這里一切都明白了, 這里調(diào)用了當(dāng)前handler的exceptionCaught方法, 也就是我們重寫的exceptionCaught方法
知道了為什么會(huì)走到exceptionCaught方法之后, 我們再進(jìn)行剖析異常事件的傳播流程
我還是通過兩種寫法來進(jìn)行剖析
@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);
}這兩種寫法我們并不陌生, 可能我們能直接猜到, 第一種寫法是從當(dāng)前節(jié)點(diǎn)進(jìn)行傳播, 第二種寫法則從頭結(jié)點(diǎn)或者尾節(jié)點(diǎn)進(jìn)行轉(zhuǎn)播, 那么和傳播inbound事件或outbound事件有什么區(qū)別呢?我們先以第二種寫法為例, 剖析異常事件傳輸?shù)恼麄€(gè)流程
跟到DefualtChannelPipeline的fireExceptionCaught方法中:
public final ChannelPipeline fireExceptionCaught(Throwable cause) {
AbstractChannelHandlerContext.invokeExceptionCaught(head, cause);
return this;
}我們看到invokeExceptionCaught傳入了head節(jié)點(diǎn), 我們可以猜測, 異常事件的傳播是從head節(jié)點(diǎn)開始的
跟進(jìn)invokeExceptionCaught方法
static void invokeExceptionCaught(final AbstractChannelHandlerContext next, final Throwable cause) {
ObjectUtil.checkNotNull(cause, "cause");
EventExecutor executor = next.executor();
if (executor.inEventLoop()) {
//執(zhí)行下一個(gè)節(jié)點(diǎn)的異常方法
next.invokeExceptionCaught(cause);
} else {
try {
executor.execute(new Runnable() {
@Override
public void run() {
next.invokeExceptionCaught(cause);
}
});
} catch (Throwable t) {
//忽略代碼
}
}
}因?yàn)檫@里是傳入的是head節(jié)點(diǎn), 所以這里的next指向head節(jié)點(diǎn)
我們跟到invokeExceptionCaught方法中, 這里其實(shí)是headContext的父類AbstractChannelHandlerContext中的方法:
private void invokeExceptionCaught(final Throwable cause) {
if (invokeHandler()) {
try {
//當(dāng)前handler調(diào)用exceptionCaught()方法
handler().exceptionCaught(this, cause);
} catch (Throwable error) {
//代碼省略
}
} else {
fireExceptionCaught(cause);
}
}這里又是我們熟悉的邏輯, 調(diào)用當(dāng)前handler的exceptionCaught方法, 因?yàn)楫?dāng)前handler是head, 所以首先會(huì)調(diào)用headContext的exceptionCaught方法
跟進(jìn)exceptionCaught方法:
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
ctx.fireExceptionCaught(cause);
}這里僅僅是繼續(xù)傳播異常事件, 這時(shí)候我們發(fā)現(xiàn), 這個(gè)寫法和我們剛才提到傳播異常事件的兩種寫法的第一種寫法一樣:
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
//寫法1
ctx.fireChannelRead(cause);
//寫法2
ctx.pipeline().fireExceptionCaught(cause);
}根據(jù)我們之前的學(xué)習(xí), 我們知道第一種寫法是從當(dāng)前節(jié)點(diǎn)傳播, 而第二種寫法是從頭傳播, 并且要求傳播事件一定要使用第一種寫法, 否則事件到這里會(huì)重新從頭傳播進(jìn)而引發(fā)不可預(yù)知錯(cuò)誤, 這個(gè)結(jié)論在異常傳播同樣適用, 同學(xué)們一定要注意這點(diǎn)
我們繼續(xù)跟fireExceptionCaught方法, 這里會(huì)走到AbstractChannelHandlerContex類的fireExceptionCaught方法:
public ChannelHandlerContext fireExceptionCaught(final Throwable cause) {
//傳播異常事件的時(shí)候, 直接拿了當(dāng)前節(jié)點(diǎn)的下一個(gè)節(jié)點(diǎn)
invokeExceptionCaught(next, cause);
return this;
}這個(gè)時(shí)候我們發(fā)現(xiàn), 這里并沒有去獲取下一個(gè)的inbound節(jié)點(diǎn)還是outbound節(jié)點(diǎn), 而是直接通過next拿到下一個(gè)節(jié)點(diǎn), 這就說明在異常事件傳播的過程中是不區(qū)分inbound事件還是outbound事件的, 都是直接從head節(jié)點(diǎn)按照鏈表結(jié)構(gòu)往下傳播,
跟到invokeExceptionCaught方法中
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, 因?yàn)槲覀兪菑膆ead節(jié)點(diǎn)開始剖析的, 所以這里很有可能就是用戶自定義的handler, 如果用戶沒有重寫exceptionCaught方法, 則會(huì)交給用戶handler的父類處理
我們以ChannelInboundHandlerAdapter為例看它的該方法實(shí)現(xiàn):
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
throws Exception {
ctx.fireExceptionCaught(cause);
}我們看到這里繼續(xù)向下傳播了異常事件
走到這里我們會(huì)知道, 如果我們沒有重寫exceptionCaught方法, 異常事件會(huì)一直傳播到鏈表的底部, 就是tail節(jié)點(diǎn)
我們跟到TailConext的exceptionCaught方法:
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
onUnhandledInboundException(cause);
}我們看到最終這里釋放了異常對象
以上就是有關(guān)異常事件的傳播，更多關(guān)于Netty分布式pipeline管道異常傳播的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
這篇文章主要介紹了Java pdf和jpg互轉(zhuǎn)案例，具有很好的參考價(jià)值，希望對大家有所幫助。一起跟隨小編過來看看吧2020-09-09
Java實(shí)現(xiàn)超簡單抖音去水印的示例詳解
抖音去水印方法很簡單，以前一直沒有去研究，以為搞個(gè)去水印還要用到算法去除，直到動(dòng)手的時(shí)候才發(fā)現(xiàn)這么簡單，不用編程基礎(chǔ)都能做。所以本文將介紹一個(gè)超簡單抖音視頻去水印方法，需要的可以參考一下2022-03-03
Java8 Supplier接口和Consumer接口原理解析
這篇文章主要介紹了Java8 Supplier接口和Consumer接口原理解析,文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-04-04
SpringCloud Alibaba 基本開發(fā)框架搭建過程
這篇文章主要介紹了SpringCloud Alibaba 基本開發(fā)框架搭建過程,開發(fā)工具選用的idea，本文通過圖文實(shí)例相結(jié)合給大家分享搭建全過程，需要的朋友可以參考下2021-06-06
這篇文章主要介紹了mybatisplus中的xml對象參數(shù)傳遞問題，具有很好的參考價(jià)值，希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2022-11-11
這篇文章介紹Java中的函數(shù)式編程，函數(shù)式編程是一種編程范式，其中程序是通過應(yīng)用和組合函數(shù)來構(gòu)造的。它是一種聲明式編程范式，其中函數(shù)定義是表達(dá)式樹，每個(gè)表達(dá)式樹返回一個(gè)值，而不是一系列改變程序狀態(tài)的命令語句，具體情況請看下文，希望對你有所幫助2021-10-10
SpringBoot關(guān)于List集合的校驗(yàn)方式
這篇文章主要介紹了SpringBoot關(guān)于List集合的校驗(yàn)方式,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-07-07
SpringCloud開啟session共享并存儲(chǔ)到Redis的實(shí)現(xiàn)
這篇文章主要介紹了SpringCloud開啟session共享并存儲(chǔ)到Redis的實(shí)現(xiàn)方式，具有很好的參考價(jià)值，希望對大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2023-02-02
springboot3+r2dbc響應(yīng)式編程實(shí)踐
本文主要介紹了springboot3+r2dbc響應(yīng)式編程實(shí)踐，文中通過示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2022-02-02
SpringBoot自定義starter啟動(dòng)器的實(shí)現(xiàn)思路
這篇文章主要介紹了SpringBoot如何自定義starter啟動(dòng)器,通過starter的自定義過程，能夠加深大家對SpringBoot自動(dòng)配置原理的理解，需要的朋友可以參考下2022-10-10