- 埋下隐患： 你在代码中使用了
ThreadLocal<UserContext>来保存当前请求的用户上下文信息。但是，你的初级同事在拦截器里**忘记写ThreadLocal.remove()**来清理数据了。 - 容器架构： Tomcat 为了处理高并发，维护了一个长生命周期的“工作线程池”。这些线程是由 Tomcat 的系统级类加载器加载的，它们只要 Tomcat 不停机，就不会死。而你的业务代码（包括
UserContext类），是由 Tomcat 为你的项目单独创建的WebappClassLoader加载的。 - 泄漏发生：
- 一个 HTTP 请求进来，Tomcat 线程池里的
Thread-A接手处理。你的代码把一个UserContext实例塞进了Thread-A的ThreadLocalMap中。请求结束，因为没调remove()，这个UserContext实例永久地卡在了Thread-A的肚子里。 - 此时，你修改了代码，在 Tomcat 控制台点击了“重新部署（Redeploy）”。
- Tomcat 的标准操作是：废弃旧的
WebappClassLoader，创建一个全新的WebappClassLoader来加载你修改后的新代码。
- 灾难爆发：
按理说，旧的类加载器及其加载的几十兆类元数据应该被 GC 掉。但是！那个长生不老的Thread-A依然存活在线程池里，它肚子里还强引用着旧版本代码产生的UserContext实例。
于是，可怕的引用链生效了：
Tomcat 核心线程 (GC Root) -> ThreadLocalMap -> 旧的 UserContext 实例 -> 旧的 UserContext.class -> 旧的 WebappClassLoader -> 旧版本项目里的几千个 Controller、Service、DTO 的类元数据。
结果就是：你每点击一次“重新部署”，元空间里就会死死卡住几十兆的旧代码元数据。部署几次之后，线上服务器直接抛出 OOM: Metaspace，系统彻底宕机。