单例模式是设计模式中最基础也最容易被误用的一种。它的目标很明确：让某个类在整个程序生命周期中只存在一个实例，并提供一个全局访问点。要实现这个目标，第一步往往不是写获取实例的方法，而是把构造器藏起来。一旦构造器被私有化，外部代码就无法通过new关键字随意创建对象，实例的唯一性也就有了制度上的保障。本文围绕构造器私有化展开，完整拆解单例模式的多种实现方式，并延伸讨论如何在这种结构下管理全局唯一的变量状态。
构造器私有化为什么是单例的基石
先看一个反例。假设有一个AppConfig类，负责加载系统配置文件，如果它的构造器是公开的，任何地方都可以new AppConfig()，每次实例化都会重新读取配置文件，不仅浪费资源，还可能因为加载时序不同导致不同对象持有的配置内容不一致。业务代码在A处拿到的配置和在B处拿到的配置对不上，排查起来非常麻烦。
把构造器声明为私有后，情况就完全不同了。此时类的实例化权力被收回到类自身手中，外部想获取实例，只能走类提供的静态入口方法。这个入口方法内部可以精确控制：实例不存在就创建一次，存在就直接返回。这样一来，实例的唯一性由类本身保证，而不依赖调用方的自觉。
除了私有构造器，单例通常还需要注意两点：一是实例变量用static修饰，让它归属于类而非对象；二是防止通过反射强行调用私有构造器绕过限制，必要时可以在构造器中加一道判断。下面这段Java代码是最经典的饿汉式写法：
public class AppConfig {
// 类加载时就创建实例，天然线程安全
private static final AppConfig INSTANCE = new AppConfig();
// 构造器私有化，外部无法 new
private AppConfig() {
// 可加防御逻辑：防止反射重复实例化
if (INSTANCE != null) {
throw new IllegalStateException("实例已存在，禁止重复创建");
}
}
// 全局唯一访问入口
public static AppConfig getInstance() {
return INSTANCE;
}
}饿汉式的优点是简单且绝对线程安全，缺点是类加载时实例就已存在，如果这个单例占用资源较多却长期没被用到，就造成了浪费。是否可接受，要看具体业务场景。
懒汉式与双重检查锁：延迟加载的进阶写法
如果希望实例在第一次被使用时才创建，就需要懒汉式。最朴素的写法是给getInstance方法加synchronized，但这样每次调用都要竞争锁，高并发下性能损耗明显。更优的方案是双重检查锁（DCL），只在实际创建实例的临界时刻加锁：
public class LazySingleton {
// volatile 防止指令重排序
private static volatile LazySingleton instance;
private LazySingleton() {}
public static LazySingleton getInstance() {
if (instance == null) { // 第一次检查，避免不必要的加锁
synchronized (LazySingleton.class) {
if (instance == null) { // 第二次检查，防止重复创建
instance = new LazySingleton();
}
}
}
return instance;
}
}这里有个细节必须强调：实例字段一定要加volatile。new操作并非原子性的，它分为分配内存、初始化对象、引用赋值三步，如果没有volatile禁止指令重排，另一个线程可能拿到一个已分配内存但尚未初始化完成的对象，使用时就会出错。这类问题在测试环境很难复现，上线后却可能偶发崩溃，是典型的隐蔽陷阱。
如果觉得DCL写法繁琐，静态内部类是更优雅的替代方案。它利用Java类加载机制：外部类加载时内部类不会立即加载，只有在第一次调用getInstance时内部类才被初始化，既做到了延迟加载，又借助类加载锁保证了线程安全：
public class HolderSingleton {
private HolderSingleton() {}
private static class Holder {
private static final HolderSingleton INSTANCE = new HolderSingleton();
}
public static HolderSingleton getInstance() {
return Holder.INSTANCE;
}
}三种方案对比下来：饿汉式胜在简单可靠，DCL适合实例创建开销大且并发高的场景，静态内部类则是两者折中的推荐写法。选择时不必纠结，多数业务系统用静态内部类就足够了。
其他语言中的构造器私有化实现
构造器私有化并非Java的专利。Python中没有真正的private关键字，惯用做法是在构造方法名前加双下划线，配合一个模块级的访问函数：
class ConfigManager:
__instance = None
def __init__(self):
# 双下划线方法名触发名称改写，外部难以直接构造
if ConfigManager.__instance is not None:
raise RuntimeError("请使用 get_instance() 获取实例")
self.settings = {}
@classmethod
def get_instance(cls):
if cls.__instance is None:
cls.__instance = cls()
return cls.__instance
config = ConfigManager.get_instance()JavaScript在ES6之后可以用模块缓存或闭包实现类似效果。由于ES Module本身就是单例语义，最简单的做法是直接导出一个Object.freeze冻结的对象，配合私有字段语法阻止外部重建：
// configManager.js
class ConfigManager {
static #instance = null;
constructor() {
if (ConfigManager.#instance) {
throw new Error("请使用 ConfigManager.getInstance()");
}
this.state = {};
ConfigManager.#instance = this;
}
static getInstance() {
if (!this.#instance) {
new ConfigManager();
}
return this.#instance;
}
}
export default ConfigManager.getInstance();无论哪种语言，思路都是一致的：封住创建入口，开放受控的访问入口。语言层面的差异只是实现手段不同。
单例中的全局状态管理注意事项
单例模式最大的争议点不在实现，而在它承载的全局状态。状态放对了地方能省去大量参数传递，放错了就会变成灾难。实践中建议遵循几条原则：第一，单例内部的可变状态要尽量少，能 immutable 就不要 mutable；第二，如果必须有可变字段，一定要考虑线程安全，例如用ConcurrentHashMap代替普通HashMap，用AtomicReference或volatile保证可见性。
下面是一个数据库连接池管理器的简化示例，展示了如何在单例中安全地维护共享状态：
public class ConnectionPool {
private static class Holder {
private static final ConnectionPool POOL = new ConnectionPool();
}
private final Map<String, Connection> pool = new ConcurrentHashMap<>();
private ConnectionPool() {}
public static ConnectionPool getInstance() {
return Holder.POOL;
}
public Connection getConnection(String key) {
// computeIfAbsent 保证同一 key 的连接只创建一次
return pool.computeIfAbsent(key, k -> createNewConnection(k));
}
private Connection createNewConnection(String key) {
// 实际场景中加载驱动、建立连接
return null;
}
}最后需要提醒的是，单例会让单元测试变麻烦，因为状态在测试之间共享且难以重置。常见解法是给单例留一个包私有的重置方法供测试使用，或者把状态抽取到独立的可注入对象中，单例只做薄薄的一层壳。这样既保留了全局访问的便利，又保留了测试的灵活性。总的来说，构造器私有化只是技术手段，真正决定代码质量的是你如何设计单例里那份全局唯一的状态。