ThreadLocal

ThreadLocal 是 Java 中一个用于存储线程本地变量的工具类，它允许每个线程拥有独立的变量副本，解决了多线程环境下变量共享的线程安全问题。

一、ThreadLocal 的核心作用

线程隔离

每个线程操作自己的变量副本，互不干扰。例如：你的代码中 loginUser 存储的用户信息，每个请求线程独立保存，避免多线程竞争。

跨方法共享数据

在同一个线程中，任何地方都可以通过 ThreadLocal 获取共享数据。例如：拦截器中将用户信息存入后，后续的 Service、Controller 可直接获取，无需传参。

二、ThreadLocal 的工作原理

内部结构

每个线程（Thread 类）内部维护一个 ThreadLocalMap，类似键值对结构。

ThreadLocal 作为键（Key），存储的变量作为值（Value）。

// 伪代码示意
class Thread {
  ThreadLocalMap threadLocals; // 存储所有 ThreadLocal 变量
}

class ThreadLocal<T> {
  public T get() {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = t.threadLocals;
    Entry e = map.getEntry(this); // 以当前 ThreadLocal 实例为键查找值
    return (T)e.value;
  }
}

数据存取
set(T value): 将值存入当前线程的 ThreadLocalMap，键为当前 ThreadLocal 实例。
get(): 从当前线程的 ThreadLocalMap 中取出值。

三、代码中的 ThreadLocal 分析

1 定义与初始化

public static ThreadLocal<MemberResponseVo> loginUser = new ThreadLocal<>();

创建了一个静态的 ThreadLocal 实例，用于存储 MemberResponseVo（用户信息）。
2 在拦截器中设置值

if (attribute != null) {
    loginUser.set(attribute); // 用户信息存入 ThreadLocal
    return true;
}

当用户已登录时，将用户信息存入当前线程的 ThreadLocal。
3 在其他地方获取值
后续业务代码（如 Service 层）可直接通过 loginUser.get() 获取用户信息：

MemberResponseVo user = LoginUserInterceptor.loginUser.get();

无需传递 HttpServletRequest 或从 Session 重复读取，提升效率。

四、ThreadLocal 的内存泄漏问题

1. 原因
   ThreadLocalMap 的键（Key）是弱引用，而值（Value）是强引用。

如果 ThreadLocal 实例被回收（如设为 null），但值仍被线程的 ThreadLocalMap 引用，会导致值无法回收，引发内存泄漏。

2. 解决方案
   必须手动调用 remove()：在不再需要时（如请求处理完成后），清理当前线程的 ThreadLocal 值。

3. 代码改进建议
   在拦截器的 afterCompletion 方法中清理数据：

@Override
public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
    loginUser.remove(); // 防止内存泄漏
}

五、ThreadLocal 的使用场景

Web 应用的请求上下文
如保存用户身份、语言设置等，贯穿整个请求生命周期。

数据库连接管理
每个线程维护独立的数据库连接，避免线程安全问题。

日期格式化
SimpleDateFormat 非线程安全，可通过 ThreadLocal 为每个线程分配一个实例。

浏览器多次请求时 ThreadLocal 如何保证数据隔离

1. Web 服务器的线程模型
   多线程处理请求：Web 服务器（如 Tomcat）使用线程池处理请求。当浏览器发起多个请求时，每个请求会被分配一个独立的线程处理。

线程复用：线程处理完请求后，会回到线程池等待下一个请求（线程复用），而不是销毁。

2. ThreadLocal 的数据存储机制
   线程隔离存储：ThreadLocal 的值存储在 线程的私有内存（Thread.threadLocals）中，不同线程之间互不可见。

示例流程：

请求1：由 线程A 处理，拦截器将用户A的数据存入 loginUser.set(userA) → 数据存储在 线程A 的 ThreadLocalMap 中。

请求2：由 线程B 处理，拦截器将用户B的数据存入 loginUser.set(userB) → 数据存储在 线程B 的 ThreadLocalMap 中。

请求1 和 请求2 的处理线程不同，因此它们访问的 ThreadLocal 数据是各自独立的。

拦截器的 preHandle 方法会针对每个请求重新设置 ThreadLocal 的值：

public boolean preHandle(HttpServletRequest request, ...) {
    // 每个请求的线程都会执行以下逻辑：
    HttpSession session = request.getSession();
    MemberResponseVo user = (MemberResponseVo) session.getAttribute(LOGIN_USER);
    if (user != null) {
        loginUser.set(user); // 将用户数据绑定到当前线程的 ThreadLocal
        return true;
    }
}

不使用 ThreadLocal 的潜在问题及后果

1. 参数传递冗余

问题：
如果不在拦截器中将用户信息存入 ThreadLocal，后续业务层（如 Service、Controller）需要显式传递用户对象，导致代码冗余和耦合。

示例：
假设在秒杀业务中，需要多次获取用户 ID 进行权限校验或记录操作日志：

// Service 方法需显式接收用户参数
public void seckill(Long userId, SeckillRequest request) {
    // 业务逻辑
}

// Controller 调用时需重复获取用户信息
public String handleSeckill(HttpServletRequest request, SeckillRequest seckillReq) {
    MemberResponseVo user = (MemberResponseVo) request.getSession().getAttribute(LOGIN_USER);
    seckillService.seckill(user.getId(), seckillReq);
    // 其他方法仍需重复传递 user.getId()
}

后果：

代码重复：每次调用业务方法都需从 Session 获取用户。

维护困难：若用户信息结构变更，需修改所有传递参数的地方。

2. 线程安全问题

问题：
如果使用共享变量（如静态变量）存储用户信息，多线程并发请求时会导致数据错乱。

错误代码示例：

public class UserHolder {
    public static MemberResponseVo user; // 静态变量存储用户信息
}

// 拦截器中赋值
public boolean preHandle(...) {
    MemberResponseVo user = (MemberResponseVo) session.getAttribute(LOGIN_USER);
    UserHolder.user = user; // 静态变量被所有线程共享
}

后果：

脏读：线程A写入用户A的数据后，线程B写入用户B的数据，导致线程A后续读取到用户B的数据。

数据覆盖：高并发场景下，多个线程同时修改静态变量，最终数据不可预测。

3. 代码耦合

问题：
业务层直接依赖 HttpServletRequest 或 HttpSession 对象获取用户信息，导致代码与 Web 层紧耦合。

错误代码示例：

// Service 层直接操作 HttpServletRequest（错误！）
public class SeckillService {
    public void seckill(HttpServletRequest request) {
        MemberResponseVo user = (MemberResponseVo) request.getSession().getAttribute(LOGIN_USER);
        // 业务逻辑
    }
}

后果：

无法复用：业务代码只能在 Web 环境中使用（如无法在单元测试或消息队列消费者中调用）。

难以测试：需模拟 HttpServletRequest 对象才能测试业务逻辑。

4. 性能损耗

问题：
频繁从 HttpSession 中读取用户信息（尤其是分布式 Session 场景）会增加 I/O 开销。

示例：

// 每次需要用户信息时都从 Session 读取
public void logOperation(HttpServletRequest request) {
    MemberResponseVo user = (MemberResponseVo) request.getSession().getAttribute(LOGIN_USER);
    System.out.println("用户 " + user.getId() + " 执行操作");
}

后果：

额外网络请求：若 Session 存储在 Redis 等远程服务中，每次读取需网络交互。

序列化开销：从 Session 中反序列化用户对象耗时。

5. 代码可读性下降

问题：
代码中充斥大量重复的 session.getAttribute(LOGIN_USER) 逻辑，降低可读性。

错误代码示例：

public void methodA(HttpServletRequest request) {
    MemberResponseVo user = (MemberResponseVo) request.getSession().getAttribute(LOGIN_USER);
    // 逻辑A
}

public void methodB(HttpServletRequest request) {
    MemberResponseVo user = (MemberResponseVo) request.getSession().getAttribute(LOGIN_USER);
    // 逻辑B
}

后果：
代码臃肿：重复代码分散在各处，难以快速理解核心逻辑。
维护成本高：修改用户信息获取方式需修改所有相关方法。

对比使用 ThreadLocal 的优势
通过 ThreadLocal 解决了上述所有问题：

参数解耦：

// 拦截器中设置用户信息
loginUser.set(user);

// 业务层直接获取
MemberResponseVo user = LoginUserInterceptor.loginUser.get();

无需传递参数，业务层直接通过 ThreadLocal 获取用户信息。

线程安全：
每个线程独立存储用户数据，天然隔离，无并发冲突。

代码解耦：
业务层不依赖 HttpServletRequest，可独立于 Web 环境运行。

性能优化：
用户信息只需从 Session 读取一次，后续直接从线程内存访问。

代码简洁：
所有业务逻辑中用户信息的获取方式统一，代码更清晰。

不使用静态变量仍可能引发线程安全问题

静态变量属于类级别，所有实例共享，而实例变量属于对象实例，如果多个线程共享同一个对象实例，那么实例变量也会有线程安全问题。而局部变量由于存在于栈中，每个线程有自己的栈，因此是线程安全的。
Spring默认的单例作用域，如果拦截器是单例的，并且使用实例变量存储用户信息，那么多个线程访问同一个拦截器实例的实例变量时，就会产生竞争条件，导致数据错乱。因此，即使用实例变量而非静态变量，仍然存在线程安全问题。

问题核心：变量的共享范围
线程安全问题的根本原因在于 变量被多个线程共享且未正确同步，而非变量是否是静态的。
关键区分点：
静态变量：属于类级别，所有线程共享同一份数据。
实例变量：属于对象实例级别，若多个线程操作同一个对象实例，实例变量仍会被共享。

示例场景分析
假设将用户信息存储在拦截器的实例变量中（非静态变量）：

public class LoginUserInterceptor implements HandlerInterceptor {
    private MemberResponseVo user; // 实例变量（非静态）

    @Override
    public boolean preHandle(HttpServletRequest request, ...) {
        HttpSession session = request.getSession();
        this.user = (MemberResponseVo) session.getAttribute(LOGIN_USER); // 写入实例变量
        return true;
    }

    // 其他方法可能读取 user
}

问题分析：

若拦截器是单例（如 Spring 默认的单例模式），所有线程共享同一个拦截器实例。

线程A 和 线程B 同时调用 preHandle 方法时，会竞争修改 user 实例变量，导致数据错乱。

后果：

脏读：线程A写入用户A后，线程B写入用户B，线程A后续读取到用户B的数据。

数据覆盖：并发写入时，最终 user 的值取决于最后写入的线程。

其他共享变量的形式
即使不使用静态变量或实例变量，以下场景仍可能引发线程安全问题：
共享容器（如 Map）

public class UserCache {
    private Map<Long, User> cache = new HashMap<>(); // 实例变量

    public void addUser(User user) {
        cache.put(user.getId(), user);
    }

    public User getUser(Long id) {
        return cache.get(id);
    }
}

若多个线程同时操作 cache，且未使用同步机制（如 ConcurrentHashMap），会导致 HashMap 内部状态损坏或读取脏数据。
单例对象

@Component
public class SingletonService {
    private User currentUser; // 单例对象的实例变量

    public void setUser(User user) {
        this.currentUser = user;
    }

    public User getUser() {
        return currentUser;
    }
}

单例对象的实例变量本质是共享的，多线程并发调用 setUser 和 getUser 会引发数据错乱。

ThreadLocal 的解决方案
通过 ThreadLocal 实现 线程级私有存储，彻底避免共享：

public class LoginUserInterceptor implements HandlerInterceptor {
    private static final ThreadLocal<User> userHolder = new ThreadLocal<>(); // 线程私有

    @Override
    public boolean preHandle(HttpServletRequest request, ...) {
        User user = (User) request.getSession().getAttribute(LOGIN_USER);
        userHolder.set(user); // 存储到当前线程的私有变量
        return true;
    }

    @Override
    public void afterCompletion(...) {
        userHolder.remove(); // 清理当前线程的私有变量
    }
}

优势：

每个线程独立操作自己的 userHolder，无竞争条件。

无需同步（如 synchronized 或锁），性能更高。

关键总结
线程安全的核心：是否有多线程共享同一变量。
静态变量只是共享的一种形式：实例变量、容器、单例对象等共享方式同样会导致线程安全问题。
ThreadLocal 的本质：通过线程隔离，将共享变为私有，无需同步即可解决线程安全问题。

ConcurrentHashMap

如果将线程ID作为键存储用户信息，那么每个线程在访问时确实可以获取到自己的数据。但问题在于如何确保每个线程在存储时使用的键是唯一的，并且正确对应到各自的线程。例如，线程A在ConcurrentHashMap中以自身ID为键存储用户A的信息，线程B同样操作。这似乎可行，但需要考虑线程ID的获取是否正确，以及是否存在线程复用的情况。

此外，如果拦截器是单例的，那么ConcurrentHashMap作为实例变量会被所有线程共享，但每个线程操作不同的键，可能不会产生冲突。但这里需要验证这种设计是否真的安全。

线程安全的数据结构只能保证其内部操作的原子性，而不能保证外部逻辑的线程安全。例如，如果多个步骤的操作需要作为一个原子操作执行，单纯使用ConcurrentHashMap是不够的，可能需要额外的同步机制。

在拦截器中，每个请求处理线程需要存储当前登录用户的信息，以便后续处理。使用ThreadLocal可以确保每个线程独立存储，互不干扰。而如果改用ConcurrentHashMap，以线程ID为键，存储用户信息，那么需要确保每个线程在存取时使用的键是正确的，并且不会发生键冲突。

这里可能存在几个问题：

1. 线程ID的唯一性：Java中的线程ID在生命周期内是唯一的，但线程可能被复用（如线程池中的线程）。当一个线程被复用处理新的请求时，其线程ID不变，此时ConcurrentHashMap中该键对应的值可能残留之前请求的数据，导致数据污染。

2. 清理问题：与ThreadLocal不同，ConcurrentHashMap不会自动清理不再需要的条目。需要在适当的时候手动移除键值对，否则可能导致内存泄漏。

3. 复合操作的安全性：例如，先检查用户是否存在，再执行某些操作，这样的复合操作在ConcurrentHashMap中可能仍需要额外的同步，因为虽然单个操作是线程安全的，但组合操作可能不是原子的。

另外，需要考虑性能问题。ConcurrentHashMap在高并发下表现良好，但相比ThreadLocal的本地存储，可能仍有性能开销，因为需要处理哈希表的并发访问。

ThreadLocal的设计正是为了解决这种每个线程需要独立副本的场景，而ConcurrentHashMap虽然线程安全，但并非为此类场景设计，因此可能在正确性和性能上不如ThreadLocal合适。

ConcurrentHashMap 的线程安全性
ConcurrentHashMap 是线程安全的，它通过分段锁（JDK 7）或 CAS + synchronized（JDK 8+）实现并发访问的安全性。

单操作原子性：例如 put()、get()、remove() 是原子的，多线程并发操作不会导致内部数据损坏。

复合操作非原子性：若需要多个操作组合（如“检查是否存在，不存在则插入”），仍需额外同步（如 computeIfAbsent()）。

假设用 ConcurrentHashMap 以线程 ID 为键存储用户信息：

public class UserHolder {
    private static final ConcurrentHashMap<Long, MemberResponseVo> userMap = new ConcurrentHashMap<>();

    // 拦截器中存储用户信息
    public static void setUser(MemberResponseVo user) {
        long threadId = Thread.currentThread().getId();
        userMap.put(threadId, user);
    }

    // 业务层获取用户信息
    public static MemberResponseVo getUser() {
        long threadId = Thread.currentThread().getId();
        return userMap.get(threadId);
    }

    // 清理用户信息
    public static void removeUser() {
        long threadId = Thread.currentThread().getId();
        userMap.remove(threadId);
    }
}

表面逻辑：每个线程通过自身 ID 存取用户信息，看似隔离。

潜在问题分析
1 线程 ID 复用导致数据污染
问题根源：Web 服务器（如 Tomcat）使用线程池，线程处理完请求后会被复用。

示例场景：

线程A（ID=100）处理请求1，存入用户A：userMap.put(100, userA)。

线程A处理完请求1后放回线程池。

线程A（ID=100）处理请求2，存入用户B：userMap.put(100, userB)。

请求1的残留数据未清理：若未调用 removeUser()，userMap 中线程A的旧值会被覆盖，但若清理逻辑遗漏，可能导致后续逻辑读取到错误数据。

2 必须手动清理数据
ConcurrentHashMap 不会自动清理：与 ThreadLocal 不同，需在请求处理完成后显式调用 removeUser()，否则 userMap 会持续增长，引发内存泄漏。

风险点：若开发者忘记清理（如异常分支未执行清理），会导致数据残留。

3 性能开销
哈希表操作成本：ConcurrentHashMap 的 put()、get() 涉及哈希计算和并发控制，而 ThreadLocal 直接访问线程私有内存，无竞争。

高并发场景下差距明显：频繁存取用户信息时，ConcurrentHashMap 的性能低于 ThreadLocal。

4 设计复杂性
依赖线程 ID 管理数据：需确保所有存取操作均基于当前线程 ID，逻辑耦合度高。

扩展性差：若需存储更多线程级数据（如请求ID、语言环境等），需维护多个 ConcurrentHashMap。

ThreadLocal 对比 ConcurrentHashMap 的优势

特性	ThreadLocal	ConcurrentHashMap
数据隔离性	天然隔离，线程私有	需依赖键（如线程 ID）人工隔离
自动清理	支持 remove()，结合拦截器可自动清理	必须手动清理，否则内存泄漏
性能	直接访问线程内存，无锁竞争	哈希表操作，涉及并发控制开销
复合操作安全性	无需额外同步	需同步或原子方法（如 computeIfAbsent()）
内存占用	仅存储当前线程的数据	存储所有线程的数据，占用更多内存

ConcurrentHashMap 不能完全替代 ThreadLocal：
虽然能通过线程 ID 隔离数据，但需处理线程复用、手动清理、性能开销等问题。
在需要线程级数据隔离的场景中，ThreadLocal 是更简洁、高效、安全的选择。

适用场景：
ConcurrentHashMap：适合存储全局共享且需并发访问的数据（如缓存）。
ThreadLocal：适合存储线程私有的上下文信息（如用户身份、事务上下文）。

使用 ThreadLocal 是标准解决方案，而 ConcurrentHashMap 会引入不必要的复杂性和风险。若坚持使用 ConcurrentHashMap，需额外注意以下事项：
严格清理数据：在 afterCompletion 中调用 removeUser()。
处理线程复用：即使清理数据，仍需确保每次请求重新初始化用户信息。
性能测试：高并发下验证是否满足要求。

为什么拦截器、Controller、Service 是同一个线程？

在 Java Web 应用（如 Spring MVC）中，一个 HTTP 请求的处理流程如下：
1请求到达服务器（如 Tomcat/Nginx），服务器从线程池中分配一个线程处理该请求。
2线程贯穿整个请求生命周期：
执行拦截器的 preHandle()
执行目标 Controller 方法
调用 Service 层、DAO 层代码
执行拦截器的 postHandle() 和 afterCompletion()
3响应返回后，线程释放回线程池（但线程可能被后续请求复用）。

关键特性：
单线程处理：一个请求的完整处理流程（拦截器 → Controller → Service → 拦截器）始终由同一个线程完成。
线程私有性：ThreadLocal 存储的数据仅在当前线程内可见，天然隔离其他请求的线程。

页面刷新会触发新线程吗？

页面刷新 = 新的 HTTP 请求：浏览器重新发送请求，服务器会分配一个新线程（可能是线程池中的另一个线程）处理该请求。

新旧请求线程隔离：即使新请求复用了之前的线程（例如线程池中回收的线程），ThreadLocal 的数据也会被重新初始化。

示例流程：
第一次请求：线程A 处理，拦截器设置 ThreadLocal.set(userA)。
页面刷新（第二次请求）：线程B（可能是新线程或复用线程A）处理，拦截器重新执行 ThreadLocal.set(userA或userB)。

数据隔离性：
若线程B是全新线程，其 ThreadLocal 初始为空，拦截器会重新设置用户信息。
若线程B是复用的线程A，但前一次请求的 afterCompletion() 中已调用 ThreadLocal.remove()，数据已被清理，仍需重新设置。

在拦截器的 afterCompletion() 中清理 ThreadLocal，避免线程复用导致脏数据：

@Override
public void afterCompletion(...) {
    LoginUserInterceptor.loginUser.remove(); // 强制清理当前线程的 ThreadLocal
}

作用：确保线程被放回线程池时，其 ThreadLocal 数据已被清除，避免下次被复用时读到旧数据。

每个请求的线程在处理时，都会重新执行拦截器的 preHandle()，从而重新设置 ThreadLocal：

public boolean preHandle(...) {
    // 每个请求的线程都会执行以下代码
    MemberResponseVo user = (MemberResponseVo) session.getAttribute(LOGIN_USER);
    if (user != null) {
        loginUser.set(user); // 重新绑定当前线程的 ThreadLocal
        return true;
    }
}

线程复用也无影响：即使线程被复用，新的请求会覆盖 ThreadLocal 的值。

特殊场景：异步线程
如果代码中手动创建新线程或使用 @Async 异步处理，新线程无法直接访问原线程的 ThreadLocal 数据。
解决方案：
场景 1：需要在子线程中获取用户信息
手动传递用户对象（如通过方法参数），或使用 InheritableThreadLocal（有限支持）。

场景 2：使用异步框架（如 CompletableFuture）
通过上下文传递工具（如 Spring 的 RequestContextHolder）或装饰器模式传递数据。
示例：

// 异步方法中手动传递用户信息
public void asyncTask(MemberResponseVo user) {
    CompletableFuture.runAsync(() -> {
        // 异步线程中无法直接访问原线程的 ThreadLocal，需显式传递
        System.out.println("异步处理用户: " + user.getId());
    });
}

场景	线程一致性	ThreadLocal 数据隔离性
同步请求处理	拦截器、Controller、Service 同一线程	天然隔离，无需额外处理
页面刷新（新请求）	新线程（可能复用旧线程）	通过 afterCompletion() 清理 + preHandle() 重置保证隔离
异步处理	新线程	需手动传递数据或使用上下文传递工具

在标准的同步请求处理中，拦截器、Controller、Service 必定在同一个线程内，ThreadLocal 可安全共享数据。

页面刷新会触发新请求，但通过正确清理和初始化 ThreadLocal，数据依然隔离。

异步场景需特殊处理，但常规 Web 开发中较少涉及。

为什么需要调用 remove() 即使已经覆盖了值？

虽然每次请求通过 preHandle 设置新的值确实会覆盖旧的 ThreadLocal 数据，但在实际场景中仍需在 afterCompletion 中调用 remove()，原因如下：

防止拦截器未覆盖旧值的场景

假设以下情况：

拦截器的路径匹配规则：仅拦截 /kill 请求。

线程复用：线程A处理完 /kill 请求后，未调用 remove()，接着处理一个 非 /kill 请求（如 /info）。

问题流程：

请求1（/kill）：
线程A执行拦截器 preHandle()，设置 ThreadLocal.set(userA)。
业务处理完成，未调用 remove()。

请求2（/info）：
线程A处理该请求，但 /info 不匹配拦截器路径，不会执行 preHandle()。
如果业务层（如 Controller/Service）误用了 ThreadLocal.get()，会错误地获取到 userA。

后果：
数据错乱：非 /kill 请求可能读取到前一个请求的用户信息。
安全隐患：未登录用户可能通过路径绕过拦截器，但误读到已登录用户数据。

防止条件分支未覆盖旧值

假设拦截器逻辑中存在条件判断：

public boolean preHandle(...) {
    if (condition) {
        // 只有满足条件时设置 ThreadLocal
        loginUser.set(user);
    }
    return true;
}

问题流程：
请求1：满足条件，设置 ThreadLocal.set(userA)。
请求2：不满足条件，未执行 set()。

若未清理 ThreadLocal，请求2的后续代码可能读到 userA。

后果：
脏数据残留：条件分支导致 ThreadLocal 未被覆盖，旧数据影响后续请求。

避免内存泄漏

ThreadLocal 的设计缺陷：
ThreadLocalMap 的键（Key）是弱引用，但值（Value）是强引用。
若未调用 remove()，即使 ThreadLocal 实例被回收，Value 仍被线程的 ThreadLocalMap 引用，导致无法被 GC 回收。

内存泄漏场景：
长期存活的线程（如线程池中的线程）：
线程处理多个请求，每次 set() 覆盖值，但旧值仍被 ThreadLocalMap 持有。
随着时间推移，ThreadLocalMap 中积累大量无用的 Value，占用内存。

// 线程池中的线程处理多个请求
for (int i = 0; i < 100000; i++) {
    threadPool.execute(() -> {
        loginUser.set(new User(...)); // 每次覆盖新值
        // 业务逻辑
        // 未调用 remove()
    });
}

每个线程的 ThreadLocalMap 会持续增长，最终导致内存溢出（OOM）。

代码健壮性保障

防御式编程原则：

即使逻辑上确保每次都会覆盖 ThreadLocal，也应显式清理数据。

避免不可预见的代码变更：
例如后续有人修改拦截器逻辑，删除了 set() 操作，但未添加 remove()，导致旧数据残留。

总结：覆盖 ≠ 清理

操作	覆盖 (set())	清理 (remove())
数据隔离	仅覆盖当前值，旧值被替换	彻底清除值，确保无残留
内存管理	旧值仍被 ThreadLocalMap 引用，无法及时 GC	释放值引用，允许 GC 回收内存
异常防护	依赖拦截器逻辑全覆盖，否则可能漏覆盖	强制清理，无论后续是否有新值写入
代码安全	条件分支或路径匹配可能导致漏覆盖	确保线程池复用时的数据隔离