线程sleep本身不直接引发ClassLoader泄漏，但因长期存活而持续持有旧ClassLoader加载类的静态资源、ThreadLocal值等隐式引用，成为GC Roots导致其无法卸载；需在sleep前显式remove ThreadLocal、清理静态资源并配合容器生命周期管理。
线程在 sleep() 状态下本身不会直接引发 ClassLoader 泄漏，但它是泄漏暴露的“放大器”——因为线程长期存活，会持续持有对旧 ClassLoader 加载类中静态资源、ThreadLocal 值、监听器等的隐式引用。热更新时若未主动清理，这些引用就成为 GC Roots，导致整个旧 ClassLoader 及其加载的所有类无法卸载。
确保 ThreadLocal 在挂起前已清理
ThreadLocal 是最常见泄漏源头，尤其在线程池复用 + sleep 场景中。Thread 持有 ThreadLocalMap，而 map 中 Entry 的 value 是强引用，即使 ThreadLocal 实例被回收（key 为弱引用），value 仍滞留。
- 每次调用
sleep()前，显式执行对应 ThreadLocal 的remove()，不要依赖线程结束自动清理 - 避免在
sleep()前 set 大对象（如缓存上下文、数据库连接池句柄），更不要在循环中反复 set 不 remove - 若使用框架（如 Spring），确认其上下文管理器是否支持热更新时自动清理 ThreadLocal（例如
RequestContextHolder.resetRequestAttributes()）
切断线程与旧类加载器的静态关联
挂起线程可能正运行着由旧 ClassLoader 加载的类，这些类中的 static 字段（如 Logger、ExecutorService、缓存 Map）若未重置，就会强引用旧 ClassLoader。
- 热更新触发时，在 sleep 线程唤醒前，统一调用各模块的清理方法：关闭静态 Executor、清空 static Map、shutdown 静态 Timer
- 禁止在静态上下文中直接 new 业务类实例（如
private static Service instance = new Service();），改用延迟初始化 + 显式销毁 - 检查日志框架（Log4j2、SLF4J）是否启用类加载器感知模式；Log4j2 推荐配置
log4j2.isWebapp=false并禁用ContextSelector自动绑定
避免 sleep 线程参与类加载或反射调用
挂起中的线程一旦被唤醒并执行到涉及类加载的逻辑（如首次访问某个类、动态加载资源、JSON 反序列化），可能意外触发旧 ClassLoader 的委托链或静态初始化，重新激活引用。
- 热更新期间，将 sleep 线程标记为“待刷新”，唤醒后先执行类加载器切换逻辑（如重置当前线程上下文 ClassLoader）再继续业务
- 避免在 sleep 后直接调用
Class.forName(...)或ObjectMapper.readValue()等可能触发类加载的操作；改用已预加载的类型或通过新 ClassLoader 的反射实例操作 - 若使用 URLClassLoader，构造时必须传
null作 parent，防止委托给 AppClassLoader，造成新旧类混杂和引用纠缠
配合容器控制线程生命周期
纯靠代码无法保证 sleep 线程“配合卸载”，需与运行环境协同。JVM 不允许强制中断 sleep，但可设计可响应的挂起机制。
- 用
wait()/notify()或LockSupport.parkNanos()替代Thread.sleep()，使线程能被中断并响应清理信号 - 在 sleep 前注册钩子（如
Thread.currentThread().setUncaughtExceptionHandler()），并在热更新时发送中断信号，捕获InterruptedException后执行 cleanup 再重新 sleep - 若部署在 Tomcat/Jetty 等容器中，监听
ServletContextListener.contextDestroyed()或自定义 LifecycleListener，在卸载阶段主动唤醒并终止所有守护型 sleep 线程
