netty中pipeline异常事件分析

 更新时间:2023年04月25日 11:22:27   作者:宽仔的编程之路  
这篇文章主要为大家介绍了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());
}

我们在handlerchannelRead方法中主动抛出异常, 模拟程序中出现异常的场景, 经测试会发现, 程序最终会走到exceptionCaught方法中, 获取异常对象并打印其信息

那么抛出异常之后, 是如何走到exceptionCaught方法的呢?

我们回顾之前小节channelRead事件的传播流程, channelRead方法是在AbstractChannelHandlerContext类的invokeChannelRead方法中被调用

AbstractChannelHandlerContext.invokeChannelRead

private void invokeChannelRead(Object msg) {
    if (invokeHandler()) {
        try {
            //调用了当前handler的channelRead方法, 其实就是head对象调用自身的channelRead方法
            ((ChannelInboundHandler) handler()).channelRead(this, msg);
        } catch (Throwable t) {
            //发生异常的时候在这里捕获异常
            notifyHandlerException(t);
        }
    } else {
        fireChannelRead(msg);
    }
}

这里不难看出, 当调用户自定义的handlerchannelRead方法发生异常之后, 会被捕获, 并调用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调用exceptionCaught()方法
            handler().exceptionCaught(this, cause);
        } catch (Throwable error) {
            //代码省略
        }
    } else {
        fireExceptionCaught(cause);
    }
}

走到这里一切都明白了, 这里调用了当前handlerexceptionCaught方法, 也就是我们重写的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);
}

这两种写法我们并不陌生, 可能我们能直接猜到, 第一种写法是从当前节点进行传播, 第二种写法则从头结点或者尾节点进行转播, 那么和传播inbound事件或outbound事件有什么区别呢?我们先以第二种写法为例, 剖析异常事件传输的整个流程

DefualtChannelPipeline.fireExceptionCaught

public final ChannelPipeline fireExceptionCaught(Throwable cause) {
    AbstractChannelHandlerContext.invokeExceptionCaught(head, cause);
    return this;
}

我们看到invokeExceptionCaught传入了head节点, 我们可以猜测, 异常事件的传播是从head节点开始的

AbstractChannelHandlerContext.invokeExceptionCaught(head, 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) {
            //忽略代码
        }
    }
}

因为这里是传入的是head节点, 所以这里的next指向head节点。

我们跟到invokeExceptionCaught方法中, 这里其实是headContext的父类AbstractChannelHandlerContext中的方法

AbstractChannelHandlerContext.invokeExceptionCaught(cause)

private void invokeExceptionCaught(final Throwable cause) {
    if (invokeHandler()) {
        try {
            //当前handler调用exceptionCaught()方法
            handler().exceptionCaught(this, cause);
        } catch (Throwable error) {
            //代码省略
        }
    } else {
        fireExceptionCaught(cause);
    }
}

这里又是我们熟悉的逻辑, 调用当前handlerexceptionCaught方法, 因为当前handlerhead, 所以首先会调用headContextexceptionCaught方法

exceptionCaught方法

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    ctx.fireExceptionCaught(cause);
}

这里仅仅是继续传播异常事件, 这时候我们发现, 这个写法和我们刚才提到传播异常事件的两种写法的第一种写法一样

@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    //写法1
    ctx.fireChannelRead(cause);
    //写法2
    ctx.pipeline().fireExceptionCaught(cause);
}

根据我们之前的学习, 我们知道第一种写法是从当前节点传播, 而第二种写法是从头传播, 并且要求传播事件一定要使用第一种写法, 否则事件到这里会重新从头传播进而引发不可预知错误, 这个结论在异常传播同样适用, 同学们一定要注意这点

我们继续跟fireExceptionCaught方法, 这里会走到AbstractChannelHandlerContex类的fireExceptionCaught方法

AbstractChannelHandlerContex.fireExceptionCaught

public ChannelHandlerContext fireExceptionCaught(final Throwable cause) {
    //传播异常事件的时候, 直接拿了当前节点的下一个节点
    invokeExceptionCaught(next, cause);
    return this;
}

这个时候我们发现, 这里并没有去获取下一个的inbound节点还是outbound节点, 而是直接通过next拿到下一个节点, 这就说明在异常事件传播的过程中是不区分inbound事件还是outbound事件的, 都是直接从head节点按照链表结构往下传播

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中执行了nextexceptionCaught, 这里的next, 因为我们是从head节点开始剖析的, 所以这里很有可能就是用户自定义的handler, 如果用户没有重写exceptionCaught方法, 则会交给用户handler的父类处理

我们以ChannelInboundHandlerAdapter为例看它的该方法实现

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
        throws Exception {
    ctx.fireExceptionCaught(cause);
}

我们看到这里继续向下传播了异常事件

走到这里我们会知道, 如果我们没有重写exceptionCaught方法, 异常事件会一直传播到链表的底部, 就是tail节点

我们跟到TailConext的exceptionCaught方法

public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
    onUnhandledInboundException(cause);
}

我们看到最终这里释放了异常对象,以上就是netty中pipeline异常事件分析的详细内容,更多关于netty pipeline异常事件的资料请关注脚本之家其它相关文章!

相关文章

  • jdk11 jdk17多版本共存切换方式

    jdk11 jdk17多版本共存切换方式

    这篇文章主要介绍了jdk11 jdk17多版本共存切换方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2024-02-02
  • 解决IDEA报错,无效的源发行版 无效的目标发行版:22问题

    解决IDEA报错,无效的源发行版 无效的目标发行版:22问题

    在项目编译过程中,可能会出现“无效的源发行版”或“无效的目标发行版”的报错信息,原因通常是编译使用的JDK版本与项目设置的发布版本不一致,解决这类问题的办法是统一JDK版本,具体操作为:在IDE的项目设置中(如File->ProjectStructure->ProjectSettings)
    2024-10-10
  • Spring Cloud Zuul的重试配置详解

    Spring Cloud Zuul的重试配置详解

    这篇文章主要介绍了Spring Cloud Zuul的重试配置详解,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧
    2018-04-04
  • Java 的 FileFilter文件过滤与readline读行操作实例代码

    Java 的 FileFilter文件过滤与readline读行操作实例代码

    这篇文章介绍了Java 的 FileFilter文件过滤与readline读行操作实例代码,有需要的朋友可以参考一下
    2013-09-09
  • mybatis查询返回Map<String,Object>类型的讲解

    mybatis查询返回Map<String,Object>类型的讲解

    这篇文章主要介绍了mybatis查询返回Map<String,Object>类型的讲解,具有很好的参考价值,希望对大家有所帮助。如有错误或未考虑完全的地方,望不吝赐教
    2022-06-06
  • Java基于Graphics2D实现海报制作

    Java基于Graphics2D实现海报制作

    这篇文章主要为大家详细介绍了Java如何基于Graphics2D实现海报制作,并且支持自定义颜色,背景,logo,贴图,感兴趣的小伙伴可以了解一下
    2024-04-04
  • 深入理解什么是Mybatis懒加载(延迟加载)

    深入理解什么是Mybatis懒加载(延迟加载)

    这篇文章主要介绍了深入理解什么是Mybatis懒加载(延迟加载),mybatis的懒加载,也称为延迟加载,是指在进行关联查询的时候,按照设置延迟规则推迟对关联对象的select查询,延迟加载可以有效的减少数据库压力,需要的朋友可以参考下
    2023-10-10
  • Java SpringBoot项目如何优雅的实现操作日志记录

    Java SpringBoot项目如何优雅的实现操作日志记录

    这篇文章主要介绍了Java SpringBoot项目如何优雅的实现操作日志记录,文章围绕主题展开详细的内容介绍,具有一定的参考价值,需要的朋友可以参考一下
    2022-08-08
  • 实例解析Java中的构造器初始化

    实例解析Java中的构造器初始化

    这篇文章主要通过实例解析Java中的构造器初始化,代码很简单,叙述很明确,需要的朋友可以了解下。
    2017-09-09
  • java实现动态验证码

    java实现动态验证码

    这篇文章主要为大家详细介绍了java实现动态验证码,文中示例代码介绍的非常详细,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
    2021-03-03

最新评论