Dubbo的filter中使用ThreadLocal引发的坑

在filter中使用ThreadLocal要特别注意一些问题，首先ThreadLocal是跟着线程走的，而不管是dubbo或者其他的rpc框架或者Springmvc都有个特点：使用的是线程池模型，当线程执行任务结束之后会回到线程池，这时如果在回到线程池之前ThreadLocal没有被清理，当下一次请求拿到这个线程的时候还能读取到之前没有被清理的ThreadLocal的数据，这样显然不是我们想要的结果了。
处理方式以dubbo的filter为例：

//在服务端的filter中invoker.invoke(invocation)执行后清除ThreadLocal变量
invoker.invoke(invocation);
//TODO 此处清理ThreadLocal的信息

看着是不是感觉没啥问题了？其实还有坑在里面，当服务中出现内部调用的时候，如aaaService里面调用bbbService，而aaaService和bbbService都属于同一个应用的时候，他们的调用不会走dubbo协议，而是直接走内部调用，但是会把filter走一遍，这时候因为不管调用aaaService还是bbbService都是同一个线程在执行，filter走一遍之后ThreadLocal被清理了，这种情况下并不是我们想要的了。。因为后续的逻辑里可能我们还需要用到这个ThreadLocal，所以我们在此加入一个判断，用于判断是否为内部调用。此处我已经找到了对应的处理方式。代码如下

//在服务端的filter中invoker.invoke(invocation)执行后清除ThreadLocal变量
invoker.invoke(invocation);
// injvm是dubbo的内部协议，内部调用伪协议，我们只有不等于这个协议的时候才需要清理ThreadLocal信息
if(!"injvm".equals(invoker.getUrl().getProtocol())){
	//TODO 此处清理ThreadLocal的信息
}