性能测试中Disruptor框架ExceptionHandler使用分享

在使用Disruptor设计新的性能测试模型的过程中，在使用过程中，偶然发现会有一些异常，然后QPS就会不断下降，直到最后QPS能力降为零。经过查询相关资料后发现了一个小坑：com.lmax.disruptor.ExceptionHandler。

这个接口实现类是处理消费消息的过程中发生的异常，具体的源码位置在com.lmax.disruptor.WorkProcessor#run，有兴趣的可以看看。下面分享一下部分代码：

            catch (final Throwable ex)
            {
                // handle, mark as processed, unless the exception handler threw an exception
                exceptionHandler.handleEventException(ex, nextSequence, event);
                processedSequence = true;
            }

如果大家在使用Disruptor使用默认的方法的话，会使用默认的ExceptionHandler的实现类com.lmax.disruptor.FatalExceptionHandler，它的com.lmax.disruptor.FatalExceptionHandler#handleEventException方法如下：

    @Override
    public void handleEventException(final Throwable ex, final long sequence, final Object event)
    {
        logger.log(Level.SEVERE, "Exception processing: " + sequence + " " + event, ex);

        throw new RuntimeException(ex);
    }

最后还是会抛出一个异常，然后造成com.lmax.disruptor.WorkProcessor执行失败，如果消费消息异常比较多的话，基本上消费线程会很快被干掉，最终导致没有消费线程。

回到实际场景，使用消费线程进行并发请求，在之前的实现中都是直接抛出异常，导致BUG的出现。修复的方法也很简单，要不使用Disruptor提供的几种com.lmax.disruptor.IgnoreExceptionHandler或者org.apache.logging.log4j.core.async.AsyncLoggerDefaultExceptionHandler之类的，基本都是日志打印。不过还是喜欢自己实现，这样方便一些，所以下面是我的解决方案。

try{
    dosomething()
catth(e){

    }

因为随着QPS上升，报错的概率还是挺大的，毕竟是日志流量回放，由于流量文件中部分请求直接回放是会失败的。如果打印日志，即使每秒万分之一的概率，每秒错误QPS就得10+的QPS。不如直接使用专用的日志平台去统计这部分的异常日志。

如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一键三连哦！

最后基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等配套学习资源在下方公众号免费获取~