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()时已经不是我们预期的结果了。这种错误也是比较隐蔽的呢。
