显式传参 vs. 请求上下文

1.背景

比如有一个HSF服务

class OneHsfService{
    void dealHSFService(RequestParam requestParam);
}

它调用了fun1()，fun1()又调用了fun2()，…,调用关系见下

void dealHSFService(requestParam)–调用–>
void fun1(param1,param2)–调用–>
void fun2(param1,param2)–调用–>
void fun3(param1,param2)

而有天接到了一个新的需求，需要在fun3(){}中用到requestParam这个参数，而这个参数没有一步步传下来，该怎么办？
这种情况，相信大家开发中并不少遇到。

2.显式传参

传统的方法，加个参数一步步传下来，解决起来最直接。

2.1 缺点

但不优雅之处为：

• 其他同学可能在其他分支上写了大量依赖fun1()、fun2()的代码，甚至是修改了它们的实现。改了签名很容易有大量报错和冲突。
• 每次发现下游方法缺参数就加形参，慢慢地函数签名会很难看。

3.请求上下文

那么另一种解决办法就是构造并使用请求上下文，即RequestContext。
web容器，在收到一个请求后，一般都会新开一个线程来回调你的方法，进行业务处理。此例中，就对应着OneHsfService.dealHSFService()被调用。
那我们能不能把原始的requestParam同当前线程绑定起来，直接用一个简单的静态方法拿到它呢？
可以。ThreadLocal类可以为我所用。它的特殊之处就是，在不同的线程中调用它的方法，返回结果是不一样的。之所以这么神奇，是因为背后调用了Thread.currentThread()方法。
那么写出来的代码就是这样的。

class OneHsfService{
    public static final ThreadLocal<RequestParam> threadLocal = new ThreadLocal<>();
    void dealHSFService(RequestParam requestParam){
        threadLocal.set(requestParam);
    }
}

我们还可以升级一下：

class OneHsfService{
    //这样，fun1()中有什么中间结果，也可以塞进去，让fun3()感知到
    public static final ThreadLocal<Map<String,?>> threadLocal = new ThreadLocal<>();
    void dealHSFService(RequestParam requestParam){
        if(threadLocal.get()==null){
            Map<String,?> map=new HashMap<>();
            threadLocal.set(map);
        }
        threadLocal.get().put("requestParam",requestParam);
    }
}

3.1缺点

凡事总有利弊。如果我们想把一个任务分解为多个子任务task1,task2，借助Semaphore或CountDownLatch使用线程池ThreadPoolExecutor来并行处理的时候，这个方法就行不通了。因为它会从池子中挑一个thread(记为thread0)来执行你的task，那么在thread0中执行ThreadLocal.get()时已经不是我们预期的结果了。这种错误也是比较隐蔽的呢。