写作目的
以前的工作经历中，笔者本人有深度使用ThreadLocal的经验，它在合适的场景下，是非常好用的一个工具，因此打算分享一二，为各位看官们实际编码过程中提供多一种选择，促进大家共同进步
场景
先举两个大家熟悉的、Spring中用到的场景
场景一
在Spring管理的Singleton Bean中，如果期望调用同一个类里被事务注解的方法(m1调用m2)，且希望事务能生效，可以考虑的实现如下：
@Service
public class FooService {
public void m1() {
// 拿到FooService的代理对象
FooService self = (FooService)AopContext.currentProxy();
// 通过代理对象调用m2方法，事务切面就能生效
self.m2();
}
@Transactional
public void m2() {
// save to db;
}
}
之所以要通过代理对象去调用，是因为若在m1中使用原始对象(this)，不会进入代理逻辑，因此切面逻辑（事务）是不会生效的。所以问题就转变成了：在一个方法执行过程中，如何拿到当前方法所属对象的代理对象？
-
在FooService中直接注入自己
-
通过调用AopContext.currentProxy()
为与本文扣题，我们的示例采用的是方式2。那么接下来需要探寻的是，为什么AopContext.currentProxy()就能拿到代理对象呢？
- 外部方法调用FooService#m1的时候，进入了代理逻辑(org.springframework.aop.framework.CglibAopProxy.DynamicAdvisedInterceptor#intercept)，与此同时，会把代理对象放到AopContext
- AopContext#setCurrentProxy会将代理对象(proxy)放到
currentProxy中，而currentProxy是一个ThreadLocal
-
在m1方法中执行
FooService self = (FooService)AopContext.currentProxy();，本质就是从当前线程的ThreadLocal中取出上边1、2步放入的代理对象，接下来就可以用代理对象"搞事情" -
代理对象切面逻辑结束后，用oldProxy将AopContext还原
如此这般，通过预先将代理对象放入当前线程的ThreadLocal的方式，就可以做到在接下来的流程中，在任意位置都可以很方便获取到该代理对象，而不需要通过方法参数一层层透传下去
在理解上，可以将ThreadLocal理解成为当前线程装东西的"篮子"：在线程执行任务时，可以在某节点(方法)将一些东西放进"篮子"，并可在后续的任意节点(方法)从"篮子"取出之前放入的东西
场景二
大家可能会经常使用到Spring @Transactional事务注解，若不理解原理，可能容易踩坑。一个基本共识是：事务由连接管理，一个事务只属于一个连接，若要使得事务生效(相关DB操作同时提交，同时回滚)，必须确保是同一个连接
那么就会有如下场景：
@Service
public class FooService {
@Resource
private BarService barService;
@Transactional
public void foo() {
barService.bar();
// save foo
// ...
}
}
@Service
public class BarService {
@Transactional
public void bar() {
// save bar
}
}
FooService#foo调用BarService#bar进行关于Bar的数据库操作，之后进行Foo的数据库操作，由于方法foo与方法bar都被@Transactional注解，可以确保事务操作的同时提交或同时回滚。**“确保事务操作的同时提交或同时回滚”**是我们在大量的编程经验中可以轻易得出的结论，如果追究根因，其实就是共识：这两个操作处于同一个事务当中，都由同一个连接里的事务进行管理。因此，重点是需要确保"同一个事务"以及"同一个连接"。"同一个事务"是如何实现的，请参考org.springframework.transaction.support.AbstractPlatformTransactionManager#handleExistingTransaction并理解事务的传播属性(不是本文重点，略过)。
那么问题就来了："同一个连接"又是如何实现的呢？代码跑在不同类以及不同方法上，Spring如何做到前后两次获取的是同一个连接？如果看官们理解了场景一，相信此处应该有了结论 -> ThreadLocal
-
外部调用
FooService#foo第一次开启事务的时候，将从连接池中取出一个连接，并将连接放到 ConnectionHolder 中，然后将ConnectionHolder绑定到当前线程// org.springframework.jdbc.datasource.DataSourceTransactionManager#doBegin protected void doBegin(Object transaction, TransactionDefinition definition) { DataSourceTransactionObject txObject = (DataSourceTransactionObject) transaction; Connection con = null; try { if (!txObject.hasConnectionHolder() || txObject.getConnectionHolder().isSynchronizedWithTransaction()) { // 从连接池中取出连接，并将连接放到 ConnectionHolder 中 Connection newCon = this.dataSource.getConnection(); // ...(省略) txObject.setConnectionHolder(new ConnectionHolder(newCon), true); } // ...(省略) // Bind the connection holder to the thread. // 将 ConnectionHolder 绑定到当前线程 if (txObject.isNewConnectionHolder()) { TransactionSynchronizationManager.bindResource(getDataSource(), txObject.getConnectionHolder()); } } // ...(省略) }将value(ConnectionHolder)放到map之后，再放到当前线程的ThreadLocal中，以实现与当前线程的绑定
// org.springframework.transaction.support.TransactionSynchronizationManager#bindResource public static void bindResource(Object key, Object value) throws IllegalStateException { Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key); // 忽略 // resources 是ThreadLocal类型的成员变量 Map<Object, Object> map = resources.get(); // set ThreadLocal Map if none found if (map == null) { map = new HashMap<Object, Object>(); resources.set(map); } // 将value(ConnectionHolder)放到map之后，再放到当前线程的ThreadLocal中，以实现与当前线程的绑定 Object oldValue = map.put(actualKey, value); // ...(省略) } -
FooService#foo调用BarService#bar将触发第二次开启事务，发现传播属性为TransactionDefinition.PROPAGATION_REQUIRED（默认值），会将第二次事务直接"融入"第一次事务，能实现的关键点在于前后两次操作使用同一个连接。如下，是从resources(ThreadLocal)中取出map，并取出第1步中放入的ConnectionHolder，因此就可以确保拿到同一个连接// org.springframework.transaction.support.TransactionSynchronizationManager#getResource public static Object getResource(Object key) { Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary(key); return doGetResource(actualKey); } private static Object doGetResource(Object actualKey) { // resources 是ThreadLocal类型的成员变量 // 从ThreadLocal中取到第1步中放入的ConnectionHolder Map<Object, Object> map = resources.get(); if (map == null) { return null; } Object value = map.get(actualKey); // ...(省略) return value; }
实战
以上使用ThreadLocal的场景，都是框架里提供的，是否业务开发中就用不到了呢？非也，业务开发中如果运用妥当，同样能省掉很多事，实现精简代码的目的。笔者同样举两个业务开发用到的场景，以供大家开阔思路
场景一
该场景比较普遍，几乎所有公司都用的上，因与业务无关，首先介绍，帮助没有使用过ThreadLocal的看官们找找感觉
所有公司所有业务都会有用户体系，进行业务操作都需要登录、鉴权，以识别某用户是否有操作某项资源的权限，因此基本上很多业务都需要拿到当前请求的用户信息
一种可以考虑的方式是：每次请求到来时，可否在入口中统一鉴权，然后将鉴权之后的用户信息记录下来，接下来但凡有业务要用到，可以直接从保存的地方获取到用户信息，不用再一次鉴权，省去一次次的计算消耗；待请求结束后，就将用户信息销毁
- 注册一个
HandlerInterceptor或Filter，用于在入口处拦截请求，并对当前请求进行鉴权，获取用户信息，放入UserHolder中，并在请求结束的时候清理掉该用户信息(注：请求结束后清理用户信息很重要，避免内存泄露)
public class LoginCheckInterceptor extends HandlerInterceptorAdapter {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler)
throws Exception {
// 鉴权(获取用户信息)
User user = xxx(request);
if (user != null) {
// 放到UserHolder这个容器(Holder)中
UserHolder.putUser(user);
return true;
}
// 鉴权(获取用户信息)失败，则直接拦截
return false;
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
// 请求结束后，清理掉用户信息(画重点：很重要)
UserHolder.clear();
}
}
UserHolder是一个容器，包装ThreadLocal，放置当次请求中用户的信息，如下示：
public class UserHolder {
// 内部维护一个ThreadLocal成员变量
private static ThreadLocal<User> tl = new ThreadLocal<>();
public static void putUser(User user) {
tl.set(user);
}
public static User getUser() {
return tl.get();
}
public static Long getUid() {
return Optional.ofNullable(tl.get()).map(User::getId).orElse(null);
}
public static void clear() {
tl.remove();
}
}
- 在需要使用的地方，例如XXXService，直接在任意方法内部调用
UserHolder#getUser即可获取到当前用户的完整信息。如此这般，就不需要将User从Controller层层传递到Service里的某个小方法，避免了"依赖污染"，对于[多层次]的业务代码组织尤为有效，省去了多次参数传递的烦恼
反例：明明request、xxx, yyy 都不直接依赖User，只是在最后一层zzz用到User，却不得不将用户信息层层传递，造成"依赖污染"
// Service接口方法
public void request(User user) {
xxx(user);
}
private void xxx(User user) {
yyy(user);
}
private void yyy(User user) {
zzz(user);
}
private void zzz(User user) {
String email = user.getEmail();
}
使用ThreadLocal后，简化如下，只有zzz需要用到User信息，那就在zzz中直接获取用户信息，并进行业务逻辑
public void request() {
xxx();
}
public void xxx() {
yyy();
}
private void yyy() {
zzz();
}
private void zzz() {
User user = UserHolder.getUser();
String email = user.getEmail();
}
看官们可能会有疑问：我们的后端服务并不需要鉴权，而是由前边的网关做好了鉴权，然后通过某些方式(如请求头)携带给后端服务，那还能使用吗？答案是肯定的，请看场景二
场景二
笔者以前从事广告相关业务，广告投放逻辑里需要识别是哪个用户，当前手机型号、品牌是什么，操作系统版本号、APP版本号、设备尺寸等等总共几十项信息，这些信息都是由请求头携带到后端服务，而广告投放逻辑里面不同的模块会使用不同头字段来做相应的业务逻辑
在实现上，同样是在入口处，通过自定义拦截器或过滤器的方式拦截请求，获取到所有的请求头信息，封装进HeaderHolder，以便在不同模块间方便获取请求头信息做业务逻辑。可以想像，一个业务有不同的模块，不同模块又分为不同的业务抽象层次，而不同层次代码中可能需要使用到请求头信息都不一样，如果是通过函数传参的方式将Header层层传递，代码将变得多么糟糕
一般化推论
诚然，使用ThreadLocal会为我们的编程带来许多好处，同样的也为代码的管理，依赖的梳理带来了一些挑战。因此真正要把ThreadLocal用好并不简单，并非任何场景都可以使用的，用好是一个亮点，用不好就是坑：这也是所有技术选型所要面临的问题，技术本身无所谓好坏，没有任何一种技术能在所有方面碾压同类的竞品技术，否则一定能将竞品取代而不需要面临trade off，抛开业务场景谈技术(架构)就是耍流氓
结合笔者本人的实际使用经验，将使用ThreadLocal的场景总结为一句话：在尽可能早的时机将一些大多数后续流程要使用的只读信息封装到ThreadLocal里，供后续流程任意取用
- 尽可能早的时机：好事须趁早，越早生成，就越早能使用，可扩展性越高，最好是在与业务无关的入口处
- 大多数： 有选择性地将大多数后续都需要用到的信息放到ThreadLocal里，而不是所有信息无脑放入
- 只读信息： 封装的信息最好"Read Only"，意味着一旦生成，将不可再更改，整个后续流程都只能读取，该要求是为了让代码更可控，倘若信息可以修改，就有可能导致不同层次的代码产生间接依赖(如下层依赖上层)，系统行为将不可控
总结
本文从Spring使用ThreadLocal的案例为切入点，介绍了ThreadLocal在开源框架中使用的两个场景；接着又分享了两个业务开发中能够用上的场景，帮助看官们更感性地理解ThreadLocal的作用；最后，针对ThreadLocal潜在"可维护性"问题，鲜明的给出笔者本人的观点：技术无所谓好坏，谨慎而不盲目使用，并针对如何正确使用ThreadLocal提出了一般化的方法论，只要遵循相应原则，基本上对于代码还是相当可控，而不致引入额外的维护成本
624
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
