Java并发编程的艺术读书笔记（第三章）

最新推荐文章于 2024-06-04 23:16:54 发布

_changeme

最新推荐文章于 2024-06-04 23:16:54 发布

阅读量187

点赞数 1

分类专栏： Java并发编程的艺术文章标签： happen-before JMM

本文链接：https://blog.csdn.net/ni_new_sm_new/article/details/97414319

版权

Java并发编程的艺术专栏收录该内容

10 篇文章 2 订阅

订阅专栏

第三章-Java内存模型

3.1 Java内存模型的基础

3.1.1 并发编程模型的两个关键问题
- 1、线程间如何通信
  
  在共享内存并发模型，线程之间共享程序的公共状态，通过写-读内存中的公共状态进行隐式通信。
  在消息传递并发模型，线程之间没有公共状态，线程之间必须通过发送消息来显式进行通信。
- 2、线程间如何同步 (同步是指程序中用于控制不同线程间操作发生相对顺序的机制。)
  
  在共享内存并发模型，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。
  在消息传递并发模型，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。
Java采用共享内存模型
3.1.2 Java 内存模型的抽象结构

Java线程之间的通信由Java内存模型（本文简称为JMM）控制，JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（Main Memory）中，每个线程都有一个私有的本地内存（Local Memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。
3.1.3 从源代码到指令序列的重排序

在执行程序时，为了提高性能，编译器和处理器常常会对指令做重排序。重排序分3种类型。
- 1 编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
- 2 指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-LevelParallelism，ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
- 3 内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。
重排序虽然能提高性能，但是可能会导致多线程程序出现内存可见性问题（详见第一章）

对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。

对于处理器重排序，JMM的处理器重排序规则会要求Java编译器在生成指令序列时，插入特定类型的内存屏障（Memory Barriers，Intel称之为Memory Fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序。

JMM属于语言级的内存模型，它确保在不同的编译器和不同的处理器平台之上，通过禁止特定类型的编译器重排序和处理器重排序，为程序员提供一致的内存可见性保证。

3.1.4 从源代码到指令序列的重排序
给出3.1.4的代码

//由于每个线程中的各个操作之间不存在数据流依赖，因此这些操作可以乱序执行 
//在不断的运行中，我得出了 (1,0) 和 (0,1) 但是始终得不到书中所的(0,0)可能几率太小了。得出(0,0)的过程如下
//线程一: x = b (0)
//线程二: b = 1,y = a(0)
//线程一: a = 1 
package ChapterII;
public class PossibleReordering {
    static int x = 0,y = 0;
    static int a = 0,b = 0;
    public static void main(String[] argc) throws InterruptedException {
        Thread one = new Thread(new Runnable(){
            @Override
            public void run() {
                a = 1;
                x = b;
            }
        });
        Thread other = new Thread(new Runnable(){
            @Override
            public void run() {
                b = 1;
                y = a;
            }
        });
        one.start(); other.start();
        one.join(); other.join();
        System.out.println("x = " + x + ", y = " + y);
    }
}

结合上述的内容，在这一节书中列出了各种处理器的不同情况下JMM对指令重排序规则的不同，引用Java编程实战 中的内容

JMM规定了JVM必须遵循的一组最小保证，这组保证规定了对变量的写入操作在何时将对其他线程可见。JMM在设计时就在可预测性和程序的易于开发性之间进行了权衡，从而在各种主流的处理器体系架构上能实现高性能JVM。

内存级的重排序会使程序行为变得不可预测，如果没有同步，那么推断出执行顺序将是非常困难的，而要确保在程序中正确的使用同步方法是非常容易的。同步将限制编译器、运行时和硬件对内存操作重排序的方式，从而在实施重排序时不会破坏JMM提供的可见性保证

在大多数主流的处理器架构中，内存都非常强大，使得读取volatile变量的性能与读取非volatile变量的性能大致相当。------《Java并发编程实战》

3.1.5 happen-before简介
- 在上述的例子中，我们知道JVM的重排序将有着不可预测的问题，那么我们怎么去解决这不同指令之间复杂的不可预测的关系？
JMM为程序中所有的操作定义了一个偏序关系，称为happen-before。想要保证执行操作B的线程中看到A的结果（无聊A和B是否在同一个线程中执行）,那么在A和B之间必须满足happen-before关系。如果两个操作之间缺乏Happen-before关系，那么JVM可以对他们任意地重排序。------《Java并发编程实战》
- 注意上面的说明是保证执行操作B的线程中看到A的结果（无聊A和B是否在同一个线程中执行），并不代表A的操作一定要在B之前。这一点在书中也有说明
happen-before 仅仅要求前一个操作（执行的结果）对后一个操作可见，且前一个操作按顺序排在第二个操作之前。

3.2 重排序

3.2.1 和 3.2.2的内容，我们先看下面的代码
```
	double pi = 3.14;  // A操作
	double r = 1.0; // B操作
	double area = pi * r * r; // C操作
```
在上面的串行代码块中，由上可知，根据happen-before规则，得出A和B操作结果必须在得出C操作结果之前。由于AB操作没有数据依赖性，所有AB操作可以重排序。
3.2.4 重排序对多线程的影响
同样给出一段代码
```
	if(flag){ //操作1
		int i = a * a; // 操作2
	}
```
- 由于操作2和操作1存在控制依赖，操作依赖会影响质量序列执行的并行度。所以在并行的情况下，编译器处理器会采用猜测（Speculation）执行来克服控制相关性对并行度的影响。以处理器的猜测执行为例，执行线程B的处理器可以提前读取并计算a*a，然后把计算结果临时保存到一个名为重排序缓冲（Reorder Buffer，ROB）的硬件缓存中。当操作3的条件判断为真时，就把该计算结果写入变量i中。
  
  意思是指令会先计算a * a然后存在知道 flag = true后直接取出来用
这虽然在单线程中不会改变执行结果，但是在并发过程中这将会破坏多线程程序的语义！
```
//下列代码a * a可能会发生在 a = 1之前，这不是我们想要看到的！
class ReorderExample {
	int a = 0;
	boolean flag = false;
	public void writer() {
		a = 1; // 1
		flag = true; // 2
	}
	Public void reader() {
		if (flag) { // 3
			int i = a * a; // 4
			……
		}
	}
}
```
3.3.2 顺序一致性内存模型
顺序一致性内存模型是一个被计算机科学家理想化了的理论参考模型，它为程序员提供
了极强的内存可见性保证。顺序一致性内存模型有两大特性。

程序执行一种简单：想象在程序中只存在唯一的操作执行顺序，而不考虑这些操作在何种处理器上执行，并且在每次读取变量时，都能获得在执行序列中（任何处理器）最近一次写入该变量的值。这种乐观的模型就被称为串行一致性。软件开发人员经常会错误地假设存在串行一致性，但在任何一款现代多处理器架构中都不会提供这种串行一致性，JMM也是如此。------《Java并发编程实战》

但是，在JMM中就没有这个保证。未同步程序在JMM中不但整体的执行顺序是无序的，而且所有线程看到的操作执行顺序也可能不一致。比如，在当前线程把写过的数据缓存在本地内存中，在没有刷新到主内存之前，这个写操作仅对当前线程可见；从其他线程的角度来观察，会认为这个写操作根本没有被当前线程执行。只有当前线程把本地内存中写过的数据刷新到主内存之后，这个写操作才能对其他线程可见。在这种情况下，当前线程和其他线程看到的操作执行顺序将不一致。
3.3.3 同步程序的顺序一致性效果
如果同步了呢？

从这里我们可以看到，JMM在具体实现上的基本方针为：在不改变（正确同步的）程序执行结果的前提下，尽可能地为编译器和处理器的优化打开方便之门。
3.3.4 未同步程序的执行特性

对于未同步或未正确同步的多线程程序，JMM只提供最小安全性：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0，Null，False），JMM保证线程读操作读取到的值不会无中生有（Out Of Thin Air）的冒出来。为了实现最小安全性，JVM在堆上分配对象时，首先会对内存空间进行清零，然后才会在上面分配对象（JVM内部会同步这两个操作）。因此，在已清零的内存空间（Pre-zeroed Memory）分配对象时，域的默认初始化已经完成了。
- 我们来看看Java是如何保证分配对象空间的时候是如何保证同步的

3.4 volatil的内存语义

3.4.1 volatile的特性
理解volatile特性的一个好方法是把对volatile变量的单个读/写，看成是使用同一个锁对单个读/写操作做了同步。
书中的代码很清晰的解释了上面这句话

class VolatileFeaturesExample {
	volatile long vl = 0L; // 使用volatile声明64位的long型变量
	public void set(long l) {
		vl = l; // 单个volatile变量的写
	}
	public void getAndIncrement () {
		vl++; // 复合（多个）volatile变量的读/写
	}
	public long get() {
		return vl; // 单个volatile变量的读
	}
}

下面的等价代码

class VolatileFeaturesExample {
	long vl = 0L; // 64位的long型普通变量
	public synchronized void set(long l) { // 对单个的普通变量的写用同一个锁同步
		vl = l;
	}
	public void getAndIncrement () { // 普通方法调用
		long temp = get(); // 调用已同步的读方法
		temp += 1L; // 普通写操作
		set(temp); // 调用已同步的写方法
	}
	public synchronized long get() { // 对单个的普通变量的读用同一个锁同步
		return vl;
	}
}

简而言之，volatile变量自身具有下列特性。

可见性。对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。

…中间的内容之前都讲过，只是在强调volatile在线程间的可见性

3.4.4 volatile的特性

重点是

我的总结是：
- volatile写入不能和前面的操作重排序
- volatile读取不能和后面的操作重排序
- volatile变量本身的操作之间不能重排序

3.6 锁的内存语义

3.6.1 final 域的重排序规则

1 在构造函数内对一个final域的写入，与随后把这个被构造对象的引用赋值给一个引用变量，这两个操作不能重排序。
2 初读一个包含final域的对象的引用，与随后初读这个final域，这两个操作不能重排序。

在说详细一点
1、JMM禁止编译器把final域的写重排序到构造函数之外。
这可以确保：在对象引用为任意线程可见之前，对象的final域已经被正确的初始化过了。
！注意！ 上面说的确保初始化要有一个附加条件：初始化没有逸出。
2、在读一个对象final域之前，一定会先读包含这个final域对象的引用。在书中的下列的示例中，如果对象引用不为null，那么引用对象的final域一定已经被A线程初始化过了。

public class FinalExample{
	int i;
	final int j;
	static FinalExample obj;
	public FinalExample(){
		i = 1;
		j = 2;
	}
	public static void writer(){
		obj = new FinalExample();
	}

	public static void reader(){
		FinalExample object = obj;
		int a = object.i;
		int b = object.j;
	}
}

逸出的意思是对象在初始化还未完成的时候已经可以被其他的线程访问，这会造成线程安全问题，所以如果要写出线程安全的代码防止对象逸出是及其重要的。

3.7.3　happens-before规则

《JSR-133:Java Memory Model and Thread Specification》定义了如下happens-before规则。
- 1）程序顺序规则：一个线程中的每个操作，happens-before于该线程中的任意后续操作。
- 2）监视器锁规则：对一个锁的解锁，happens-before于随后对这个锁的加锁。
- 3）volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。
- 4）传递性：如果A happens-before B，且B happens-before C，那么A happens-before C。
- 5）start()规则：如果线程A执行操作ThreadB.start()（启动线程B），那么A线程的ThreadB.start()操作happens-before于线程B中的任意操作。
- 6）join()规则：如果线程A执行操作ThreadB.join()并成功返回，那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。

书中的一句话我觉得写得很好:
as-if-serial语义给编写单线程程序的程序员创造了一个幻境：单线程程序是按程序的顺序来执行的。happens-before关系给编写正确同步的多线程程序的程序员创造了一个幻境：正确同步的多线程程序是按happens-before指定的顺序来执行的。

3.9　Java内存模型综述

顺序一致性内存模型是一个理论参考模型，JMM和处理器内存模型在设计时通常会以顺序一致性内存模型为参照。在设计时，JMM和处理器内存模型会对顺序一致性模型做一些放松，因为如果完全按照顺序一致性模型来实现处理器和JMM，那么很多的处理器和编译器优化都要被禁止，这对执行性能将会有很大的影响。

JMM屏蔽了不同处理器内存模型的差异，它在不同的处理器平台之上为Java程序员呈现
了一个一致的内存模型。
在这里插入图片描述

按程序类型，Java程序的内存可见性保证可以分为下列3类。

单线程程序。单线程程序不会出现内存可见性问题。编译器、runtime和处理器会共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。
正确同步的多线程程序。正确同步的多线程程序的执行将具有顺序一致性（程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同）。这是JMM关注的重点，JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证。
未同步/未正确同步的多线程程序。JMM为它们提供了最小安全性保障：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值（0、null、false）。