单例对象持有资源时，生命周期和释放要注意什么？

简化版

单例生命周期通常很长，如果它持有线程池、连接、文件句柄、缓存等资源，必须明确初始化失败、关闭顺序、重复关闭、重启重载和测试清理策略。否则单例会变成资源泄漏点，尤其在容器重启、热部署和单元测试中更明显。

详细版

很多单例不是纯对象，而是资源管理器，例如 HTTP 客户端、线程池、配置监听器、指标注册表。它们创建一次不难，难的是何时创建、失败怎么办、何时释放、释放后还能不能再次使用。

设计时要回答：

初始化是饿汉、懒加载还是容器启动阶段；
初始化失败是否允许重试；
是否需要 close() 或 destroy()；
多线程调用关闭和使用方法如何协调；
测试和热部署是否能清理旧实例。

在 Spring 等容器中，资源型单例更适合交给容器托管，通过 @PreDestroy、DisposableBean 或配置销毁方法释放资源。手写静态单例则要格外小心类加载器泄漏和进程退出前未关闭的问题。

完整版教学

一、为什么资源型单例比普通单例更危险

纯计算单例即使生命周期很长，也不一定有明显副作用。但资源型单例会持有外部资源，例如线程、socket、文件、定时任务和大缓存。只要释放策略不清楚，它就可能在系统停止、重启或测试结束后继续占用资源。

常见资源包括：

资源	泄漏后果
线程池	JVM 无法退出、线程数持续增长
HTTP 连接池	连接占用、目标服务压力异常
文件句柄	文件无法删除或达到句柄上限
本地缓存	内存持续增长
监听器/回调	旧对象被引用，形成泄漏

所以资源型单例不能只讨论“怎么创建一次”，还要讨论“怎么安全结束一次”。

二、初始化失败要有明确语义

如果单例在类初始化阶段打开网络连接，失败语义会比较僵硬。Java 类初始化失败后，后续再次使用该类可能遇到 NoClassDefFoundError 或初始化错误缓存，恢复路径不直观。

例如：

public final class ClientHolder {
    private static final RemoteClient CLIENT = new RemoteClient("http://config");
    public static RemoteClient get() { return CLIENT; }
}

如果启动时配置中心短暂不可用，静态初始化可能直接失败。对于需要重试、降级或动态配置的资源，显式初始化器或容器生命周期通常更适合。

启动 -> 初始化失败 -> 记录原因 -> 等待重试 -> 成功后发布可用实例

这条路径比“类加载时直接 new”更容易观测和恢复。

三、关闭方法要考虑并发使用

资源型单例常同时被多个线程使用。关闭时如果没有状态机，可能出现一个线程正在发送请求，另一个线程关闭连接池，导致随机失败。

可以设计简单状态：

NEW -> RUNNING -> CLOSING -> CLOSED

伪代码如下：

public void send(Request request) {
    if (closed.get()) {
        throw new IllegalStateException("client closed");
    }
    // use resource
}

public void close() {
    if (closed.compareAndSet(false, true)) {
        pool.shutdown();
    }
}

这里 compareAndSet 保证关闭逻辑最多执行 1 次。实际工程还要考虑正在执行的任务是否等待完成、超时时间是多少、强制关闭是否允许。

四、重复关闭和幂等很重要

关闭方法最好是幂等的。因为容器、测试框架和关闭钩子可能从不同路径触发释放。如果第 2 次关闭抛出奇怪异常，会让停机流程变得脆弱。

一个数字例子：服务里有 5 个组件引用同一个单例客户端，其中 2 个组件在销毁时都调用 client.close()。如果 close 不幂等，第二个组件销毁会失败；如果 close 幂等，只有第一次真正释放资源，后续调用直接返回。

close 第 1 次：RUNNING -> CLOSED，释放线程池
close 第 2 次：已 CLOSED，直接返回
close 第 3 次：已 CLOSED，直接返回

幂等关闭并不代表随时关闭都安全。它只解决重复调用问题，不能解决关闭期间仍有业务请求进入的问题。

五、容器托管为什么通常更稳

Spring、Micronaut 等容器提供了较完整的生命周期管理：创建顺序、依赖注入、初始化回调、销毁回调和作用域控制。资源型单例放进容器，通常比手写静态字段更容易管理。

例如：

@Component
public class ReportClient implements AutoCloseable {
    @Override
    public void close() {
        // release connection pool
    }
}

容器关闭时可以统一调用销毁逻辑。测试中也可以启动独立容器或替换 Bean。相比之下，静态单例常常活到 JVM 退出，难以按测试用例或模块卸载粒度释放。

记忆钩子：创建型模式只回答“谁创建”，资源型单例还必须回答“谁关闭、何时关闭、失败后怎么办”。

六、热部署和 ClassLoader 泄漏

在应用服务器、插件系统或热部署环境中，资源型单例如果被长生命周期线程引用，可能阻止旧 ClassLoader 回收。比如单例启动了一个后台线程，线程的 contextClassLoader 指向业务加载器，即使应用卸载，旧类和对象也可能留在内存里。

示意：

System Thread
  -> Runnable from old app
    -> Singleton instance
      -> Old ClassLoader

如果每次热部署都留下 30 MB 旧对象，部署 20 次就可能残留约 600 MB。解决思路是关闭线程池、注销监听器、清空静态引用，并把生命周期交给容器或插件框架。

七、测试环境要有清理策略

资源型单例在测试中会造成两个常见问题：端口占用和状态残留。第一个测试启动了本地服务器但没有关闭，第二个测试再绑定同一端口就失败；缓存型单例没有清空，也会让断言依赖执行顺序。

较好的做法包括：

测试优先注入 fake 实现；
每个测试类使用独立容器上下文；
对静态资源提供受控的 test-only 清理入口；
使用 try-with-resources 或测试框架生命周期回调关闭资源；
避免在单例中保存请求级业务状态。

如果一个单例必须在测试之间 reset，要确保 reset 和业务方法不会并发执行，否则清理动作本身也会制造竞态。

八、常见误区与追问

误区：单例只创建一次，所以资源管理更简单。 长生命周期会放大释放、重载和测试清理问题。
误区：JVM 退出会自动释放所有资源，因此不用 close。 进程退出能回收内存，但优雅停机、刷盘、注销和连接关闭仍需要显式流程。
误区：close 方法写了就安全。 还要考虑并发使用、重复关闭、关闭超时和异常处理。
误区：静态内部类懒加载能解决生命周期问题。 它只解决创建时机和线程安全，不负责销毁。
追问：初始化失败需要重试怎么办？ 不宜依赖静态类初始化，使用显式工厂、容器生命周期或可观测的初始化状态机。
追问：资源型单例是否适合枚举实现？ 简单固定资源可以，但复杂依赖、代理和销毁管理通常更适合容器。
追问：如何验证没有资源泄漏？ 检查线程数、句柄数、连接池指标、类加载器引用和测试后的端口释放。

九、加强记忆

资源型单例要用生命周期视角回答：创建、发布、使用、关闭、重试、清理。普通单例题只问实例唯一，资源型单例还要把失败语义、并发关闭、幂等释放、容器托管和测试隔离一起讲清楚。

简化版

详细版