静态代码块仅执行一次性初始化，不提供反向清理机制；清理必须由开发者主动设计静态清理方法（如public static void cleanup()），并通过JVM关闭钩子、ServletContextListener或显式API等时机调用，确保幂等与线程安全。
静态代码块本身不负责清理，它只做一次性初始化；Java 没有内置的“静态资源反向清理机制”，清理必须由开发者主动设计和触发。
静态资源清理不能依赖静态代码块
静态代码块在类加载时执行，且仅执行一次，它没有对应的“反向执行块”或自动卸载钩子。JVM 不会在类卸载（极少见）时自动运行清理逻辑，更不会在应用运行中自动回调。所以，把清理逻辑写在静态代码块里是无效的，也不会被调用。
需要手动提供清理入口点
对需释放的静态资源（如缓存、线程池、文件句柄、数据库连接等），应显式定义静态清理方法，并在合适时机调用：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 定义 public static void cleanup() 方法，在其中释放资源（如 close()、shutdown()、clear()、置 null）
- 确保该方法幂等：多次调用不抛异常、不重复释放
- 避免在 cleanup 中访问已清空的静态引用，防止 NullPointerException
- 典型示例：关闭静态线程池：
EXECUTOR_SERVICE.shutdownNow();，清空静态 Map：CACHE.clear();
常见触发清理的时机
没有统一标准，但实际项目中主要靠以下方式主动触发：
立即学习“Java免费学习笔记（深入）”；
- 应用正常关闭前：注册 JVM 关闭钩子
Runtime.getRuntime().addShutdownHook() - Web 应用中：在 ServletContextListener 的
contextDestroyed()中调用 - Spring 环境：使用
@PreDestroy（需托管为 Bean）或实现DisposableBean - 模块化场景：提供显式 shutdown API，由上层协调调用（如 SDK、插件框架）
特别注意内存与线程安全风险
静态资源若持有堆对象或开启后台线程，清理不到位极易引发泄漏：
- 静态集合（如
static List<String>）未 clear → 对象长期驻留堆中 - 静态线程池未 shutdown → 线程持续存活，阻止类加载器卸载
- 静态监听器/回调未注销 → 隐式引用导致关联对象无法回收
- 清理操作本身需线程安全：多个线程并发调用 cleanup 时，应加同步或使用 AtomicBoolean 控制执行一次
