讲一讲 SpringMVC，线程变量 ThreadLocal 的使用
Spring MVC 和 ThreadLocal 是 Java Web 开发中两个非常核心的概念。在 Spring MVC 的 Web 应用中，ThreadLocal 是一个非常有用的工具，但需要正确使用才能发挥其优势并避免问题。
🏗️ Spring MVC 的请求处理模型
在深入 ThreadLocal 之前，了解 Spring MVC 如何处理请求至关重要。
- 核心组件 ：Spring MVC 的核心是
DispatcherServlet，它作为前端控制器，接收所有 HTTP 请求。 - 处理流程 ：
DispatcherServlet根据请求的 URL 找到对应的Controller（处理器）来处理。Controller 执行业务逻辑后，返回视图名称和模型数据，最终由DispatcherServlet组装并响应给客户端。 - 线程模型 ：对于每一个 HTTP 请求，Web 服务器（如 Tomcat）都会从其线程池中分配一个线程来执行整个请求处理链路。这个线程会贯穿从
DispatcherServlet到Controller，再到Service、DAO等所有后续调用，直到请求结束。这意味着，在一次请求的完整生命周期内，所有代码都在同一个线程中执行。
这个"一次请求对应一个线程"的模型，为 ThreadLocal 的应用提供了完美的场景。
🧵 ThreadLocal 是什么？
ThreadLocal 是 Java 提供的一个工具类，它为每个使用它的线程提供一个独立的变量副本。每个线程只能访问和修改自己的那份副本，从而实现了线程间的数据隔离，从根本上避免了多线程并发访问共享变量时的线程安全问题。
你可以将其理解为一个以线程为作用域的"Map"，其内部结构大致如下：
- Key ：
ThreadLocal实例本身。 - Value：当前线程绑定的变量副本。
这种方式体现了"空间换时间"的设计思想，通过为每个线程提供独立的资源副本来避免昂贵的线程同步开销。
💡 在 Spring MVC 中的典型应用场景
利用 Spring MVC 的线程模型，ThreadLocal 可以优雅地解决一些特定问题。
1. 上下文信息传递
在 Web 应用中，经常需要在一次请求的整个处理链路中传递一些上下文信息，例如当前登录用户的身份信息、请求 ID（用于链路追踪）、租户信息等。
传统方式 的弊端是需要将这些信息作为参数，在 Controller、Service、DAO 等每一层的方法调用中层层传递，这不仅让代码变得臃肿，还增加了耦合度。
使用 ThreadLocal 可以实现隐式传参：
- 设置 ：在请求处理的入口（如
Interceptor拦截器或Filter过滤器）中，解析出用户信息并存入ThreadLocal。 - 获取 ：在后续任意的业务层代码中，都可以通过同一个
ThreadLocal实例获取到该用户信息。 - 清理 ：在请求处理完毕后，务必清除
ThreadLocal中的数据。
java
// 1. 定义一个工具类来封装 ThreadLocal
public class UserContextHolder {
private static final ThreadLocal<User> contextHolder = new ThreadLocal<>();
public static void setUser(User user) {
contextHolder.set(user);
}
public static User getUser() {
return contextHolder.get();
}
public static void clear() {
contextHolder.remove();
}
}
// 2. 在拦截器中设置和清理
@Component
public class UserContextInterceptor implements HandlerInterceptor {
@Override
public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
// 从请求头或 Session 中解析用户信息
User currentUser = authenticate(request);
// 将用户信息存入 ThreadLocal
UserContextHolder.setUser(currentUser);
return true;
}
@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
// 请求结束后，务必清理 ThreadLocal 中的数据，防止内存泄漏
UserContextHolder.clear();
}
}
// 3. 在任意业务 Service 中使用
@Service
public class SomeService {
public void doBusiness() {
// 直接获取当前线程绑定的用户信息，无需层层传递参数
User user = UserContextHolder.getUser();
// ... 业务逻辑
}
}2. 线程安全的工具类封装
一些常用的工具类本身不是线程安全的，例如 SimpleDateFormat。如果将其实例作为共享变量（static）使用，在多线程环境下会产生数据混乱。
使用 ThreadLocal 可以为每个线程提供一个独立的 SimpleDateFormat 实例，既保证了线程安全，又避免了频繁创建和销毁对象的开销。
java
public class DateUtil {
private static final ThreadLocal<SimpleDateFormat> sdfLocal =
ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
public static String format(Date date) {
return sdfLocal.get().format(date);
}
public static Date parse(String dateStr) throws ParseException {
return sdfLocal.get().parse(dateStr);
}
}⚠️ 关键注意事项与最佳实践
虽然 ThreadLocal 非常有用，但使用不当会带来严重问题，尤其是在基于线程池的 Web 应用中。
1. 内存泄漏风险
这是 ThreadLocal 最需要注意的问题。ThreadLocal 的底层实现中，其内部的 Entry 结构使用弱引用 来引用 ThreadLocal 对象，但使用强引用来存储值（value）。
- 问题 ：当
ThreadLocal实例被外部置为null后，由于线程池中的线程是长期存活的，其内部的ThreadLocalMap依然持有对 value 的强引用，导致 value 无法被垃圾回收，从而造成内存泄漏。 - 解决 ：每次使用完
ThreadLocal后，必须 调用remove()方法手动清除数据。
2. 线程复用问题
Web 服务器使用线程池来处理请求，线程会被反复用于处理不同的请求。如果在一个请求中为 ThreadLocal 设置了值，但没有在请求结束时清理，那么当下一个请求恰好被分配到同一个线程时，它可能会读取到上一个请求遗留的数据，导致严重的业务逻辑错误。
3. 最佳实践：使用 try-finally 块
为了确保 ThreadLocal 的数据总能被正确清理，无论业务代码是否发生异常，都应该使用 try-finally 语句块。
java
// 在拦截器或服务中
public void someMethod() {
// 设置数据
UserContextHolder.setUser(currentUser);
try {
// 执行业务逻辑
processBusiness();
} finally {
// 确保在方法结束时（无论成功或异常）清理数据
UserContextHolder.clear();
}
}🚀 进阶：跨线程传递（TransmittableThreadLocal）
需要注意的是，普通的 ThreadLocal 只在当前线程内有效。如果在主线程中创建了子线程（例如使用线程池执行异步任务），子线程是无法访问到主线程 ThreadLocal 中的数据的。
为了解决线程池场景下的上下文传递问题，阿里巴巴开源了一个增强版的 ThreadLocal 工具 ------ TransmittableThreadLocal (TTL) 。它通过装饰 Runnable 和 Callable 的方式，实现了在线程池中自动传递和恢复上下文信息。
总而言之，在 Spring MVC 中，ThreadLocal 是管理请求级别上下文数据的强大工具，但必须严格遵守"设置 -> 使用 -> 清理"的生命周期管理规范，才能确保应用的稳定和高效。