java虚拟机10.内存模型与线程

多任务处理在现代计算机操作系统中是一项必备的功能，让计算机同时去做几件事情，不仅是因为计算机的运算能力强大了，更重要的原因是计算机的运算速度与它的存储和通信子系统速度的差距太大，大量的时间都花费在磁盘I/O，网络通信或者数据库访问上，因此处理器在大部分时间里都处于等待其他资源的状态。

如果让计算机并发执行若干个运算任务就可以更充分地利用计算机处理器的效能，但是其中的复杂性是绝大多数的运算任务都不可能只靠处理器计算就能完成，处理器至少要与内存交互，如读取运算数据、存储运算结果等，这个I/O操作无法消除。

所以现代计算机通过加入一层读写速度尽可能接近处理器运算速度的告诉缓存来作为内存与处理器之间的缓冲：将运算需要使用的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无需等待缓慢的内存读写了。

基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是引入了复杂度更高的一个问题：缓存一致性。

在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存。当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致，在将数据同步回主内存时以谁的缓存数据为准呢？为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作。

因此内存模型可以理解为在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。

除了增加高速缓存之外，为了使处理器内部的运算单元能尽量被充分利用，处理器可能会对输入代码进行乱序执行优化，处理器会在计算之后将乱序执行的结果重组，保证该结果与顺序执行的结果是一致的，但并不保证程序中的各个语句计算的先后顺序与输入的代码顺序一致。因此，如果存在一个计算任务依赖另外一个计算任务的中间结果，那么其顺序性并不能依靠代码的先后顺序来保证。与处理器的乱序执行优化器类似，java虚拟机的即时编译器中也有类似的指令重排序优化。

Java内存模型

java虚拟机规范中试图定义一种java内存模型来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让java程序在各种平台下都能达到一致的内存访问效果。

java内存模型规定了所有的变量都存储在主内存中，每条线程有自己的工作内存，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存中的变量。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。

内存间交互操作

对于一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存的问题在java内存模型中定义了8种操作：

1.lock:作用于主内存的变量，它把一个变量标识为一条线程独占的状态。

2.unlock:作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

3.read:作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用。

4.load:作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。

5.use:作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作。

6.assign:作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，，每当虚拟机遇到一个给变量赋值的字节码指令时将会执行这个操作。

7.store:作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。

8.write:作用于主内存的变量，它把store操作从工作内存中得到的变量的值写入主内存的变量中。

如果要把一个变量从主内存复制到工作内存，需要顺序的执行read和load操作，如果要把变量从工作内存同步回主内存，需要顺序执行store和write。但java内存模型只要求两个操作时顺序执行，没有保证是连续执行，即在两个操作之间可插入执行其他指令。

所以java内存模型还规定了在执行上述8中操作时必须满足的规则：

1.不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况。

2.不允许一个线程丢弃它的最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。

3.不允许一个线程无原因地(没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。

4.对一个变量实施use、store操作之前，必须先执行过load、assign操作。

5.一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后,只有执行相同次数的unlock操作，变量才会被解锁。

6.如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作初始化变量的值。

7.如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。

8.对一个变量执行unlock操作之前，必须先把此变量同步回主内存中，即store,write。

对于volatile型变量的特殊规则

java内存模型对volatile型变量专门定义了一些特殊的访问规则：

假定T表示一个线程，V表示volatile变量，那么在进行read、load、use、assign、store和write操作时需要满足如下规则：

1.只有当线程T对变量V执行的前一个动作是load的时候，线程T才能对变量V执行use动作；并且只有当线程T对变量V执行的后一个动作是use的时候，线程T才能对变量V执行load操作。线程T对变量V的use动作可认为是和线程T对变量V的load、read动作相关联，必须连续一起出现。

这条规则要求在工作内存中，每次使用V前都必须先从主内存刷新最新的值，用于保证能看见其他线程对变量V所做的修改。

2.只有当线程T对变量V执行的前一个动作是assign的时候，线程T才能对变量V执行store动作；并且，只有当线程T对变量V执行的后一个动作是store的时候，线程T才能对变量V执行assign动作。线程T对变量V的assign动作可认为是和线程T对变量的store、write动作相关联，必须连续一起出现。

这条规则要求在工作内存中，每次修改V后都必须立即同步回主内存中，用于保证其他线程可以看到自己对变量V的修改。

这两个规则确保了volatile的可见性[1]。

所以volatile变量在各个线程的工作内存中不存在一致性问题，但java里面的运算并非原子操作，导致volatile变量在并发下一样是不安全的(从主内存获取变量值到交给执行引擎为止都是没问题的，但是执行引擎在执行时不是原子操作，所以线程T1在修改变量值的时候，线程T2可以继续获取变量的旧值并交给自己的执行引擎，这样线程T1的修改对线程T2就不可见，即出现并发问题)。

由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，仍然要通过加锁来保证原子性。

1.运算结果不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。

2.变量不需要与其他的状态变量共同参与不变约束。

volatile变量的另一个语义是禁止指令重排序优化[2]。

普通的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获得正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中无法感知到这点，也就java内存模型中描述的：线程内表现为串行的语义。

eg:

Map configOptions;

char[] configText;

volatile boolean initialized = false;

//假设以下代码在线程A中执行，读取配置信息，读取完后将initialized设置为true以通知其他线程配置可用。

configOptions = new HashMap();

configText = readConfigFile(fileName);

processConfigOptions(configText,configOptions);

initialized = true;

//假设以下代码在线程B中执行，等待initialized为true,代表线程A已经把配置信息初始化完成。

while(!initialized){

sleep();

}

doSomethingWithConfig();

如果定义initialized变量时没有使用volatile修饰，就可能由于指令重排序的优化，导致位于线程A中最后一句的代码”initialized=true”被提前执行，这样线程B中使用配置信息的代码就可能出现错误。

volatile变量相当于在操作指令中的一个内存屏障，在指令重排序时不能把后面的指令重排序到内存屏障之前的位置。只有一个cpu访问内存时，并不需要内存屏障；但如果有多个cpu访问同一块内存，且其中有一个在观测另一个，就需要内存屏障来保证一致性了。

由于虚拟机对锁实行的消除和优化，使得我们很难量化地认为volatile就会比synchronize快多少。volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过在大多数场景下volatile的总开销仍然要比锁低。我们在volatile与锁之间选择的唯一依据仅仅是volatile的语义能否满足使用场景的需求。

原子性、可见性、有序性

java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这个三个特征来建立的。

原子性：

由java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store、和write,我们大致可以认为基本数据类型的访问读写是具备原子性的。对于更大范围的原子性保证，java内存模型提供了lock和unlock操作来满足这种需求。

可见性：

java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递介质的方式来实现可见性的，无论是普通变量还是volatile变量都是如此，普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。

除了volatile之外，java还有两个关键字能实现可见性，即syncharonized和final。

同步块的可见性由”对一个变量执行unlock操作之前，必须先把此变量同步回主内存中(store,write)”。而final的可见性是指，被final修饰的字段在构造器中一旦初始化完成，并且构造器没有把”this”的引用传递出去，那在其他线程中就能看见final字段的值。

有序性：

java程序中天然的有序性可以总结为：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句指’线程内表现为串行语义’，后半句指’指令重排序和工作内存与主内存的同步延时。’

java提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile本身就包含了禁止指令重排序的语义，而synchaonized则是有”一个变量在同一个时刻只允许一条线程对其进行lock操作”(lock之后只有自己能unlock,将自己的结果同步到主内存中)

先行发生规则

先行发生java内存模型中定义的两项操作之间的偏序关系，如果说操作A先行发生于操作B，其实就是说在发生操作B之前，操作A产生的影响能被B观察到。

java内存模型中有一些天然的先行发生关系，这些先行发生关系无须任何同步器协助就已经存在。

程序次序规则 在一个线程内，按照代码顺序（控制流），写在前面的操作先行发生于写在后面的操作。

管程锁定规则 一个unlock操作先行发生于后面(时间上的)对同一个锁的lock操作，这里强调的是同一个锁。

volatile变量规则 对一个volatile变量的写操作先行发生于后面（时间上的）对这个变量的读操作。

线程启动规则 Thread对象的start()方法先行发生于此线程的每一个动作。

线程终止规则 线程中的所有操作都先行发生于对此线程的终止检测，可以通过Thread.join()方法结束。

线程中断规则 对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生。

对象终结规则 一个对象的初始化完成先行发生于它的finalize()方法的开始。

传递性 如果操作A先行发生于操作B，操作B先行发生于操作C,那么操作A先行发生于操作C。

线程状态

java定义了5种线程状态，在任意一个时间点，一个线程有且只有其中一种状态。

1.新建[New]：创建后尚未启动的线程处于这种状态。

2.运行[Runnable]：runnable包括了操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可能正在执行，也有可能正在等待着CPU为它分配执行时间。

3.无限期等待[Waiting]：处于这种状态的线程不会被分配CPU执行时间，他们要等待被其他线程显示地唤醒：

.没有设置Timeout参数的Object.wait()方法。

.没有设置Timeout参数的Thread.join()方法。

.LockSupport.park()方法。

3.限期等待[Timed Waiting]：处于这种状态的线程也不会被分配CPU执行时间，不过无须等待被其他线程显示地唤醒，在一定时间之后它们会由系统自动唤醒：

.Thread.sleep()方法。

.设置了Timeout参数的Object.wait()方法。

.设置了Timeout参数的Thread.join()方法。

.LockSupport.parkNanos()方法。

.LockSupport.parkUntil()方法。

4.阻塞[blocked]：线程被阻塞了，“阻塞状态”与“等待状态”的区别是：“阻塞状态”在等待着获取到一个排他锁，这个事件将在另外一个线程放弃这个锁的时候发生，而“等待状态”则是在等待一段时间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态。

5.结束[Terminated]：已终止线程的线程状态，线程已经结束执行。

贴一张转换图：

Java语言中的线程安全

按照线程安全的“安全程度”由强至弱来排序，可以将java语言中各种操作共享的数据分为以下5类：

不可变：只要一个不可变的对象被正确的构建出来（没有发生this引用逃逸的情况），那其外部的可见状态永远也不会改变。String类就是一个典型的不可变对象，它的substring(),replace()和concat()方法都不会影响它原来的值，只会返回一个新构造的字符串对象。保证对象行为不影响自己状态的途径有很多种，其中最简单的就是把对象中带有状态的变量都声明为final，这样在构造函数结束以后，它就是不可变的。绝对线程安全：如vector容器，所有类方法都用synchronized修饰。相对线程安全：通常意义上的线程安全，可以保证对象的单个操作是线程安全的，在调用的时候不需要做额外的保障措施，但对一些特定顺序的连续调用，可能需要在调用端使用额外的同步手段来保证正确性。线程兼容：指对象本身并不是线程安全的，但可以通过在调用端正确的使用同步手段来保证对象在并发环境中可以安全地使用。线程对立：指无论调用端是否采取了同步措施，都无法再多线程环境中并发使用。

锁消除

锁消除是指虚拟机即时编译器在运行时，对一些代码上要求同步，但是被检测到不可能存在共享数据竞争的锁进行消除。主要判断依据来于逃逸分析的数据支持，如果判断在一段代码中，堆上的所有数据都不会逃逸出去从而被其他线程访问到，那就可以把它们当做栈上数据对待，认为它们是线程私有的，同步加锁自然就无须进行。

例如：public String condat(String s1,String s2,String s3){

return s1+s2+s3;

}

在jdk1.5之前，会转化为StringBuffer对象的连续append()操作，在jdk1.5及之后的版本中，会转化为StringBuilder对象的连续append()操作。

其实每个StringBuffer.append()方法中都有一个同步块，锁就是stringbuffer对象，但虚拟机观察stringbuffer对象，发现它的动态作用域被限制在方法内部，就是说不会逃逸到方法外，因此会将锁消除掉。

#笔记内容来自《深入理解java虚拟机》

个人收藏笔记记录

开通VIP