数字世界的“唯一身份证“——单例模式

想象一家跨国集团只能有一位CEO，所有重大决策必须通过他签署。单例模式就是这个原理：确保系统中只有一个决策核心。无论市场部要预算，还是研发部要资源，都必须通过这位唯一的CEO，避免多头决策导致管理混乱。

一、单例模式的核心特质

其核心特征可概括为三大铁律：

• 唯一实例原则：单例类必须确保在任何时刻只有一个实例存在
• 自主创建权：通过私有构造方法禁止外部随意创建对象
• 全局访问点：通过静态方法getInstance()提供统一的访问入口

模式演化论：从"即刻生产"到"按需供给"

基于不同的资源管理策略，单例模式发展出两大经典流派： “饿汉模式” 和 “懒汉模式”

二、饿汉模式 & 懒汉模式

饿汉式：雷厉风行的执行者

代码实现

public class EagerCEO {
    // 公司成立时直接任命CEO
    private static final EagerCEO instance = new EagerCEO();
    
    // 禁止外部招聘CEO
    private EagerCEO() {}
    
    // 董事会获取CEO联系方式
    public static EagerCEO getInstance() {
        return instance;
    }
}

核心特征

• 类加载时立即创建实例（公司注册时确定CEO人选）
• 天然线程安全（公司章程保障人事稳定）
• 适用于高频访问的核心服务（如财务系统）

懒汉式：精打细算的财务官

双重检查锁标准版

public class LazyCFO {
    // volatile防止指令重排序
    private static volatile LazyCFO instance;
    
    private LazyCFO() {}
    
    public static LazyCFO getInstance() {
        if (instance == null) {          // 第一关：快速安检
            synchronized (LazyCFO.class) {
                if (instance == null) {  // 第二关：深度核查
                    instance = new LazyCFO();
                }
            }
        }
        return instance;
    }
}

设计精妙处

• 第一层判断避免每次加锁（减少90%的锁竞争）
• 第二层判断拦截漏网之鱼（杜绝重复创建）
• synchronized ：当多个线程同时调用getInstance()时，synchronized确保同一时间只有一个线程能进入同步代码块
• volatile：保证对象完整初始化（防止拿到半成品）

静态内部类实现懒汉模式

public class LazyCFO {
    private LazyCFO() {}
    
    private static class CEOHolder {
        static final LazyCFO INSTANCE = new LazyCFO();
    }
    
    public static LazyCFO getInstance() {
        return CEOHolder.INSTANCE;
    }
}

设计精妙之处

• 类加载机制保障线程安全（JVM在加载静态内部类CEOHolder时，会自动加锁保证线程安全）
• 延迟加载与资源优化（首次调用getInstance()才会加载内部类）

三、反射攻击：黑客的万能钥匙

破解演示

public class HackAttack {
    public static void main(String[] args) throws Exception {
        // 获取正牌CEO
        EagerCEO realCEO = EagerCEO.getInstance();
        
        // 反射伪造CEO
        Class<?> clazz = Class.forName("EagerCEO");
        Constructor<?> constructor = clazz.getDeclaredConstructor();
        constructor.setAccessible(true); // 撬开私有构造锁
        EagerCEO fakeCEO = (EagerCEO) constructor.newInstance();
        
        System.out.println("正牌CEO：" + realCEO.hashCode());
        System.out.println("伪造CEO：" + fakeCEO.hashCode());
        System.out.println("是否同一人？" + (realCEO == fakeCEO));
    }
}

/* 输出结果：
正牌CEO：356573597
伪造CEO：1735600054
是否同一人？false */

攻击原理

• 反射API可突破private访问限制
• 绕开getInstance()直接调用构造器
• 导致内存中出现多个"CEO"实例

四、防反射机制：两大终极防御

1. 构造方法 防御法

public class SafeCEO {
    private static boolean flag = false;
    private static final SafeCEO instance = new SafeCEO();
    
    private SafeCEO() {
        if (flag) { // 发现非法闯入者
            throw new RuntimeException("禁止私自任命CEO！");
        }
        flag = true; // 首次构造标记合法
    }
    
    public static SafeCEO getInstance() {
        return instance;
    }
}

防御原理：

• 通过状态标记检测二次创建
• 首次构造时设置flag=true
• 后续反射调用会触发异常警报

2. 枚举 防御法

public enum EnumCEO {
    INSTANCE;
    
    public void signDocument() {
        System.out.println("文件已签署");
    }
}

无敌特性：

• JVM保证枚举实例唯一性
• 反射API无法实例化枚举类
• 天然防御序列化/反射攻击

五、单例实战场景：职场生存指南

1、全局配置中心

典型场景：应用启动时加载application.properties配置文件，所有模块共享同一份配置数据

// 饿汉式实现（线程安全）
public class AppConfig {
    private static final AppConfig INSTANCE = new AppConfig();
    private Properties configs = new Properties();

    private AppConfig() {
        try (InputStream is = getClass().getResourceAsStream("/config.properties")) {
            configs.load(is); // 单次加载配置文件
        } catch (IOException e) {
            throw new RuntimeException("配置文件加载失败", e);
        }
    }
    
    public static AppConfig getInstance() {
        return INSTANCE;
    }
    
    public String getDBUrl() {
        return configs.getProperty("db.url");
    }
}

技术要点：

• 饿汉式保证配置在类加载时初始化，避免多线程竞争
• 私有构造方法防止外部实例化（符合单例三原则）

2、日志记录中枢

典型场景：多线程环境下需要保证日志写入顺序

// 双重检查锁实现（线程安全）
public class Logger {
    private static volatile Logger instance;
    private FileWriter writer;
    
    private Logger() {
        try {
            writer = new FileWriter("app.log", true); // 保持文件持续打开
        } catch (IOException e) {
            throw new RuntimeException("日志文件初始化失败", e);
        }
    }
    
    public static Logger getInstance() {
        if (instance == null) {
            synchronized (Logger.class) {
                if (instance == null) {
                    instance = new Logger();
                }
            }
        }
        return instance;
    }
    
    public synchronized void log(String message) {
        try {
            writer.write(LocalDateTime.now() + " : " + message + "\n");
            writer.flush();
        } catch (IOException e) {
            System.err.println("日志写入失败: " + e.getMessage());
        }
    }
}

优化点：

• volatile防止指令重排序导致对象未初始化完成
• 同步写操作保证日志顺序一致性

六、模式选择指南

场景特征	推荐方案	技术优势
高频访问	饿汉式	系统配置中心
资源敏感	懒汉式（双重检查）	数据库连接池
安全要求极高	枚举式	金融交易系统
需要延迟加载	静态内部类	插件管理系统

职场经验：在Spring框架中，优先使用@Bean的单例作用域而非手动实现，既保证线程安全又方便管理 。但需注意不要滥用单例，对于需要保持会话状态的服务，应选用原型(prototype)作用域。