Supplier接口本身不替代DCL，但能简化懒汉式单例实现：封装创建逻辑于get()中，首次调用才初始化，配合volatile与双重检查或AtomicReference可实现线程安全懒加载，更轻量、函数式、易组合。
Supplier 接口本身不直接替代双重检查锁（DCL），但它能简化懒汉式单例的实现逻辑，尤其适合需要运行时参数、条件初始化或统一懒加载语义的场景。它不是“新写法”的替代方案，而是提供了一种更轻量、更函数式、更易组合的延迟创建方式。
Supplier 本质是延迟执行的创建动作封装
Supplier
- 避免重复编写 DCL 模板代码，减少出错风险（比如漏掉 volatile）
- 创建逻辑可依赖运行时状态，比如从配置中心读取参数后再初始化数据库连接池
- 便于与 Optional、Stream 等 API 组合，例如 Optional.ofNullable(cache).orElseGet(() -> initCache())
用 Supplier 实现线程安全的懒加载单例（非严格单例，但语义等效）
单纯用 Supplier
- 最简实用方式：用 AtomicReference
> + computeIfAbsent（Java 8+），或用 ConcurrentHashMap.computeIfAbsent 存储已初始化实例 - 推荐封装为工具类，如 Lazy
：内部用 volatile holder + synchronized 初始化块，对外暴露 get() 方法，内部委托给 Supplier - 示例片段：private static final Lazy
CONNECTION = Lazy.of(() -> new DatabaseConnection(config)); ，之后调用 CONNECTION.get() 即可，线程安全且延迟
对比传统 DCL，Supplier 方式更适合哪些场景
它不追求“JVM 层级绝对单例”（如防反射/反序列化），而聚焦“业务层按需、安全、可组合地获取唯一实例”。适合：
立即学习“Java免费学习笔记（深入）”；
- 配置驱动型对象：实例化依赖外部配置、环境变量或 Spring Bean，饿汉式无法满足，DCL 写起来又冗长
- 测试友好：Supplier 可被 mock 或替换为测试桩，避免静态字段带来的隔离难题
- 模块化构建：多个组件各自用 Supplier 封装其核心服务，再由主容器统一 resolve，比硬编码 DCL 更松耦合
注意边界：Supplier 不等于枚举或静态内部类的强安全性
它不解决反射攻击、序列化破坏等问题。若需最高级别单例保障（如敏感系统管理器），仍应优先选枚举单例；若仅需“首次使用才创建 + 多线程不重复创建”，Supplier 配合原子操作已足够稳健，且代码更简洁、意图更清晰。
