classloader内存泄漏本质是旧classloader及其加载的类、实例、静态资源被强引用导致gc无法回收，关键在“断链”使其彻底不可达。
ClassLoader 内存泄漏不是“加载了没卸载”那么简单，而是旧 ClassLoader 及其加载的所有类、实例、静态资源，被意外持有了强引用，导致 GC 无法回收。JVM 本身不提供主动卸载 ClassLoader 的 API，所以关键在于“断链”——让整个加载器子图彻底不可达。
切断静态引用链
静态字段是 ClassLoader 泄漏最常见入口。Log4j 的 Logger、Jackson 的 ObjectMapper、自定义的 static Map 或 ExecutorService，都可能长期持有业务类或其 ClassLoader。
- 所有 static final 对象，若实现了 close/shutdown/clear 方法，必须在卸载前显式调用（如 logger 关闭无意义，但 ExecutorService 必须 shutdownNow）
- 避免在 static 上直接 new 业务类实例；若必须缓存，改用 WeakReference 包装，或使用 WeakHashMap
- 检查第三方库文档：Log4j2 提供 LogManager.shutdown()，Hibernate 有 SessionFactory.close()，这些都需在 contextDestroyed 中触发
清理 ThreadLocal 和线程上下文
ThreadLocal 是隐形强引用大户。只要线程还在运行，且其 ThreadLocalMap 中存在 key 为业务类 ClassLoader 加载的类的 entry，value 就会阻止整个 ClassLoader 卸载。
- 每个使用了 ThreadLocal 的类，在热更新前必须调用 tl.remove()（不只是 set(null)）
- 特别注意 Tomcat/Jetty 的工作线程池：应用卸载后，线程未必立即销毁。需确保线程局部变量在 request 结束或 listener 销毁时清空
- 设置当前线程的 contextClassLoader 为 null 或系统类加载器（如 Thread.currentThread().setContextClassLoader(null)），防止 WebAppClassLoader 被间接持有
隔离并正确构造 URLClassLoader
复用或错误继承父加载器，会让新旧类混杂、引用关系失控。独立、无委托的 ClassLoader 是可控卸载的前提。
- 构造时显式传入 null 作为 parent：new URLClassLoader(urls, null)，切断与 AppClassLoader 的委托链
- 只覆盖 findClass()，不要重写 loadClass() —— 否则破坏双亲委派，可能导致 java.lang.* 类加载异常
- 每次热部署都新建 ClassLoader 实例，旧实例在完成清理后立即置为 null，不复用也不缓存
- 通过反射创建对象（clazz.getDeclaredConstructor().newInstance()），避免编译期类型硬编码，防止 class 字面量隐式绑定旧 ClassLoader
配合容器与驱动级清理
单靠代码清理不够，容器和 JDBC 驱动等底层组件常持有反向引用，必须协同处理。
- Tomcat：启用 reloadable="true"，关闭 JSP 编译缓存（development="false"），并在 web.xml 中配置 classloader-leak-prevention 监听器
- Oracle/MySQL 驱动：必须在 ServletContextListener.contextDestroyed() 中遍历 DriverManager.getDrivers()，对 oracle.jdbc.driver.OracleDriver 等显式 deregisterDriver()，否则 BootstrapClassLoader → Driver → WebAppClassLoader 链无法断裂
- 监控验证：用 Arthas 的 classloader -l 查看加载器数量是否持续增长；用 jmap -histo:live | grep 检查特定类实例数是否累积
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
