知识大全 Java多线程之volatile深入分析

Posted 2022-07-18 变量

篇首语：人的大脑和肢体一样，多用则灵，不用则废-茅以升本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 Java多线程之volatile深入分析相关的知识，希望对你有一定的参考价值。

Java多线程之volatile深入分析 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　volatile 变量提供了线程的可见性并不能保证线程安全性和原子性

　　什么是线程的可见性

　　锁提供了两种主要特性互斥（mutual exclusion）和可见性（visibility）互斥即一次只允许一个线程持有某个特定的锁因此可使用该特性实现对共享数据的协调访问协议这样一次就只有一个线程能够使用该共享数据可见性要更加复杂一些它必须确保释放锁之前对共享数据做出的更改对于随后获得该锁的另一个线程是可见的如果没有同步机制提供的这种可见性保证线程看到的共享变量可能是修改前的值或不一致的值这将引发许多严重问题

　　具体看volatile的语义

　　volatile相当于synchronized的弱实现也就是说volatile实现了类似synchronized的语义却又没有锁机制它确保对volatile字段的更新以可预见的方式告知其他的线程

　　volatile包含以下语义

　　（）Java 存储模型不会对valatile指令的操作进行重排序这个保证对volatile变量的操作时按照指令的出现顺序执行的

　　（）volatile变量不会被缓存在寄存器中（只有拥有线程可见）或者其他对CPU不可见的地方每次总是从主存中读取volatile变量的结果也就是说对于volatile变量的修改其它线程总是可见的并且不是使用自己线程栈内部的变量也就是在happens before法则中对一个valatile变量的写操作后其后的任何读操作理解可见此写操作的结果

　　尽管volatile变量的特性不错但是volatile并不能保证线程安全的也就是说volatile字段的操作不是原子性的 volatile变量只能保证可见性（一个线程修改后其它线程能够理解看到此变化后的结果）要想保证原子性目前为止只能加锁！

　　使用Volatile的原则

　　应用volatile变量的三个原则

　　（）写入变量不依赖此变量的值或者只有一个线程修改此变量

　　（）变量的状态不需要与其它变量共同参与不变约束

　　（）访问变量不需要加锁

　　实际上这些条件表明可以被写入 volatile 变量的这些有效值独立于任何程序的状态包括变量的当前状态

　　第一个条件的限制使 volatile 变量不能用作线程安全计数器虽然增量操作（x++）看上去类似一个单独操作实际上它是一个由读取修改写入操作序列组成的组合操作必须以原子方式执行而 volatile 不能提供必须的原子特性实现正确的操作需要使 x 的值在操作期间保持不变而 volatile 变量无法实现这点（然而如果将值调整为只从单个线程写入那么可以忽略第一个条件）

　　大多数编程情形都会与这三个条件的其中之一冲突使得 volatile 变量不能像 synchronized 那样普遍适用于实现线程安全清单显示了一个非线程安全的数值范围类它包含了一个不变式下界总是小于或等于上界

　　正确使用volatile:

　　模式 # :状态标志

　　也许实现 volatile 变量的规范使用仅仅是使用一个布尔状态标志用于指示发生了一个重要的一次性事件例如完成初始化或请求停机

　　很多应用程序包含了一种控制结构形式为在还没有准备好停止程序时再执行一些工作如清单所示

　　清单将 volatile 变量作为状态标志使用

　　volatile boolean shutdownRequested;

　　…

　　public void shutdown（） shutdownRequested = true;

　　public void doWork（）

　　while （！shutdownRequested）

　　// do stuff

　　很可能会从循环外部调用 shutdown（）方法即在另一个线程中因此需要执行某种同步来确保正确实现 shutdownRequested变量的可见性（可能会从 JMX 侦听程序 GUI 事件线程中的操作侦听程序通过 RMI 通过一个 Web 服务等调用）然而使用synchronized 块编写循环要比使用清单所示的 volatile 状态标志编写麻烦很多由于 volatile 简化了编码并且状态标志并不依赖于程序内任何其他状态因此此处非常适合使用 volatile

　　这种类型的状态标记的一个公共特性是通常只有一种状态转换 shutdownRequested 标志从 false 转换为 true 然后程序停止这种模式可以扩展到来回转换的状态标志但是只有在转换周期不被察觉的情况下才能扩展（从 false 到 true 再转换到 false）此外还需要某些原子状态转换机制例如原子变量

　　模式 # :一次性安全发布（one time safe publication）

　　缺乏同步会导致无法实现可见性这使得确定何时写入对象引用而不是原语值变得更加困难在缺乏同步的情况下可能会遇到某个对象引用的更新值（由另一个线程写入）和该对象状态的旧值同时存在（这就是造成著名的双重检查锁定（double checked locking）问题的根源其中对象引用在没有同步的情况下进行读操作产生的问题是您可能会看到一个更新的引用但是仍然会通过该引用看到不完全构造的对象）

　　实现安全发布对象的一种技术就是将对象引用定义为 volatile 类型清单展示了一个示例其中后台线程在启动阶段从数据库加载一些数据其他代码在能够利用这些数据时在使用之前将检查这些数据是否曾经发布过

　　清单将 volatile 变量用于一次性安全发布

　　public class BackgroundFloobleLoader

　　public volatile Flooble theFlooble;

　　public void initInBackground（）

　　// do lots of stuff

　　theFlooble = new Flooble（） // this is the only write to theFlooble

　　public class SomeOtherClass

　　public void doWork（）

　　while （true）

　　// do some stuff…

　　// use the Flooble but only if it is ready

　　if （floobleLoader theFlooble != null）

　　doSomething（floobleLoader theFlooble）

　　如果 theFlooble 引用不是 volatile 类型 doWork（）中的代码在解除对 theFlooble 的引用时将会得到一个不完全构造的 Flooble

　　该模式的一个必要条件是被发布的对象必须是线程安全的或者是有效的不可变对象（有效不可变意味着对象的状态在发布之后永远不会被修改） volatile 类型的引用可以确保对象的发布形式的可见性但是如果对象的状态在发布后将发生更改那么就需要额外的同步

　　模式 # :独立观察（independent observation）

　　安全使用 volatile 的另一种简单模式是定期发布观察结果供程序内部使用例如假设有一种环境传感器能够感觉环境温度一个后台线程可能会每隔几秒读取一次该传感器并更新包含当前文档的 volatile 变量然后其他线程可以读取这个变量从而随时能够看到最新的温度值

　　使用该模式的另一种应用程序就是收集程序的统计信息清单展示了身份验证机制如何记忆最近一次登录的用户的名字将反复使用 lastUser 引用来发布值以供程序的其他部分使用

　　清单将 volatile 变量用于多个独立观察结果的发布

　　public class UserManager

　　public volatile String lastUser;

　　public boolean authenticate（String user String password）

　　boolean valid = passwordIsValid（user password）

　　if （valid）

　　User u = new User（）

　　activeUsers add（u）

　　lastUser = user;

　　return valid;

　　该模式是前面模式的扩展将某个值发布以在程序内的其他地方使用但是与一次性事件的发布不同这是一系列独立事件这个模式要求被发布的值是有效不可变的即值的状态在发布后不会更改使用该值的代码需要清楚该值可能随时发生变化

　　模式 # : volatile bean 模式

　　volatile bean 模式适用于将 JavaBeans 作为荣誉结构使用的框架在 volatile bean 模式中 JavaBean 被用作一组具有 getter 和/或 setter 方法的独立属性的容器 volatile bean 模式的基本原理是很多框架为易变数据的持有者（例如 HttpSession）提供了容器但是放入这些容器中的对象必须是线程安全的

　　在 volatile bean 模式中 JavaBean 的所有数据成员都是 volatile 类型的并且 getter 和 setter 方法必须非常普通除了获取或设置相应的属性外不能包含任何逻辑此外对于对象引用的数据成员引用的对象必须是有效不可变的（这将禁止具有数组值的属性因为当数组引用被声明为 volatile 时只有引用而不是数组本身具有 volatile 语义）对于任何 volatile 变量不变式或约束都不能包含 JavaBean 属性清单中的示例展示了遵守 volatile bean 模式的 JavaBean:

　　模式 # : volatile bean 模式

　　@ThreadSafe

　　public class Person

　　private volatile String firstName;

　　private volatile String lastName;

　　private volatile int age;

　　public String getFirstName（） return firstName;

　　public String getLastName（） return lastName;

　　public int getAge（） return age;

　　public void setFirstName（String firstName）

　　this firstName = firstName;

　　public void setLastName（String lastName）

　　this lastName = lastName;

　　public void setAge（int age）

　　this age = age;

　　volatile 的高级模式

　　前面几节介绍的模式涵盖了大部分的基本用例在这些模式中使用 volatile 非常有用并且简单这一节将介绍一种更加高级的模式在该模式中 volatile 将提供性能或可伸缩性优势

　　volatile 应用的的高级模式非常脆弱因此必须对假设的条件仔细证明并且这些模式被严格地封装了起来因为即使非常小的更改也会损坏您的代码！同样使用更高级的 volatile 用例的原因是它能够提升性能确保在开始应用高级模式之前真正确定需要实现这种性能获益需要对这些模式进行权衡放弃可读性或可维护性来换取可能的性能收益如果您不需要提升性能（或者不能够通过一个严格的测试程序证明您需要它）那么这很可能是一次糟糕的交易因为您很可能会得不偿失换来的东西要比放弃的东西价值更低

　　模式 # :开销较低的读写锁策略

　　目前为止您应该了解了 volatile 的功能还不足以实现计数器因为 ++x 实际上是三种操作（读添加存储）的简单组合如果多个线程凑巧试图同时对 volatile 计数器执行增量操作那么它的更新值有可能会丢失

　　然而如果读操作远远超过写操作您可以结合使用内部锁和 volatile 变量来减少公共代码路径的开销清单中显示的线程安全的计数器使用 synchronized 确保增量操作是原子的并使用 volatile 保证当前结果的可见性如果更新不频繁的话该方法可实现更好的性能因为读路径的开销仅仅涉及 volatile 读操作这通常要优于一个无竞争的锁获取的开销

　　清单结合使用 volatile 和 synchronized 实现开销较低的读写锁

　　@ThreadSafe

　　public class CheesyCounter

　　// Employs the cheap read write lock trick

　　// All mutative operations MUST be done with the this lock held

　　@GuardedBy（ this ） private volatile int value;

　　public int getValue（） return value;

　　public synchronized int increment（）

　　return value++;

　　之所以将这种技术称之为开销较低的读写锁是因为您使用了不同的同步机制进行读写操作因为本例中的写操作违反了使用 volatile 的第一个条件因此不能使用 volatile 安全地实现计数器您必须使用锁然而您可以在读操作中使用 volatile 确保当前值的可见性因此可以使用锁进行所有变化的操作使用 volatile 进行只读操作其中锁一次只允许一个线程访问值 volatile 允许多个线程执行读操作因此当使用 volatile 保证读代码路径时要比使用锁执行全部代码路径获得更高的共享度就像读写操作一样然而要随时牢记这种模式的弱点如果超越了该模式的最基本应用结合这两个竞争的同步机制将变得非常困难

　　关于指令重排序与Happens before法则

　　指令重排序

　　Java语言规范规定了JVM线程内部维持顺序化语义也就是说只要程序的最终结果等同于它在严格的顺序化环境下的结果那么指令的执行顺序就可能与代码的顺序不一致这个过程通过叫做指令的重排序指令重排序存在的意义在于 JVM能够根据处理器的特性（CPU的多级缓存系统多核处理器等）适当的重新排序机器指令使机器指令更符合CPU的执行特点最大限度的发挥机器的性能

　　程序执行最简单的模型是按照指令出现的顺序执行这样就与执行指令的CPU无关最大限度的保证了指令的可移植性这个模型的专业术语叫做顺序化一致性模型但是现代计算机体系和处理器架构都不保证这一点（因为人为的指定并不能总是保证符合CPU处理的特性）

　　Happens before法则

　　Java存储模型有一个happens before原则就是如果动作B要看到动作A的执行结果（无论A/B是否在同一个线程里面执行）那么A/B就需要满足happens before关系

　　在介绍happens before法则之前介绍一个概念 JMM动作（Java Memeory Model Action） Java存储模型动作一个动作（Action）包括变量的读写监视器加锁和释放锁线程的start（）和join（）后面还会提到锁的的

　　happens before完整规则

　　（）同一个线程中的每个Action都happens before于出现在其后的任何一个Action

　　（）对一个监视器的解锁happens before于每一个后续对同一个监视器的加锁

　　（）对volatile字段的写入操作happens before于每一个后续的同一个字段的读操作

　　（）Thread start（）的调用会happens before于启动线程里面的动作

　　（）Thread中的所有动作都happens before于其他线程检查到此线程结束或者Thread join（）中返回或者Thread isAlive（）==false

　　（）一个线程A调用另一个另一个线程B的interrupt（）都happens before于线程A发现B被A中断（B抛出异常或者A检测到B的isInterrupted（）或者interrupted（））

　　（）一个对象构造函数的结束happens before与该对象的finalizer的开始

cha138/Article/program/Java/gj/201311/27449