为什么单例模式容易造成隐藏依赖和测试困难？

简化版

单例容易让代码通过静态入口直接取依赖，方法签名和构造器看不出真实依赖；同时全局实例和可变状态可能跨测试残留，导致测试顺序相关、并行测试互相污染。改进方式是优先依赖接口和构造器注入，把共享实例交给容器管理，并尽量让单例无状态。

详细版

单例的风险不只在“只能创建一个对象”，更在于它常被当成全局访问点。业务代码如果到处调用 Config.getInstance()、UserContext.getInstance()，依赖关系就隐藏在方法体里，调用者无法从构造器看出这个类需要什么。

测试困难主要来自三方面：

全局状态在不同测试之间残留；
静态入口难以替换为 mock；
并行测试共享同一个实例，容易互相影响。

工程上应避免在单例中保存请求级、用户级和测试用例级状态。需要共享实例时，优先用依赖注入容器提供 singleton scope；需要替换时依赖接口；必须使用静态单例时，要提供清晰的只读状态、关闭流程和测试清理策略。

完整版教学

一、隐藏依赖是怎么产生的

隐藏依赖指的是：类的构造器和方法参数看不出它依赖什么，但方法内部偷偷访问全局对象。单例的静态获取方法很容易制造这种情况。

例如：

public class OrderService {
    public BigDecimal calculate(Long orderId) {
        int timeout = ConfigCenter.getInstance().getTimeout();
        return queryAndCalculate(orderId, timeout);
    }
}

从 OrderService 的构造器看，它没有任何依赖；但实际运行需要 ConfigCenter 已初始化。测试时如果忘了准备全局配置，就会在方法内部失败。依赖越隐藏，代码越难组合、替换和审查。

二、为什么静态入口会削弱可替换性

如果调用方写死 ConfigCenter.getInstance()，测试就很难换成一个只返回固定配置的 fake 对象。你可以用反射改静态字段，也可以引入特殊 mock 框架，但这些做法都比普通构造器注入更脆。

对比写法：

public class OrderService {
    private final ConfigProvider config;

    public OrderService(ConfigProvider config) {
        this.config = config;
    }
}

生产环境注入真实实现，测试环境注入 fake 实现。假设有 50 个测试用例需要不同超时时间，构造器注入只要 new 50 个不同 fake；静态单例则需要反复修改全局状态，任何一个测试忘记恢复都会影响后续用例。

三、全局可变状态为什么会污染测试

单例如果保存可变字段，字段生命周期通常跟进程一样长。测试 A 改了字段，测试 B 可能读到旧值，导致测试是否通过取决于执行顺序。

示例：

TestA: Singleton.mode = "gray"
TestA: 断言灰度逻辑通过
TestB: 期望默认 mode = "prod"
TestB: 读到 "gray"，失败

如果测试框架并行执行，问题更明显。两个测试同时修改同一个全局实例，可能出现非确定性失败。非确定性失败最难排查，因为本地单跑通过，CI 并发运行失败。

记忆钩子：单例把生命周期拉长了，测试就必须为“上一个用例留下了什么”负责。

四、单例和并发测试的冲突

并行测试不是特殊情况，现代项目为了速度经常开启。假设 8 个 worker 同时跑测试，所有 worker 在同一个 JVM 内共享静态单例，那么它们修改的就是同一份状态。

一个简单数字例子：

8 个并行测试
每个测试都执行 setCurrentUser(user-i)
随后断言 getCurrentUser() == user-i
如果 currentUser 是单例字段，任意两个测试交错都可能互相覆盖

这类问题不能只靠 synchronized 修复。加锁最多保证读写原子，不能让每个测试拥有独立上下文。正确模型通常是把用户状态放到请求上下文、线程上下文或显式参数中，而不是放进进程级单例。

五、依赖注入如何保留共享又降低耦合

依赖注入并不反对共享实例。Spring 默认 singleton Bean 就是共享对象，只是共享由容器负责，依赖通过构造器显式声明。

对比：

方案	共享实例	依赖可见	测试替换	生命周期
静态单例	可以	较差	较难	类自己负责
容器 singleton	可以	较好	较容易	容器负责
每次 new	不共享	可见	容易	调用方负责
静态工具	不应有状态	方法内可见	取决于是否纯函数	无对象生命周期

例如配置客户端可以作为容器 singleton 注入 30 个服务类。这样仍然只创建 1 个客户端，但每个服务类的依赖都能从构造器看出来，测试也能传入 fake。

六、哪些单例更容易出问题

高风险单例通常有 4 个特征：

保存请求级或用户级数据；
初始化依赖外部环境且失败后难恢复；
提供大量 setXxx() 修改全局配置；
被业务代码通过静态入口到处调用。

低风险单例通常是无状态、只读、生命周期简单的对象，例如不可变配置快照、枚举常量服务、进程内指标注册入口。即便如此，也要注意资源关闭和测试清理。

判断时可以用一个问题：如果我想在同一个测试进程里创建两个不同配置的 OrderService，当前设计是否允许？如果不允许，就说明单例已经限制了测试隔离和组合能力。

七、如何改造已经滥用的单例

已有项目不能总是一次性删除单例，可以分步骤改造：

抽出接口，例如 ConfigProvider；
新代码通过构造器依赖接口；
旧的 getInstance() 暂时作为适配入口；
把可变状态迁移到请求上下文或数据库；
为测试提供显式 reset 或独立实例工厂；
最后减少静态入口调用点。

改造目标不是形式上消灭所有单例，而是让依赖显式、状态边界清楚、测试可隔离。面试中这样回答会比简单说“单例不好”更成熟。

八、常见误区与追问

误区：单例一定导致测试困难。 无状态且只读的单例风险较低，问题主要来自静态硬编码和全局可变状态。
误区：用了 Spring singleton 就没有单例问题。 容器单例仍共享同一对象，可变字段依然要处理并发和测试隔离。
误区：给单例加 reset 方法就完美解决测试。 reset 容易遗漏，且并行测试下仍可能互相影响。
误区：隐藏依赖只是代码风格问题。 它会直接影响替换实现、故障定位、单元测试和模块复用。
追问：什么时候可以接受静态单例？ 生命周期简单、无状态或只读、无替换需求且边界明确时可以接受。
追问：ThreadLocal 能否解决单例保存用户状态的问题？ 只能缓解线程隔离，还要处理线程池复用下的清理，不能替代清晰的上下文设计。
追问：如何发现隐藏依赖？ 看构造器为空但方法内部访问静态全局对象、系统时间、环境变量或外部客户端的地方。

九、加强记忆

这题的核心不是背“单例不好”，而是讲清两条链：静态入口会隐藏依赖，全局可变状态会污染测试。改进方向是接口、构造器注入、容器管理共享实例，以及把请求级状态从进程级单例里拿出来。

简化版

详细版