Java中的volatile关键字 —— 从内存可见性到DCL单例文章目录Java中的volatile关键字 —— 从内存可见性到DCL单例前言一、Java内存模型JMM基础1.1 主内存与工作内存1.2 可见性问题演示二、volatile保证内存可见性2.1 加上volatile后的效果2.2 可见性的底层实现三、volatile禁止指令重排序3.1 什么是指令重排序3.2 volatile如何禁止重排序3.3 一个更直观的例子四、volatile不保证原子性volatile vs synchronized五、经典案例DCL单例模式5.1 单例模式的演进5.2 new操作的秘密5.3 volatile修复DCL5.4 其他单例实现方式六、volatile适用场景总结volatile的happens-before规则总结✅ 亮点总结适用场景扩展方向前言在Java并发编程中volatile是理解难度仅次于synchronized的关键字。很多开发者知道它用于保证变量的可见性但对禁止指令重排这一特性以及它在DCLDouble-Checked Locking单例中的关键作用往往一知半解。面试中经常出现这样的对话面试官问volatile有什么用候选人答保证可见性面试官追问还有呢候选人就答不上来了。volatile之所以难以理解是因为它背后涉及了Java内存模型JMM、CPU缓存一致性、指令重排优化等多个底层概念。只有将这几点串联起来才能真正理解volatile的设计意图和使用边界。很多线上并发bug的根源都是开发者误以为volatile可以替代synchronized——给它加上了本不该有的原子性期望。本文将从JMMJava内存模型出发深入解析volatile的三大特性内存可见性、禁止指令重排序以及不保证原子性最后以DCL单例的经典案例收尾帮助你建立对volatile完整而准确的认识。一、Java内存模型JMM基础要理解volatile必须先理解Java内存模型Java Memory ModelJMM。1.1 主内存与工作内存线程A 主内存 线程B ┌────────┐ ┌──────────┐ ┌────────┐ │ flag │ │ flag 0 │ │ │ │ (0) │ │ 所有线程 │ │ flag │ │ │ │ 共享的 │ │ (0) │ │ 本地 │ │ 变量副本 │ │ 本地 │ │ 缓存 │ └──────────┘ │ 缓存 │ └────────┘ └────────┘JMM规定所有变量存储在主内存中每条线程有自己的工作内存类似于CPU缓存线程对变量的所有操作必须在工作内存中进行不能直接读写主内存不同线程之间无法直接访问对方的工作内存1.2 可见性问题演示下面的代码演示了一个经典的可见性问题。这个问题在JIT优化和特定CPU架构下会真实发生——不仅仅局限于理论层面。publicclassVisibilityProblem{// 没有volatile修饰线程B可能永远看不到线程A对flag的修改privatestaticbooleanflagfalse;publicstaticvoidmain(String[]args)throwsInterruptedException{newThread(()-{System.out.println(线程A准备修改flag);try{Thread.sleep(1000);}catch(InterruptedExceptione){}flagtrue;System.out.println(线程Aflag已修改为true);},线程A).start();newThread(()-{System.out.println(线程B开始等待flag...);while(!flag){// 线程B的工作内存中可能缓存了flag的旧值// 导致即使线程A修改了flag循环也无法退出// 这在某些JVM实现和CPU架构下确实会发生}System.out.println(线程B检测到flag变化退出循环);},线程B).start();}}为什么线程B可能看不到修改这背后有两种机制在共同起作用。线程B可能在读取了flag的值到CPU缓存JIT编译器将while循环优化为if(!flag) { while(true) {} }导致线程B的工作内存永远不和主内存同步补充说明你可能会发现这个代码在某些机器上跑得通——线程B能正常退出。这恰恰说明了可见性问题的概率性它取决于CPU架构、JIT的优化策略、甚至是系统负载。并发编程最危险的地方就在于——有问题的代码不是每次都出错而是在最不应该出错的生产环境中才暴露出来。二、volatile保证内存可见性2.1 加上volatile后的效果为变量添加volatile后JMM保证写操作线程修改volatile变量后立即刷新到主内存读操作线程读取volatile变量时必须从主内存重新读取publicclassVolatileVisibility{privatestaticvolatilebooleanflagfalse;publicstaticvoidmain(String[]args)throwsInterruptedException{newThread(()-{System.out.println(线程A准备修改flag);try{Thread.sleep(1000);}catch(InterruptedExceptione){}flagtrue;// 写操作 → 立即刷新到主内存System.out.println(线程Aflag已修改为true);},线程A).start();newThread(()-{System.out.println(线程B开始等待flag...);while(!flag){// 读操作 → 每次从主内存重新读取// 一定能看到线程A的修改}System.out.println(线程B检测到flag变化退出循环);},线程B).start();}}2.2 可见性的底层实现volatile的可见性是通过**内存屏障Memory Barrier**实现的// volatile写操作前插入 StoreStore 屏障// volatile写操作后插入 StoreLoad 屏障// volatile读操作前插入 LoadLoad 屏障// volatile读操作后插入 LoadStore 屏障// 伪代码表示volatile的读写//// volatile写// 插入 StoreStore 屏障// 写入 volatile 变量// 插入 StoreLoad 屏障确保本次写对后续读可见//// volatile读// 插入 LoadLoad 屏障// 读取 volatile 变量// 插入 LoadStore 屏障汇编层面volatile的写操作对应着Lock前缀指令该指令会将当前处理器缓存行写回系统内存这个写回操作会使其他CPU核心缓存了该地址的数据失效当其他核心再访问该地址时必须从系统内存重新获取三、volatile禁止指令重排序3.1 什么是指令重排序编译器、JIT、甚至CPU都可能为了优化性能对指令顺序进行重新排列。重排序遵循as-if-serial原则——单线程下执行结果不变但多线程可能出现问题。publicclassReorderExample{privateinta0;privatebooleanreadyfalse;// 线程1执行publicvoidwriter(){a1;// 操作1readytrue;// 操作2// CPU可能先执行操作2再执行操作1}// 线程2执行publicvoidreader(){if(ready){// 看到readytrueintresulta;// 但a可能还是0重排序导致System.out.println(a result);}}}3.2 volatile如何禁止重排序publicclassVolatileReorderPrevention{privateinta0;privatevolatilebooleanreadyfalse;publicvoidwriter(){a1;// 不能重排到readytrue之后readytrue;// volatile写确保前序操作已完成}publicvoidreader(){if(ready){// volatile读确保后序操作在它之后intresulta;// 一定能看到a1System.out.println(a result);// 始终输出 a 1}}}volatile的重排序规则volatile读volatile写前一个操作的结果后不会重排前不会重排后一个操作的结果前不会重排后会重排通俗理解volatile写之前的操作不会重排到写之后前面的不能跑到后面volatile读之后的操作不会重排到读之前后面的不能跑到前面3.3 一个更直观的例子publicclassVolatileBarrierDemo{intx0;volatilebooleanvfalse;publicvoidthread1(){x42;// ① 普通写vtrue;// ② volatile写// 内存屏障保证①一定在②之前执行}publicvoidthread2(){if(vtrue){// ③ volatile读// 内存屏障保证如果看到vtrue则x42已完成System.out.println(x);// ④ 一定输出42}}}四、volatile不保证原子性这是volatile最容易误解的地方。volatile保证可见性但不保证原子性。publicclassVolatileAtomicity{privatestaticvolatileintcount0;publicstaticvoidmain(String[]args)throwsInterruptedException{Thread[]threadsnewThread[10];for(inti0;i10;i){threads[i]newThread(()-{for(intj0;j1000;j){count;// 非原子操作// count 是三个步骤读 → 加1 → 写// 线程A读到0还没写回线程B也读到0// 两个线程各加1写回count还是1而不是2}});threads[i].start();}for(Threadt:threads){t.join();}System.out.println(期望值: 10000, 实际值: count);// 实际值常小于10000}}volatile vs synchronizedpublicclassVolatileVsSynchronized{privatevolatileintvCount0;privateintsCount0;// volatile不能保证原子性publicvoidincrementVolatile(){vCount;// 非线程安全}// synchronized保证原子性publicsynchronizedvoidincrementSynchronized(){sCount;// 线程安全}// volatile适用的场景1状态标志privatevolatilebooleanshutdownfalse;publicvoidshutdown(){shutdowntrue;}// volatile适用的场景2单次赋值privatevolatileMyConfigconfig;publicvoidinit(){confignewMyConfig();// 一次性赋值没有读-改-写}}五、经典案例DCL单例模式DCLDouble-Checked Locking单例是volatile最关键的应用场景之一。5.1 单例模式的演进// 版本1懒汉式线程不安全publicclassSingletonV1{privatestaticSingletonV1instance;privateSingletonV1(){}publicstaticSingletonV1getInstance(){if(instancenull){// ①instancenewSingletonV1();// ② 线程不安全}returninstance;}}// 版本2加synchronized性能差publicclassSingletonV2{privatestaticSingletonV2instance;privateSingletonV2(){}publicstaticsynchronizedSingletonV2getInstance(){if(instancenull){instancenewSingletonV2();}returninstance;}// 问题每次获取都要同步即使对象已经创建好了}// 版本3DCL双重检查锁定仍有问题publicclassSingletonV3{privatestaticSingletonV3instance;// 注意没有volatileprivateSingletonV3(){}publicstaticSingletonV3getInstance(){if(instancenull){// 第一次检查synchronized(SingletonV3.class){if(instancenull){// 第二次检查instancenewSingletonV3();// 问题在这里}}}returninstance;}// 问题instance new SingletonV3() 不是原子操作}5.2 new操作的秘密这是理解DCL为什么需要volatile的关键。看似简单的new操作在JVM层面上其实是多个步骤的组合。instance new SingletonV3()这一行代码在JVM中实际分解为三个步骤// 步骤①分配内存空间memoryallocate();// 步骤②初始化对象调用构造函数constructInstance(memory);// 步骤③将 instance 指向内存地址instancememory;由于指令重排序步骤②和③的顺序可能交换正常顺序① → ② → ③ 重排后① → ③ → ②如果重排后线程A执行到步骤③instance已非null但未初始化此时线程B进入getInstance()发现instance ! null直接返回一个未初始化完毕的对象导致灾难性后果。这个场景不是理论上的在早期JDK版本1.4及以前的某些实现中指令重排确实可能导致DCL出现问题。这也是为什么DCL曾经被称为反模式——直到JDK 5引入volatile的happens-before语义后DCLvolatile组合才真正变得安全可靠。5.3 volatile修复DCLpublicclassSingletonDCL{// volatile 禁止指令重排序问题解决privatestaticvolatileSingletonDCLinstance;privateSingletonDCL(){// 私有构造器System.out.println(Singleton 初始化);}publicstaticSingletonDCLgetInstance(){if(instancenull){// 第一次检查无锁synchronized(SingletonDCL.class){if(instancenull){// 第二次检查有锁instancenewSingletonDCL();// volatile 保证有序}}}returninstance;}publicvoiddoSomething(){System.out.println(执行业务逻辑: this.hashCode());}}// 测试publicclassDCLTest{publicstaticvoidmain(String[]args){for(inti0;i10;i){newThread(()-{SingletonDCLinstanceSingletonDCL.getInstance();instance.doSomething();}).start();}}}5.4 其他单例实现方式// 方式1静态内部类推荐利用类加载机制的线程安全publicclassSingletonHolder{privateSingletonHolder(){}privatestaticclassHolder{privatestaticfinalSingletonHolderINSTANCEnewSingletonHolder();}publicstaticSingletonHoldergetInstance(){returnHolder.INSTANCE;}}// 方式2枚举最安全防反射、防序列化破坏publicenumSingletonEnum{INSTANCE;publicvoiddoSomething(){System.out.println(枚举单例执行);}}六、volatile适用场景总结场景是否适用说明状态标志位✅ 适用如 shutdown、initialized 标志一次性安全发布✅ 适用DCL单例中的instance独立观察✅ 适用定期发布温度、配置等信息volatile bean✅ 适用简单JavaBeangetter/setter读-改-写操作❌ 不适用count 需要synchronized复合操作❌ 不适用if条件判断 赋值需要原子性volatile的happens-before规则// volatile变量的写操作 happens-before 后续对该变量的读操作// 也就是说读操作一定能看到写操作的结果volatilebooleanflagfalse;// 线程A先执行flagtrue;// volatile写// 线程B后执行if(flag){// volatile读 —— 一定能看到true// 此处flag之前的所有共享变量修改都可见}总结volatile的关键特性可以概括为两点半保证内存可见性一个线程修改后其他线程立即可见禁止指令重排序通过内存屏障保证有序性2.5.不保证原子性复合操作如count仍然需要加锁这三个特性中前两个让volatile成为轻量级的同步机制而第三个局限决定了它只能用在特定场景。正确使用volatile的关键在于只把它用在简单赋值的场景凡是涉及先检查再修改的操作请老老实实地用synchronized或者Lock。DCL单例是volatile的经典应用它完美展示了volatile禁止指令重排的重要性。理解了DCL的问题和volatile的修复方案你就真正理解了volatile的核心价值。✅ 亮点总结JMM主内存与工作内存模型线程不能直读主内存volatile确保每次读写都经过主内存volatile保证内存可见性的底层实现内存屏障StoreStore/LoadLoad与Lock前缀指令缓存行失效volatile禁止指令重排序的规则写之前的操作不能重排到写之后读之后的操作不能重排到读之前volatile不保证原子性的确切边界简单赋值flagtrue安全复合操作count仍需要同步DCL单例的问题根源——new操作的三个步骤分配→初始化→赋值可能被重排volatile禁止此重排适用场景线程间状态标志传递如shutdown、initialized等布尔开关一次性安全发布的配置对象配置初始化后对所有线程可见DCL单例模式中instance字段的正确声明防止指令重排导致的半初始化对象泄漏扩展方向深入学习JMM的happens-before规则体系建立并发代码正确性的理论基础研究JUC原子类AtomicInteger/LongAdder的CAS无锁并发实现推荐阅读[21_Java IO流体系详解](./21_Java IO流体系详解.md)下一篇[21_Java IO流体系详解](./21_Java IO流体系详解.md)
20_Java中的volatile关键字
Java中的volatile关键字 —— 从内存可见性到DCL单例文章目录Java中的volatile关键字 —— 从内存可见性到DCL单例前言一、Java内存模型JMM基础1.1 主内存与工作内存1.2 可见性问题演示二、volatile保证内存可见性2.1 加上volatile后的效果2.2 可见性的底层实现三、volatile禁止指令重排序3.1 什么是指令重排序3.2 volatile如何禁止重排序3.3 一个更直观的例子四、volatile不保证原子性volatile vs synchronized五、经典案例DCL单例模式5.1 单例模式的演进5.2 new操作的秘密5.3 volatile修复DCL5.4 其他单例实现方式六、volatile适用场景总结volatile的happens-before规则总结✅ 亮点总结适用场景扩展方向前言在Java并发编程中volatile是理解难度仅次于synchronized的关键字。很多开发者知道它用于保证变量的可见性但对禁止指令重排这一特性以及它在DCLDouble-Checked Locking单例中的关键作用往往一知半解。面试中经常出现这样的对话面试官问volatile有什么用候选人答保证可见性面试官追问还有呢候选人就答不上来了。volatile之所以难以理解是因为它背后涉及了Java内存模型JMM、CPU缓存一致性、指令重排优化等多个底层概念。只有将这几点串联起来才能真正理解volatile的设计意图和使用边界。很多线上并发bug的根源都是开发者误以为volatile可以替代synchronized——给它加上了本不该有的原子性期望。本文将从JMMJava内存模型出发深入解析volatile的三大特性内存可见性、禁止指令重排序以及不保证原子性最后以DCL单例的经典案例收尾帮助你建立对volatile完整而准确的认识。一、Java内存模型JMM基础要理解volatile必须先理解Java内存模型Java Memory ModelJMM。1.1 主内存与工作内存线程A 主内存 线程B ┌────────┐ ┌──────────┐ ┌────────┐ │ flag │ │ flag 0 │ │ │ │ (0) │ │ 所有线程 │ │ flag │ │ │ │ 共享的 │ │ (0) │ │ 本地 │ │ 变量副本 │ │ 本地 │ │ 缓存 │ └──────────┘ │ 缓存 │ └────────┘ └────────┘JMM规定所有变量存储在主内存中每条线程有自己的工作内存类似于CPU缓存线程对变量的所有操作必须在工作内存中进行不能直接读写主内存不同线程之间无法直接访问对方的工作内存1.2 可见性问题演示下面的代码演示了一个经典的可见性问题。这个问题在JIT优化和特定CPU架构下会真实发生——不仅仅局限于理论层面。publicclassVisibilityProblem{// 没有volatile修饰线程B可能永远看不到线程A对flag的修改privatestaticbooleanflagfalse;publicstaticvoidmain(String[]args)throwsInterruptedException{newThread(()-{System.out.println(线程A准备修改flag);try{Thread.sleep(1000);}catch(InterruptedExceptione){}flagtrue;System.out.println(线程Aflag已修改为true);},线程A).start();newThread(()-{System.out.println(线程B开始等待flag...);while(!flag){// 线程B的工作内存中可能缓存了flag的旧值// 导致即使线程A修改了flag循环也无法退出// 这在某些JVM实现和CPU架构下确实会发生}System.out.println(线程B检测到flag变化退出循环);},线程B).start();}}为什么线程B可能看不到修改这背后有两种机制在共同起作用。线程B可能在读取了flag的值到CPU缓存JIT编译器将while循环优化为if(!flag) { while(true) {} }导致线程B的工作内存永远不和主内存同步补充说明你可能会发现这个代码在某些机器上跑得通——线程B能正常退出。这恰恰说明了可见性问题的概率性它取决于CPU架构、JIT的优化策略、甚至是系统负载。并发编程最危险的地方就在于——有问题的代码不是每次都出错而是在最不应该出错的生产环境中才暴露出来。二、volatile保证内存可见性2.1 加上volatile后的效果为变量添加volatile后JMM保证写操作线程修改volatile变量后立即刷新到主内存读操作线程读取volatile变量时必须从主内存重新读取publicclassVolatileVisibility{privatestaticvolatilebooleanflagfalse;publicstaticvoidmain(String[]args)throwsInterruptedException{newThread(()-{System.out.println(线程A准备修改flag);try{Thread.sleep(1000);}catch(InterruptedExceptione){}flagtrue;// 写操作 → 立即刷新到主内存System.out.println(线程Aflag已修改为true);},线程A).start();newThread(()-{System.out.println(线程B开始等待flag...);while(!flag){// 读操作 → 每次从主内存重新读取// 一定能看到线程A的修改}System.out.println(线程B检测到flag变化退出循环);},线程B).start();}}2.2 可见性的底层实现volatile的可见性是通过**内存屏障Memory Barrier**实现的// volatile写操作前插入 StoreStore 屏障// volatile写操作后插入 StoreLoad 屏障// volatile读操作前插入 LoadLoad 屏障// volatile读操作后插入 LoadStore 屏障// 伪代码表示volatile的读写//// volatile写// 插入 StoreStore 屏障// 写入 volatile 变量// 插入 StoreLoad 屏障确保本次写对后续读可见//// volatile读// 插入 LoadLoad 屏障// 读取 volatile 变量// 插入 LoadStore 屏障汇编层面volatile的写操作对应着Lock前缀指令该指令会将当前处理器缓存行写回系统内存这个写回操作会使其他CPU核心缓存了该地址的数据失效当其他核心再访问该地址时必须从系统内存重新获取三、volatile禁止指令重排序3.1 什么是指令重排序编译器、JIT、甚至CPU都可能为了优化性能对指令顺序进行重新排列。重排序遵循as-if-serial原则——单线程下执行结果不变但多线程可能出现问题。publicclassReorderExample{privateinta0;privatebooleanreadyfalse;// 线程1执行publicvoidwriter(){a1;// 操作1readytrue;// 操作2// CPU可能先执行操作2再执行操作1}// 线程2执行publicvoidreader(){if(ready){// 看到readytrueintresulta;// 但a可能还是0重排序导致System.out.println(a result);}}}3.2 volatile如何禁止重排序publicclassVolatileReorderPrevention{privateinta0;privatevolatilebooleanreadyfalse;publicvoidwriter(){a1;// 不能重排到readytrue之后readytrue;// volatile写确保前序操作已完成}publicvoidreader(){if(ready){// volatile读确保后序操作在它之后intresulta;// 一定能看到a1System.out.println(a result);// 始终输出 a 1}}}volatile的重排序规则volatile读volatile写前一个操作的结果后不会重排前不会重排后一个操作的结果前不会重排后会重排通俗理解volatile写之前的操作不会重排到写之后前面的不能跑到后面volatile读之后的操作不会重排到读之前后面的不能跑到前面3.3 一个更直观的例子publicclassVolatileBarrierDemo{intx0;volatilebooleanvfalse;publicvoidthread1(){x42;// ① 普通写vtrue;// ② volatile写// 内存屏障保证①一定在②之前执行}publicvoidthread2(){if(vtrue){// ③ volatile读// 内存屏障保证如果看到vtrue则x42已完成System.out.println(x);// ④ 一定输出42}}}四、volatile不保证原子性这是volatile最容易误解的地方。volatile保证可见性但不保证原子性。publicclassVolatileAtomicity{privatestaticvolatileintcount0;publicstaticvoidmain(String[]args)throwsInterruptedException{Thread[]threadsnewThread[10];for(inti0;i10;i){threads[i]newThread(()-{for(intj0;j1000;j){count;// 非原子操作// count 是三个步骤读 → 加1 → 写// 线程A读到0还没写回线程B也读到0// 两个线程各加1写回count还是1而不是2}});threads[i].start();}for(Threadt:threads){t.join();}System.out.println(期望值: 10000, 实际值: count);// 实际值常小于10000}}volatile vs synchronizedpublicclassVolatileVsSynchronized{privatevolatileintvCount0;privateintsCount0;// volatile不能保证原子性publicvoidincrementVolatile(){vCount;// 非线程安全}// synchronized保证原子性publicsynchronizedvoidincrementSynchronized(){sCount;// 线程安全}// volatile适用的场景1状态标志privatevolatilebooleanshutdownfalse;publicvoidshutdown(){shutdowntrue;}// volatile适用的场景2单次赋值privatevolatileMyConfigconfig;publicvoidinit(){confignewMyConfig();// 一次性赋值没有读-改-写}}五、经典案例DCL单例模式DCLDouble-Checked Locking单例是volatile最关键的应用场景之一。5.1 单例模式的演进// 版本1懒汉式线程不安全publicclassSingletonV1{privatestaticSingletonV1instance;privateSingletonV1(){}publicstaticSingletonV1getInstance(){if(instancenull){// ①instancenewSingletonV1();// ② 线程不安全}returninstance;}}// 版本2加synchronized性能差publicclassSingletonV2{privatestaticSingletonV2instance;privateSingletonV2(){}publicstaticsynchronizedSingletonV2getInstance(){if(instancenull){instancenewSingletonV2();}returninstance;}// 问题每次获取都要同步即使对象已经创建好了}// 版本3DCL双重检查锁定仍有问题publicclassSingletonV3{privatestaticSingletonV3instance;// 注意没有volatileprivateSingletonV3(){}publicstaticSingletonV3getInstance(){if(instancenull){// 第一次检查synchronized(SingletonV3.class){if(instancenull){// 第二次检查instancenewSingletonV3();// 问题在这里}}}returninstance;}// 问题instance new SingletonV3() 不是原子操作}5.2 new操作的秘密这是理解DCL为什么需要volatile的关键。看似简单的new操作在JVM层面上其实是多个步骤的组合。instance new SingletonV3()这一行代码在JVM中实际分解为三个步骤// 步骤①分配内存空间memoryallocate();// 步骤②初始化对象调用构造函数constructInstance(memory);// 步骤③将 instance 指向内存地址instancememory;由于指令重排序步骤②和③的顺序可能交换正常顺序① → ② → ③ 重排后① → ③ → ②如果重排后线程A执行到步骤③instance已非null但未初始化此时线程B进入getInstance()发现instance ! null直接返回一个未初始化完毕的对象导致灾难性后果。这个场景不是理论上的在早期JDK版本1.4及以前的某些实现中指令重排确实可能导致DCL出现问题。这也是为什么DCL曾经被称为反模式——直到JDK 5引入volatile的happens-before语义后DCLvolatile组合才真正变得安全可靠。5.3 volatile修复DCLpublicclassSingletonDCL{// volatile 禁止指令重排序问题解决privatestaticvolatileSingletonDCLinstance;privateSingletonDCL(){// 私有构造器System.out.println(Singleton 初始化);}publicstaticSingletonDCLgetInstance(){if(instancenull){// 第一次检查无锁synchronized(SingletonDCL.class){if(instancenull){// 第二次检查有锁instancenewSingletonDCL();// volatile 保证有序}}}returninstance;}publicvoiddoSomething(){System.out.println(执行业务逻辑: this.hashCode());}}// 测试publicclassDCLTest{publicstaticvoidmain(String[]args){for(inti0;i10;i){newThread(()-{SingletonDCLinstanceSingletonDCL.getInstance();instance.doSomething();}).start();}}}5.4 其他单例实现方式// 方式1静态内部类推荐利用类加载机制的线程安全publicclassSingletonHolder{privateSingletonHolder(){}privatestaticclassHolder{privatestaticfinalSingletonHolderINSTANCEnewSingletonHolder();}publicstaticSingletonHoldergetInstance(){returnHolder.INSTANCE;}}// 方式2枚举最安全防反射、防序列化破坏publicenumSingletonEnum{INSTANCE;publicvoiddoSomething(){System.out.println(枚举单例执行);}}六、volatile适用场景总结场景是否适用说明状态标志位✅ 适用如 shutdown、initialized 标志一次性安全发布✅ 适用DCL单例中的instance独立观察✅ 适用定期发布温度、配置等信息volatile bean✅ 适用简单JavaBeangetter/setter读-改-写操作❌ 不适用count 需要synchronized复合操作❌ 不适用if条件判断 赋值需要原子性volatile的happens-before规则// volatile变量的写操作 happens-before 后续对该变量的读操作// 也就是说读操作一定能看到写操作的结果volatilebooleanflagfalse;// 线程A先执行flagtrue;// volatile写// 线程B后执行if(flag){// volatile读 —— 一定能看到true// 此处flag之前的所有共享变量修改都可见}总结volatile的关键特性可以概括为两点半保证内存可见性一个线程修改后其他线程立即可见禁止指令重排序通过内存屏障保证有序性2.5.不保证原子性复合操作如count仍然需要加锁这三个特性中前两个让volatile成为轻量级的同步机制而第三个局限决定了它只能用在特定场景。正确使用volatile的关键在于只把它用在简单赋值的场景凡是涉及先检查再修改的操作请老老实实地用synchronized或者Lock。DCL单例是volatile的经典应用它完美展示了volatile禁止指令重排的重要性。理解了DCL的问题和volatile的修复方案你就真正理解了volatile的核心价值。✅ 亮点总结JMM主内存与工作内存模型线程不能直读主内存volatile确保每次读写都经过主内存volatile保证内存可见性的底层实现内存屏障StoreStore/LoadLoad与Lock前缀指令缓存行失效volatile禁止指令重排序的规则写之前的操作不能重排到写之后读之后的操作不能重排到读之前volatile不保证原子性的确切边界简单赋值flagtrue安全复合操作count仍需要同步DCL单例的问题根源——new操作的三个步骤分配→初始化→赋值可能被重排volatile禁止此重排适用场景线程间状态标志传递如shutdown、initialized等布尔开关一次性安全发布的配置对象配置初始化后对所有线程可见DCL单例模式中instance字段的正确声明防止指令重排导致的半初始化对象泄漏扩展方向深入学习JMM的happens-before规则体系建立并发代码正确性的理论基础研究JUC原子类AtomicInteger/LongAdder的CAS无锁并发实现推荐阅读[21_Java IO流体系详解](./21_Java IO流体系详解.md)下一篇[21_Java IO流体系详解](./21_Java IO流体系详解.md)
