线程理论:(一)Java内存模型、volatile
一、Java内存模型(JMM)
Java内存模型是为了定义虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。此处的变量是指实例字段、静态字段和构成数组对象的元素,不包括局部变量与方法参数,因为后者是线程私有的,不会被共享,自然不会存在竞争问题。
Java内存模型规定了所有的变量都存储在主内存中,每条线程都有自己的工作内存,工作内存保存了被该线程使用到的变量的主内存副本拷贝,线程对变量的所有操作都必须在工作内存中进行,而不是直接读写主内存中的变量。如果局部变量是一个reference类型,它引用的对象在Java堆中可被各个线程共享,但reference本身在Java栈的局部变量表中,它是线程私有的。
不同的线程之间也无法直接访问对方工作内存中的变量,线程间变量值的传递均需要通过主内存来完成,线程、工作内存、主内存之间的关系,如下图所示:
内存间交互操作
Java内存模型中定义了8种操作来完成一个变量如何从主内存拷贝到工作内存,如何从工作内存同步到主内存之类的实现细节,虚拟机实现时需保证这八种操作都是原子的、不可再分的。
- lock(锁定):作用于主内存的变量,它把一个变量标识为一条线程独占的状态;
- unlock(解锁):作用于主内存变量,它把一个处于锁定状态的变量释放出来,释放后的变量才可以被其他线程锁定;
- read(读取):作用于主内存变量,它把一个变量的值从主内存传输到线程的工作内存中,以便随后的load动作使用;
- load(载入):作用于工作内存的变量,它把read操作从主内存中得到的变量值放入到工作内存的变量副本中;
- use(使用):作用于工作内存的变量,它把工作内存中的一个变量的值传递给执行引擎,每当虚拟机遇到一个需要使用变量的字节码指令时将会执行这个操作;
- assign(赋值):作用于工作内存的变量,它把一个从执行引擎接收到的值赋值给工作内存的变量,每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作;
- store(存储):作用于工作内存的变量,它把工作内存中一个变量值传送到主内存中,以便随后的write操作使用;
- write(写入):作用于主内存的变量,它把store操作从工作内存中得到的变量的值放入到主内存中。
对八种基本操作的几点规则:
- 不允许read和load、store和write操作之一单独出现
- 不允许一个线程丢弃它的最近assign的操作,即变量在工作内存中改变了之后必须同步到主内存中。
- 不允许一个线程无原因地(没有发生过任何assign操作)把数据从工作内存同步回主内存中。
- 一个新的变量只能在主内存中诞生,不允许在工作内存中直接使用一个未被初始化(load或assign)的变量。即就是对一个变量实施use和store操作之前,必须先执行过了assign和load操作。
- 一个变量在同一时刻只允许一条线程对其进行lock操作,lock和unlock必须成对出现
- 如果对一个变量执行lock操作,将会清空工作内存中此变量的值,在执行引擎使用这个变量前需要重新执行load或assign操作初始化变量的值
- 如果一个变量事先没有被lock操作锁定,则不允许对它执行unlock操作;也不允许去unlock一个被其他线程锁定的变量。
- 对一个变量执行unlock操作之前,必须先把此变量同步到主内存中(执行store和write操作)。
二、volatile变量
当一个变量定义为volatile之后,它将具备两种特性:
第一,可见性,当一条线程修改了这个变量的值,新值对于其他线程来说是可以立即可知的,这里只是因为每次使用volatile变量前都要刷新,但volatile变量在各个线程的工作内存还是会存在不一致的情况,在并发运算下是线程不安全的。参考链接:https://www.cnblogs.com/hapjin/p/5492880.html
1 public class RunThread extends Thread { 2 3 private boolean isRunning = true; 4 5 public boolean isRunning() { 6 return isRunning; 7 } 8 9 public void setRunning(boolean isRunning) { 10 this.isRunning = isRunning; 11 } 12 13 @Override 14 public void run() { 15 System.out.println("进入到run方法中了"); 16 while (isRunning == true) { 17 } 18 System.out.println("线程执行完成了"); 19 } 20 } 21 22 public class Run { 23 public static void main(String[] args) { 24 try { 25 RunThread thread = new RunThread(); 26 thread.start(); 27 Thread.sleep(1000); 28 thread.setRunning(false); 29 } catch (InterruptedException e) { 30 e.printStackTrace(); 31 } 32 } 33 }
Run.java 第28行,main线程将启动的线程RunThread中的共享变量设置为false,从而想让RunThread.java 第14行中的while循环结束。如果,我们使用JVM -server参数执行该程序时,RunThread线程并不会终止!从而出现了死循环!!
原因分析:
现在有两个线程,一个是main线程,另一个是RunThread。它们都试图修改第三行的 isRunning变量。按照JVM内存模型,main线程将isRunning读取到本地线程内存空间,修改后,再刷新回主内存。
而在JVM 设置成 -server模式运行程序时,线程会一直在私有堆栈中读取isRunning变量。因此,RunThread线程无法读到main线程改变的isRunning变量,从而出现了死循环,导致RunThread无法终止。这种情形,在《Effective JAVA》中,将之称为“活性失败”
解决方法,在第三行代码处用 volatile 关键字修饰即可。这里,它强制线程从主内存中取 volatile修饰的变量。
volatile private boolean isRunning = true;
扩展一下,当多个线程之间需要根据某个条件确定 哪个线程可以执行时,要确保这个条件在线程之间是可见的。因此,可以用volatile修饰。
综上,volatile关键字的作用是:使变量在多个线程间可见(可见性)
第二,禁止指令重排序优化,普通变量不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。
Map configOptions; char[] configText; //此变量必须定义为volatile volatile boolean initialized = false; //假设以下代码在线程A中执行 //模拟读取配置信息,当读取完成后将initialized设置为true来通知其它线程配置可用 configOptions = new HashMap(); configText = readConfigFile(fileName); processConfigOptions(configText, configOptions); initialized = true; //假设以下代码在线程B中执行 //等线程A待initialized为true,代表线程A已经把配置信息初始化完成 while(!initialized) { sleep(); } //使用线程A中初始化好的配置信息 doSomethingWithConfig();
如果没有使用volatile定义initialized变量,就可能会由于指令重排序的优化,导致在线程A中最后一句的代码"initialized = true"被提前执行,这样线程B就可能误以为线程A已经加载好配置文件,但其实只是代码被提前执行,这样在使用配置信息就可能出现错误。
重排序会破坏多线程程序的语义,因此才需要诸如volatile这样的技术来禁止重排序。
三、原子性、可见性与有序性
对于long和double型变量的特殊规则:Java内存模型允许虚拟机将没有被volatile修饰的64位数据类型的读写操作划分为两次32位的操作来进行,但目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待,因此我们在编写代码时一般不需要把用到的long和double变量专门声明为volatile。
1)原子性:
由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store和write,我们大致可以认为基本数据类型的访问读写是具备原子性的(例外的就是long和double的非原子协定,不过几乎不会发生)。
为了提供更大范围的原子性保证,Java内存模型还提供了lock和unlock,反映到Java代码中就是同步块——synchronized关键字,因此在Synchronized块之间的操作也具备原子性。
2)可见性:
可见性是指当一个线程修改了共享变量的值,其他线程能立即得知这个修改。Java内存模型是通过在变量修改之后将新值同步到主内存,在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性,无论是普通变量还是volatile变量都是如此。
普通变量与volatile变量的区别在于:volatile的特殊规则保证了新值能立即同步到主内存中,以及每次使用前立即从主内存刷新。因此,可以说volatile保证了多线程操作时变量的可见性,而普通变量则不能保证这一点。
除了volatile之外,Synchronized和final这两个关键字也能实现可见性,Synchronized同步块的可见性是由“对一个变量执行unlock之前,必须先把此变量同步到主内存中(执行store和write操作)”这条规则来获得的。被final修饰的字段在构造器中一旦初始化完成,并且构造器没有把“this”的引用传递出去,那在其他线程中就能看见final字段的值,无需同步就能被其他线程正确访问。
3)有序性:
Java程序中天然的有序性可以总结为一句话:如果在本线程内观察,所有的操作都是有序的;如果在一个线程中观察另一个线程,所有的操作都是无序的。前半句是指“线程内表现为串行的语义”。后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。
Java提供了volatile和Synchronized两个关键字来保证线程之间操作的有序性,volatile关键字本身就包含了禁止指令重排序的语义,而Synchronized关键字则是由“一个变量在同一个时刻只允许一条线程对其进行lock操作”这条规则获得的,这条规则决定了持有同一个锁的两个同步块只能串行地进入。
四、先行发生原则
Java内存模型下一些“天然的”先行发生关系,这些先行发生关系无须任何同步器协助就已经存在,可以在编码中直接使用。如果两个操作的关系不在此列,并且无法从下列规则推导出来的话,它们就没有顺序性保障,虚拟机可以对它们随意进行重排序。
- 程序次序规则:在一个线程内,按照程序代码顺序,书写在前面的操作先行发生于书写在后面的操作。准确的说,应该是控制流顺序而不是程序代码顺序,因为考虑到分支、循环等结构;
- 管程锁定规则:一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁,而“后面”是指时间上的先后顺序;
- volatile变量规则:对一个volatile变量的写操作先行发生于后面对这个变量的读操作,这里的“后面”同样是指时间上的先后顺序;
- 线程启动规则:Thread对象的start()方法先行发生于此线程的每一个动作;
- 线程终止规则:线程中的所有操作都先行发生于对此线程的终止检测,我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行;
- 线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生,可以通过Thread.interrupted()方法检测到是否有中断发生;
- 对象终结规则:一个对象初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始;
- 传递性:如果操作A先行发生于操作B,操作B先行发生于操作C,那就可以得出操作A先行发生于操作C的结论;
private int value=0; pubilc void setValue(int value){ this.value=value; } public int getValue(){ return value; }
假设存在线程A和B,线程A先(时间上的先后)调用了“setValue(1)”,然后线程B调用了同一个对象的“getValue()”,那么线程B收到的返回值是什么?
由于两个方法分别由线程A和线程B调用,不在一个线程中,所以程序次序规则在这里不适用;由于没有同步块,自然就不会发生lock和unlock操作,所以管程锁定规则不适用;由于value变量没有被volatile关键字修饰,所以volatile变量规则不适用;后面的线程启动、终止、中断规则和对象终结规则也和这里完全没有关系。 因为没有一个适用的先行发生规则,所以最后一条传递性也无从谈起,因此我们可以判定尽管线程A在操作时间上先于线程B,但是无法确定线程B中“getValue()”方法的返回结果,换句话说,这里面的操作不是线程安全的。
要修复这个问题呢我们至少有两种比较简单的方案可以选择:要么把getter/setter方法都定义为synchronized方法;要么把value定义为volatile变量,由于setter方法对value的修改不依赖value的原值,满足volatile关键字使用场景,这样就可以套用volatile变量规则来实现先行发生关系。
通过上面的例子,我们可以得出结论:一个操作“时间上的先发生”不代表这个操作会是“先行发生”。
//以下操作在同一个线程中执行 int i=1; int j=2;
以上代码的两条赋值语句在同一个线程之中,根据程序次序规则,“int i=1”的操作先行发生于“int j=2”,但是“int j=2”的代码完全可能先被处理器执行,这并不影响先行发生原则的正确性,因为我们在这条线程之中没有办法感知到这点。
通过上面的例子,我们可以得出结论:一个操作“先行发生”不代表这个操作必定是“时间上的先发生”。
上面两个例子综合起来证明了一个结论:时间先后顺序与先行发生原则之间基本没有太大的关系,所以我们衡量并发安全问题的时候不要受到时间顺序的干扰,一切必须以先行发生原则为准。
https://blog.csdn.net/wangdong5678999/article/details/80960118
http://www.cnblogs.com/keedor/p/4395568.html
https://blog.csdn.net/json_it/article/details/79218297
https://www.cnblogs.com/dolphin0520/p/3920373.html
https://blog.csdn.net/sunxianghuang/article/details/51920794