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