单例模式和静态工具类有什么区别？

简化版

单例是一个真正的对象，可以实现接口、被注入、持有生命周期和少量受控状态；静态工具类只是类级函数集合，更适合无状态、纯计算、没有替换需求的方法。面试中要强调：能用依赖注入表达共享实例时，通常比到处调用静态方法更清晰。

详细版

单例模式解决的是“在某个作用域内只需要一个对象身份”的问题，例如配置快照、注册表、连接管理器。它虽然提供全局访问点，但本质仍是对象：可以实现接口、参与多态、由容器管理，也可以在测试中替换实现。

静态工具类解决的是“这组操作不依赖对象状态”的问题，例如字符串格式化、日期计算、编码转换。它不需要创建对象，也不适合保存可变业务状态。

两者的核心区别包括：

维度	单例模式	静态工具类
本质	一个受控创建的对象	类级方法集合
状态	可以有受控状态和生命周期	应尽量无状态
扩展	可实现接口、可替换实现	难以多态替换
测试	注入式单例较易替换	静态调用通常更难隔离
典型场景	注册表、配置中心客户端	Math、StringUtils、编码工具

如果只是“很多地方要用”，不要直接选静态工具或静态单例。先判断它是不是对象、有没有生命周期、是否需要替换和测试隔离，再决定写成普通 Bean、单例对象还是工具类。

完整版教学

一、先分清“对象身份”和“函数集合”

单例模式讨论的是对象身份：同一个进程内的多个调用方拿到的是同一个实例，这个实例可以代表一个资源、协调者或状态边界。静态工具类讨论的是操作归属：这些方法只是放在同一个类名下面，并不代表存在一个业务对象。

例如 ConfigCenterClient 通常需要连接地址、缓存、刷新线程和关闭流程，它更像对象；DigestUtils.md5(text) 只是纯函数计算，不需要保存实例身份。把前者写成静态工具会隐藏连接生命周期，把后者写成单例则会制造多余概念。

需要共享身份 -> 倾向单例或容器 Bean
只是一组无状态计算 -> 倾向静态工具类
需要替换实现/模拟依赖 -> 倾向接口 + 依赖注入

判断时不要只看“调用方便”。调用方便是语法收益，身份边界、生命周期和可测试性才是设计收益。

二、单例为什么仍然是面向对象的对象

单例虽然经常用静态方法获取，但返回值仍是对象。对象意味着它可以实现接口、参与继承层次、被代理、被装饰，也可以由 Spring 之类的容器统一管理生命周期。

例如一个告警发送器可以定义接口：

public interface AlarmSender {
    void send(String message);
}

public final class AlarmSenderSingleton implements AlarmSender {
    private static final AlarmSenderSingleton INSTANCE = new AlarmSenderSingleton();
    private AlarmSenderSingleton() {}
    public static AlarmSenderSingleton getInstance() { return INSTANCE; }
    public void send(String message) { /* send alarm */ }
}

调用方如果依赖 AlarmSender 接口，就仍有替换空间；如果到处硬编码 AlarmSenderSingleton.getInstance()，替换能力会被静态入口削弱。也就是说，单例本身不是原罪，真正危险的是把全局访问点当成依赖管理方式。

三、静态工具类适合什么场景

静态工具类最适合无状态、确定性、轻量的操作。输入相同，输出相同，不需要连接外部资源，不需要按环境替换，也不需要在测试之间清理状态，这类方法放在工具类中很自然。

典型例子包括：

public final class StringMasks {
    private StringMasks() {}

    public static String maskPhone(String phone) {
        if (phone == null || phone.length() != 11) return phone;
        return phone.substring(0, 3) + "****" + phone.substring(7);
    }
}

这里没有“同一个实例”的需求，只有“同一个算法”的复用需求。若 1000 次调用都不依赖共享字段，就没有必要为了模式而创建单例。

记忆钩子：单例强调“同一个对象”，静态工具强调“同一组函数”；前者问身份，后者问状态。

四、从测试角度看两者差异

测试单例时，最怕的是全局状态残留。假设单例里保存 currentTenantId，第 1 个测试设置为 tenant-a，第 2 个测试若没有清理就可能读到旧值，导致测试顺序影响结果。

静态工具类如果保持纯函数，测试反而很简单：输入 13812345678，输出 138****5678，没有共享状态。真正难测的是静态方法内部访问网络、数据库、系统时间或全局配置，因为调用方无法通过构造器替换这些依赖。

一个简单对比：

测试场景	单例	静态工具类
纯计算	不必要	很合适
外部依赖	可通过接口注入缓解	静态硬编码难替换
可变状态	需要清理和并发保护	不应出现
并行测试	容易互相污染	纯函数基本安全

所以面试回答不能说“静态一定不好”。更准确的说法是：静态纯工具没问题，静态隐藏依赖和可变状态才麻烦。

五、从依赖管理角度看隐藏成本

如果业务代码到处写 OrderConfig.getInstance().getTimeout()，表面上少传了一个参数，实际是把依赖藏到了方法内部。代码阅读者看方法签名时不知道它依赖配置中心，单元测试也必须准备全局实例。

构造器注入则把依赖摆在明面上：

public class OrderService {
    private final OrderConfig config;

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

假设系统有 30 个服务类依赖同一份配置，容器可以只创建 1 个 OrderConfig 实例并注入 30 次。这既满足共享，又不需要每个业务类硬编码静态入口。共享实例和全局访问是两件事，前者可以由容器完成，后者会增加耦合。

六、面试中如何给出选择标准

回答这题时，可以按 4 个问题判断：

是否需要对象身份：需要统一注册表或缓存索引，才考虑单例。
是否有可变状态：有共享可变状态就必须考虑并发和清理。
是否需要替换：需要 mock、灰度实现或多租户实现时，优先接口和注入。
是否只是纯函数：纯函数集合更适合静态工具类。

例如 Math.max(3, 5) 没必要做成单例；MetricsRegistry 可能需要共享对象；PaymentClient 在 Spring 项目里更适合容器单例；UserSession 因为是请求级状态，既不适合静态工具，也不适合进程级单例。

七、常见误区与追问

误区：单例就是高级一点的静态工具类。 单例是对象身份管理，静态工具类是无状态方法归类，两者解决的问题不同。
误区：静态工具类一定违反面向对象。 纯函数工具没有外部依赖和可变状态时是合理选择。
误区：只要要复用对象就必须写 GoF 单例。 依赖注入容器也能复用同一个实例，并且依赖关系更清楚。
误区：单例比静态方法更容易测试。 如果调用方硬编码 getInstance()，测试隔离仍然困难。
追问：静态工具类为什么通常要 private 构造方法？ 它不代表业务对象，禁止实例化可以表达“只提供类级函数”的意图。
追问：Spring Bean 默认 singleton 是否等于 GoF 单例？ 不等于；Spring 是每个容器、每个 Bean 定义缓存一份对象。
追问：有状态工具类能不能写 static 字段？ 应谨慎；共享可变静态字段会扩大并发和测试污染范围。

八、加强记忆

这题抓住“身份、状态、替换、生命周期”四个词。需要共享对象身份时考虑单例或容器单例；只是无状态计算时用静态工具类；需要替换和测试隔离时优先接口加依赖注入。不要把“少传依赖”和“设计更好”混为一谈。

简化版

详细版