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