volatile确保DCL中对象初始化的可见性与有序性，防止重排序导致未初始化对象被访问；两次判空分别用于性能优化与线程安全；synchronized锁Singleton.class保证互斥。
volatile 保证对象初始化的可见性和有序性
在双重检查锁（DCL）中，volatile 不是用来加锁的，而是解决两个关键并发问题：指令重排序和内存可见性。
new Singleton() 实际包含三步：① 分配内存；② 初始化对象；③ 将引用指向该内存。没有 volatile 时，JVM 或 CPU 可能将步骤②和③重排序——先让 instance 指向一块未初始化完成的内存地址。此时另一个线程看到 instance != null，就直接返回并使用，结果调用未初始化的对象，抛出 NullPointerException 或行为异常。
volatile 强制这三步按序执行，同时确保一旦 instance 被写入，所有线程都能立即看到最新值，不会因本地工作内存缓存而读到过期的 null。
双重检查锁的两次判断各司其职
第一次判断（无锁）：快速拦截已创建实例的请求，避免每次调用都进同步块，提升高并发下的性能。
立即学习“Java免费学习笔记（深入）”；
第二次判断（加锁后）：防止多个线程“同时通过第一次判断”，抢到锁后重复创建实例。即使线程 A 刚创建完、刚释放锁，线程 B 紧接着拿到锁，也必须再次确认 instance 是否仍为 null——此时它会发现已有实例，直接返回，不再 new。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
这两个 if 缺一不可：只留第一个，不安全；只留第二个，失去性能优化意义。
synchronized 锁的是类对象，不是实例
getInstance 是静态方法，锁的目标必须是类本身，即 Singleton.class。每个类在 JVM 中有且仅有一个 Class 对象，所有线程竞争同一把锁，才能真正互斥。
不能写成 synchronized(this)，因为 this 在 getInstance 中还不存在；也不能用 new Object() 作为锁对象，那样不同线程可能持不同锁，起不到同步作用。
完整写法与关键细节
标准实现需同时满足三点：
- instance 声明为 private static volatile Singleton instance
- 构造方法私有：private Singleton() {}（防止反射攻击可加枚举或校验）
- getInstance 方法内严格按“判空→加锁→再判空→创建→返回”顺序，不可省略任一环
从 JDK 1.5 起，volatile 的语义增强才使 DCL 真正可靠；旧版本存在内存模型缺陷，不推荐使用。
