静态变量残留不是“忘了清”，而是它的生命周期天然绑定旧 ClassLoader——只要类没被卸载，static 字段就一直存在；而热部署时旧类根本不会卸载，只会被丢弃。解决的核心不是保留它，是让它不成为回收障碍。

静态字段必须显式清理，不能依赖 GC

static final Logger、static ConcurrentHashMap、static ScheduledExecutorService 等，都是 GC Roots 的强引用源头。它们一旦持有了业务类实例或本模块类的 Class 对象，就会把整个旧 ClassLoader “钉死”在内存里。

• 模块卸载前，逐个调用 close()、shutdown()、clear()、removeAll() 等清理方法
• 避免 static 块中执行不可逆注册（如 DriverManager.registerDriver）；若已注册，卸载时必须 deregisterDriver
• 对 static Map/Cache，不用 clear() 时，改用 WeakHashMap 或在卸载钩子中遍历 keySet 并 remove

把 static 当作“迁移锚点”，而非状态容器

不要把用户会话、计数器、配置快照等存进 static 变量。应将真实状态外置到跨 ClassLoader 存活的载体中，比如：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• JVM 级别的 ConcurrentMap（用系统类加载器加载，如 java.util.concurrent.ConcurrentHashMap）
• 外部存储：Redis、本地文件、共享内存映射区
• 通过 static final 引用一个全局状态管理器（如 StateHolder.getInstance()），该管理器本身由 Bootstrap 或 AppClassLoader 加载，不随模块更新

这样，每次新 ClassLoader 加载后，只需让新类通过同一入口获取状态，实现“无感切换”。

切断静态上下文对业务类的隐式持有

很多框架会在 static 字段里缓存 Class 或 ClassLoader 实例，例如 Log4j 的 LogManager、Jackson 的 ObjectMapper 默认实例、Hibernate 的 SessionFactory 静态构造器等。

• 启用框架提供的清理 API：LogManager.reset()、ObjectMapper.clearSerializationContexts()
• 禁用自动初始化：Jackson 配置 disable(DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS)，避免触发静态构造
• 避免在业务类中声明 public static final INSTANCE，改用工厂方法 + 懒汉单例（且确保工厂本身不被旧加载器污染）

验证是否真正清理干净

光写 cleanup() 不代表生效。需配合运行时观测确认旧 ClassLoader 已脱离 GC Roots：

• 启动 JVM 时加参数：-XX:+TraceClassUnloading -verbose:class，观察日志中是否有 Unloading class xxx from 出现
• 模块卸载后，用 WeakReference 包装旧 ClassLoader 实例，稍等片刻调用 get()；返回 null 才说明可回收
• 必要时 dump 堆（jmap -dump:format=b,file=heap.hprof pid），用 MAT 分析“Path to GC Roots”，定位哪个 static 字段还在强引用旧加载器

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南