文章>又踩到Dubbo的坑,但是这次我笑不出来>

又踩到Dubbo的坑,但是这次我笑不出来

肥朝
java
dubbo
3天前

前言

直入主题,线上应用发现,偶发性出现如下异常日志。

image.png

image.png

当然由于线上具体异常包含信息量过大,秉承让肥朝的粉丝没有难调试的代码的原则,我特意抽取了一个复现的demo放在了git,让你不在现场,一样享受到排查的快乐!但是最近,太多假粉伸手党拿到地址就跑,因此我把地址藏在本文某个角落,因此认真看文的才能找到!(重点)

由于工作性质的原因,上班时间根本抽不出时间做其他事,修bug,都只能下班时间来做,因此周六就到公司搬砖了。

image.png

什么是ConcurrentModificationException?

中文意思就是,并发修改异常。也就是我们常说的fail-fast(快速失败)。当然肥朝更认为,快速失败是一种思想,比如Spring会在启动的时候做大量的检查,什么bean找不到,依赖注入错误等等,都会把一些显而易见的错误检查出来,防止在项目跑着跑着期间再失败,也就是提前检查。无论是业务开发,还是基础组件开发,亦或是生活中,这个思想都是可以用到的。

那么,言归正传,这个异常到底什么意思啊。简单说就是,当一个集合在遍历的时候,他的元素也正在被修改。刚学java那会,我们边遍历边删除就会出现这个异常。ConcurrentModificationException的原理这些网上太多,肥朝就暂且不提。那么我们来看下异常栈。

image.png

image.png

好了,我们已经找到了RpcContext.getContext().getObjectAttachments()正在遍历。那么,只要找到谁在修改他就行了啊,就这?

image.png

难点分析

很明显,这里面并不存在遍历的同时修改元素,Dubbo的代码还不至于有这个明显的bug。出现ConcurrentModificationException,就有可能是,A线程在遍历,B线程在修改。

但是肥朝,你说了这么多,我还是没发现这个问题有什么难的啊!

这个问题难点主要在于,在Dubbo里面,RpcContext是对应一个线程的,你可以简单理解为ThreadLocal的增强版。也就是说,A线程拿出来的,和B线程拿出来的RpcContext都不是同一个,何来并发修改同一个之说?当然官方文档给了我一个启示。

image.png

会不会有同学在线程开启前拿到RpcContext,然后在新线程中,做set操作(图中的get操作是没有问题的)。

于是,似乎豁然开朗的我,顺着这条线索,周六加了一天班,把代码翻了个遍,最后发现没有找到。

索然无味还是柳暗花明?

并发这东西,要么不出问题,一旦出问题都是很难找。观察了线上日志,重现概率很小,就一小段日志,并且业务方很忙,也没时间配合你查问题。于是只能顺着源码,把Dubbo的整个请求到响应的过程在脑海中快速过几遍,看看哪个环节有可能出问题,做了无数的假设。随着一次次的假设失败,在即将身体索然无味之际,还真发现了一些蛛丝马迹!(注意,本文所用到的,都是dubbo2.7.6)

我们先来看一下官方文档对RpcContext的介绍

image.png

好了,那么我问你,下面这段代码,love能输出什么?

@Service
public class AHelloServiceImpl implements AHelloService {

    @Reference
    private BHelloService bHelloService;

    @Override
    public String sayHello() throws Exception{

        RpcContext.getContext().setAttachment("我最爱的人是?","肥朝");
        bHelloService.sayHello();
        String love = RpcContext.getContext().getAttachment("我最爱的人是?");
        System.out.println("this is: " + love);
        Thread.sleep(10L);

        bHelloService.sayHello();

        return "欢迎关注微信公众号:肥朝";
    }
}

我在图都圈得这么明显了,看得懂中文都知道,发起一次远程调用后,参数会被清空,下面肯定get不到的啦。但是其实是get得到的,不要问肥朝为什么都知道图是有问题的,还特意圈起来骗你,我只想让你知道社会险恶。

源码细节

阅读过源码,和对源码有细节深入思考,效果是很大不一样的。

我们来看一下源码就知道了。文中说的会清除,对应的代码是怎么样的呢?

image.png

image.png

如果作为正常的客户端调用,那么,在调用后确实是会删除的。但是如果你对源码细节足够熟悉你就会发现,在org.apache.dubbo.rpc.filter.ContextFilter这个类中。

image.png

image.png

你不看代码直接听我说也行,这几段代码的意思是,在一个提供者的方法中,canRemove会设置为false的,所以,他们在这个方法体远程调用中,是没办法清空RpcContext的,需要在整体调用完才会清空。

我们再回顾一下案发现场

@Override
public String sayHello() throws Exception{

    bHelloService.sayHello();
    Thread.sleep(10L);
    bHelloService.sayHello();

    return "欢迎关注微信公众号:肥朝";
}

从目前得到的信息很明显知道,第一次远程调用,和第二次远程调用,用的是同一个RpcContext,并且,在第二次远程调用的时候。这个RpcContext的内容,给人动了手脚了。

那么,究竟是何人所为!我们随着镜头,再次深入源码!既然是RpcContext给人搞了,那么我们就从这里顺藤摸瓜,这里先省略肥朝的内心戏,我们来看重点。在RpcContext中发现一段可疑片段

public static void restoreContext(RpcContext oldContext) {
    LOCAL.set(oldContext);
}

接着继续顺丰摸瓜,发现调用这段代码的逻辑是

/**
 * tmp context to use when the thread switch to Dubbo thread.
 */
private RpcContext tmpContext;

private RpcContext tmpServerContext;
private BiConsumer<Result, Throwable> beforeContext = (appResponse, t) -> {
    tmpContext = RpcContext.getContext();
    tmpServerContext = RpcContext.getServerContext();
    RpcContext.restoreContext(storedContext);
    RpcContext.restoreServerContext(storedServerContext);
};

private BiConsumer<Result, Throwable> afterContext = (appResponse, t) -> {
    RpcContext.restoreContext(tmpContext);
    RpcContext.restoreServerContext(tmpServerContext);
};
public Result whenCompleteWithContext(BiConsumer<Result, Throwable> fn) {
    this.responseFuture = this.responseFuture.whenComplete((v, t) -> {
        beforeContext.accept(v, t);
        fn.accept(v, t);
        afterContext.accept(v, t);
    });
    return this;
}
@Override
public Result invoke(Invocation invocation) throws RpcException {
    Result asyncResult;
    try {
        interceptor.before(next, invocation);
        asyncResult = interceptor.intercept(next, invocation);
    } catch (Exception e) {
        // onError callback
        if (interceptor instanceof ClusterInterceptor.Listener) {
            ClusterInterceptor.Listener listener = (ClusterInterceptor.Listener) interceptor;
            listener.onError(e, clusterInvoker, invocation);
        }
        throw e;
    } finally {
        interceptor.after(next, invocation);
    }
    return asyncResult.whenCompleteWithContext((r, t) -> {
        // onResponse callback
        if (interceptor instanceof ClusterInterceptor.Listener) {
            ClusterInterceptor.Listener listener = (ClusterInterceptor.Listener) interceptor;
            if (t == null) {
                listener.onMessage(r, clusterInvoker, invocation);
            } else {
                listener.onError(t, clusterInvoker, invocation);
            }
        }
    });
}

看不懂代码不要怕,肥朝大白话解释一下。你就想象一个Dubbo异步场景,Dubbo异步回调结果的时候,是会开启一个新的线程,那么,这个回调就和当初请求不在一个线程里面了,因此这个回调线程是拿不到当初请求的RpcContext。但是我们清空RpcContext是需要在一次请求结束的时候,也就是说,虽然异步回调是另外一个线程了,但是我们仍然需要拿到当初请求时候的RpcContext来走Filter,做清空等操作。上面那段代码就是做,切换线程怎么拿回之前的RpcContext

听完上面的分析,你是不是明白了点啥?新线程,还能拿到旧的RpcContext。那么,有这么一个场景,我们在通过提供者方法中,发起两个异步请求,第一个请求走FilteronResponse(响应结果)的时候,我们如果在FilterRpcContext.getContext().setAttachment操作,第二个请求又正好发起,而发起又会经历putAll这步骤,就会出现这个并发修改异常。于是乎,真相大白!

拓展性思考

真相大白就结束了?熟悉肥朝的粉丝都知道,我们遇到问题,要尽量压榨问题的全部价值!比如,你说不要在拦截器中onResponse方法中用RpcContext.getContext().setAttachment这样的操作,但是我们确实有类似需要,那到底要怎么写代码又不说,你这样叫我怎么给你转发文章!

image.png

我们要知道怎么正确写代码,那直接去抄Dubbo其他拦截器的代码不就知道了?比如

@Activate(group = PROVIDER, order = -10000)
public class ContextFilter implements Filter, Filter.Listener {


    @Override
    public void onResponse(Result appResponse, Invoker<?> invoker, Invocation invocation) {
        // pass attachments to result
        appResponse.addObjectAttachments(RpcContext.getServerContext().getObjectAttachments());
    }

}

我们很明显看到,你熟悉一下appResponse的api和他的作用,就很容易知道,有类似需求,代码应该怎么写了。我光告诉你怎么写代码没用啊,我要告诉你,遇到问题,怎么去抄正确代码,让你任何时候,都有得cao!

794 阅读
请先登录,再评论

评论列表

流年_68852113小时前

dubbo还是主流吗?