单例模式的核心诉求是让一个类在进程中只存在一个实例，同时提供全局可访问的入口。把构造器声明为private后，外部任何代码试图用new创建对象都会在编译期直接报错，这是语言级别的最强约束。相比之下，仅仅在文档中约定“请只创建一个实例”并没有实际约束力。私有化构造器把实例创建权收回到类内部，类可以决定何时创建、如何创建、是否延迟加载，并且能安全地保存一份全局唯一的状态。本文通过几个可运行的Java示例，展示几种经典实现方式，并说明如何用单例对象管理需要全局共享的变量。
为什么构造器私有化能阻止外部创建实例
在Java中，如果没有显式声明构造器，编译器会默认生成一个public的无参构造器，外部代码可以直接new。一旦将构造器写成private，new操作的访问权限检查就会失败。比如下面的代码：
public class Singleton {
private Singleton() {
}
}
public class Test {
public static void main(String[] args) {
// 编译错误：Singleton() 在 Singleton 中是 private 访问控制
// Singleton s = new Singleton();
}
}构造器私有化并不是把所有创建路径都堵死，而是把“创建”这个动作限制在类内部。类内部仍然可以调用自己的私有构造器，比如在静态方法或静态代码块中完成实例化。反射机制可以突破private限制，但那是刻意绕过语言规范的行为，可以通过额外判断或使用枚举来防御。理解了这一点，就能明白单例模式并不是绝对安全的，它只是将常规创建路径封闭起来，配合其他机制才能达到真正的全局唯一。
私有构造器还有另一个好处：它允许类在创建实例时执行初始化逻辑，而这些逻辑对外部不可见。比如读取配置文件、建立连接池、初始化缓存等。外部拿到的永远是一个已经配置好的完整对象，不需要关心对象是怎么来的。这种封装性为全局状态管理提供了基础。
实战：Java 中几种经典单例实现
单例模式的实现方式很多，不同方式在加载时机、线程安全和内存开销上各有差别。下面从最基础的版本开始，逐步改进。
饿汉式最简单：类加载时就创建实例。因为没有延迟，所以天然线程安全，但可能造成资源浪费。
public class EagerSingleton {
private static final EagerSingleton INSTANCE = new EagerSingleton();
private EagerSingleton() {
}
public static EagerSingleton getInstance() {
return INSTANCE;
}
}饿汉式的问题在于，即使这个单例在程序运行期间从未被使用，实例也会占用内存。对于启动时就需要完成大量初始化的对象，这种做法会拖慢启动速度。
懒汉式延迟到第一次调用getInstance时才创建，但简单的懒汉式在多线程下可能产生多个实例。
public class LazySingleton {
private static LazySingleton instance;
private LazySingleton() {
}
public static LazySingleton getInstance() {
if (instance == null) {
instance = new LazySingleton();
}
return instance;
}
}两个线程同时通过instance == null判断后，都可能执行new操作，导致出现两个不同的实例。为了解决这个问题，可以给方法加synchronized，但每次获取实例都要加锁，性能较差。
双重检查锁是更精细的写法：先检查一次，不加锁；如果为空再进入同步块，二次检查后再创建。为了防止指令重排序导致另一个线程看到未完全初始化的对象，instance字段必须使用volatile修饰。
public class DoubleCheckedSingleton {
private static volatile DoubleCheckedSingleton instance;
private DoubleCheckedSingleton() {
}
public static DoubleCheckedSingleton getInstance() {
if (instance == null) {
synchronized (DoubleCheckedSingleton.class) {
if (instance == null) {
instance = new DoubleCheckedSingleton();
}
}
}
return instance;
}
}双重检查锁在JDK 5之后配合volatile可以正确工作，性能也比较好。但代码结构相对复杂，容易出现漏写volatile或同步块的错误。
静态内部类利用类加载机制实现延迟加载和线程安全，代码更简洁。外部类加载时不会初始化内部类，只有调用getInstance时内部类才会被加载并创建实例。
public class HolderSingleton {
private HolderSingleton() {
}
private static class Holder {
private static final HolderSingleton INSTANCE = new HolderSingleton();
}
public static HolderSingleton getInstance() {
return Holder.INSTANCE;
}
}这种方式不需要显式同步，因为类加载过程本身是线程安全的。相比双重检查锁，代码清晰得多，是实际项目中比较推荐的手写单例方案。
枚举单例是《Effective Java》作者推荐的方式，除了线程安全和防止反射攻击，还能天然防御序列化破坏单例。
public enum EnumSingleton {
INSTANCE;
public void doSomething() {
// 业务方法
}
}枚举类型的实例在Java中由JVM保证全局唯一，构造器默认就是private的。它的缺点是无法继承其他类，也不太适合需要延迟加载的场景，因为枚举实例在类加载时就会被创建。
用单例管理全局唯一的变量状态
单例最常见的用途之一，就是保存程序运行期间的全局配置或状态。比如一个应用可能需要保存当前登录用户、主题样式、数据库连接参数等。把这些信息放在普通对象里，不同模块各自new一个，状态就会产生多份拷贝，A模块修改后B模块读到的还是旧值。通过单例对象，所有模块访问的是同一个内存地址，修改可以立即被其他模块感知。
下面是一个全局配置管理的例子，使用静态内部类方式实现单例，并提供读取和修改配置的方法。
import java.util.HashMap;
import java.util.Map;
public class AppConfig {
private final Map<String, String> configMap = new HashMap<>();
private AppConfig() {
// 初始化默认配置
configMap.put("theme", "light");
configMap.put("lang", "zh-CN");
}
private static class Holder {
private static final AppConfig INSTANCE = new AppConfig();
}
public static AppConfig getInstance() {
return Holder.INSTANCE;
}
public String get(String key) {
return configMap.get(key);
}
public void set(String key, String value) {
configMap.put(key, value);
}
}这段代码中，AppConfig的构造器是私有的，外部无法创建第二个实例。configMap作为实例字段，只会在唯一的INSTANCE中存在一份。任何模块调用AppConfig.getInstance().get("theme")拿到的都是同一份数据。当某个模块调用set修改主题后，其他模块再读取就会得到新值。这种全局唯一状态管理在小型应用或工具类中非常方便，避免了参数层层传递的麻烦。
不过需要注意，单例对象中的可变状态并不是线程安全的。如果多个线程同时读写configMap，HashMap可能会产生并发问题。上面的示例适用于单线程或读多写少且可以接受外部同步的场景。如果需要线程安全，应该将configMap替换为ConcurrentHashMap，或者对get/set方法加锁。
线程安全与序列化破坏单例的坑
单例模式的一个常见误区是认为只要构造器私有化就万事大吉。实际上，即使实现了双重检查锁，仍然有两个容易被忽略的破坏点：反射和序列化。
反射可以通过setAccessible(true)强行调用私有构造器，从而创建第二个实例。防御方式是在构造器中判断实例是否已经存在，存在则抛出异常，但这种方式在静态内部类实现中比较麻烦，因为INSTANCE可能还未赋值。更省心的做法是使用枚举单例，JVM会直接抛出IllegalArgumentException，无法通过反射创建枚举实例。
序列化同样会绕过构造器。一个单例类如果实现了Serializable接口，当它被序列化再反序列化时，会生成一个新的实例，与原单例不是同一个对象。解决方法是添加readResolve方法，在反序列化时返回已存在的单例实例。
import java.io.Serializable;
public class SerializableSingleton implements Serializable {
private static final long serialVersionUID = 1L;
private SerializableSingleton() {
}
private static class Holder {
private static final SerializableSingleton INSTANCE = new SerializableSingleton();
}
public static SerializableSingleton getInstance() {
return Holder.INSTANCE;
}
// 反序列化时返回当前单例，避免产生新实例
private Object readResolve() {
return Holder.INSTANCE;
}
}readResolve方法的机制是：反序列化过程中会创建一个新对象，但在返回给调用方之前，如果类定义了readResolve，返回值会替换掉那个新对象。这样就能保证反序列化后拿到的仍然是原来的单例。枚举单例则不需要这些额外处理，因为枚举的序列化机制本身保证了唯一性。
单例模式的适用场景与替代方案
单例模式适合那些在整个应用生命周期中确实只需要一个实例的对象，比如配置管理器、日志记录器、线程池、缓存等。这些对象如果存在多个实例，可能会造成资源浪费、状态不一致或管理混乱。单例通过全局访问点简化了这些场景下的对象获取方式。
但是，单例模式也常被批评为“反模式”。它引入了全局状态，使代码之间的耦合变得隐蔽。使用单例的类很难进行单元测试，因为无法轻易替换为mock对象。另外，单例的延迟加载和线程安全处理会增加代码复杂度。如果项目规模较大，更推荐使用依赖注入框架（如Spring）来管理bean，框架默认以单例方式创建对象，同时保留了替换和测试的灵活性。
在实际开发中，是否使用单例需要权衡。如果只是简单工具类或小型模块，手写单例完全足够；如果是大型系统，优先考虑容器管理。无论如何，理解构造器私有化这一核心手段，能帮助你在需要时写出正确、可靠的单例代码，并清楚它背后的限制和风险。