JUC并发编程(11.Java线程-内存(JMM)）

古城微笑少年丶 2023-09-24 19:03 44阅读 0赞

# 1. 共享模式-内存（JMM） #

上一章讲解的 `Monitor` 主要关注的是访问共享变量时，保证临界区代码的`原子性`  
这一章我们进一步深入学习共享变量在多线程间的`【可见性】`问题与多条指令执行时的`【有序性】`问题

## 1）Java内存模式 ##

JMM 即 `Java Memory Model`，它定义了`主存、工作内存`抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。  
JMM 体现在以下几个方面

*  原子性 - 保证指令**不会受到线程上下文切换**的影响
 *  可见性 - 保证指令**不会受 cpu 缓存**的影响
 *  有序性 - 保证指令**不会受 cpu 指令并行优化**的影响

## 2）可见性 ##

### 退不出的循环 ###

先来看一个现象，`main 线程对 run 变量的修改对于 t 线程不可见`，导致了`t 线程无法停止`：

public class Test32 {
        
        // 易变
        static boolean run = true;
    
        public static void main(String[] args) throws InterruptedException {
        
            Thread t = new Thread(()->{
        
                while(true){
        
                        if(!run) {
        
                            break;
                        }
                }
            });
            t.start();
    
            sleep(1);
            log.debug("停止t");
            run = false; // 线程t不会如预想的停下来
        }
    }

09:48:17.668 c.Test32 [main] - 停止t

#### 分析 ####

为什么呢？分析一下：

1.  初始状态， **t 线程刚开始从主内存读取了 run 的值到工作内存**。

![在这里插入图片描述][c7b8a9521a0648f9a8c2ffe535b172ec.png]

1.  因为 t 线程要**频繁从主内存中读取 run 的值**，**JIT 编译器会将 run 的值缓存至自己工作内存中的高速缓存中**，减少对主存中 run 的访问，提高效率  
    ![在这里插入图片描述][540edd2421fc4dae98590ef5c90888af.png]
2.  1 秒之后，**main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值**  
    ![在这里插入图片描述][b591a56584ae422da2b098babf230f1f.png]

#### 问题解决 ####

在静态变量上添加 volatile，不会从缓存中获取run的值，从主存中获取run的值  
`volatile（易变关键字）`它可以用来**修饰成员变量和静态成员变量**，他可以**避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值**，**线程操作 volatile 变量都是直接操作主存**

public class Test32 {
        
        // 易变
        volatile static boolean run = true;
    
        public static void main(String[] args) throws InterruptedException {
        
            Thread t = new Thread(()->{
        
                while(true){
        
                        if(!run) {
        
                            break;
                        }
                }
            });
            t.start();
    
            sleep(1);
            log.debug("停止t");
            run = false; // 线程t不会如预想的停下来
        }
    }

09:49:07.928 c.Test32 [main] - 停止t

### 可见性 vs 原子性 ###

前面例子体现的实际就是可见性，它保证的是在多个线程之间，**一个线程对 volatile 变量的修改对另一个线程可见， 不能保证原子性，仅用在一个写线程，多个读线程的情况**： 上例从字节码理解是这样的：

getstatic run // 线程 t 获取 run true
    getstatic run // 线程 t 获取 run true
    getstatic run // 线程 t 获取 run true
    getstatic run // 线程 t 获取 run true
    putstatic run // 线程 main 修改 run 为 false， 仅此一次
    getstatic run // 线程 t 获取 run false

比较一下之前我们将线程安全时举的例子：两个线程一个 i++ 一个 i-- ，只能保证看到最新值，不能解决指令交错

// 假设i的初始值为0
    getstatic i // 线程2-获取静态变量i的值 线程内i=0
    getstatic i // 线程1-获取静态变量i的值 线程内i=0
    iconst_1 // 线程1-准备常量1
    iadd // 线程1-自增 线程内i=1
    putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1
    iconst_1 // 线程2-准备常量1
    isub // 线程2-自减 线程内i=-1
    putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1

> 注意 synchronized 语句块既可以保证代码块的`原子性`，也同时保证代码块内变量的`可见性`。但`缺点`是  
> `synchronized 是属于重量级操作`，`性能相对更低`  
> 如果在前面示例的死循环中加入 `System.out.println() 会发现即使不加 volatile 修饰符`，线程 t 也能正确看到  
> 对 run 变量的修改了，想一想为什么？

#### 模式之两阶段终止 ####

![在这里插入图片描述][89d564657523471aa8bdb144be784a73.png]

public class Test13 {
        
        public static void main(String[] args) throws InterruptedException {
        
            TwoPhaseTermination tpt = new TwoPhaseTermination();
            tpt.start();
            tpt.start();
            tpt.start();
    
            Thread.sleep(3500);
            log.debug("停止监控");
            tpt.stop();
        }
    }
    
    @Slf4j(topic = "c.TwoPhaseTermination")
    class  TwoPhaseTermination {
        
        // 监控线程
        private Thread monitorThread;
        // 停止标记
        private volatile boolean stop = false;
        // 判断是否执行过 start 方法
        private boolean starting = false;
    
        // 启动监控线程
        public void start() {
        
            synchronized (this) {
        
                if (starting) {
         // false
                    return;
                }
                starting = true;
            }
            monitorThread = new Thread(() -> {
        
                while (true) {
        
                    Thread current = Thread.currentThread();
                    // 是否被打断
                    if (stop) {
        
                        log.debug("料理后事");
                        break;
                    }
                    try {
        
                        Thread.sleep(1000);
                        log.debug("执行监控记录");
                    } catch (InterruptedException e) {
        
                    }
                }
            }, "monitor");
            monitorThread.start();
        }
    
        // 停止监控线程
        public void stop() {
        
            stop = true;
            monitorThread.interrupt();
        }
    }

12:49:50.050 c.TwoPhaseTermination [monitor] - 执行监控记录
    12:49:51.062 c.TwoPhaseTermination [monitor] - 执行监控记录
    12:49:52.075 c.TwoPhaseTermination [monitor] - 执行监控记录
    12:49:52.542 c.TwoPhaseTermination [main] - 停止监控
    12:49:52.543 c.TwoPhaseTermination [monitor] - 料理后事

#### 同步模式之Balking ####

![在这里插入图片描述][f208b5983f8d48fa9c408ffad630c82c.png]  
![在这里插入图片描述][261eb8c854b84775af8a04b7c1483bf1.png]  
![在这里插入图片描述][ff9f06f4ea5545d0af1a0bf313ae1e39.png]

## 3）有序性 ##

### 原理之指令级并行 ###

#### 指令重排序优化 ####

![在这里插入图片描述][d239523b8c10454fb8083465f3efcbff.png]  
![在这里插入图片描述][594662038d0f4f1c85109e75c6552be8.png]

#### 诡异的结果 ####

boolean ready = false;
    // 线程1 执行此方法
    public void actor1(I_Result r) {
        
    	if(ready) {
        
    	r.r1 = num + num;
    	} else {
        
    	r.r1 = 1;
    	}
    }
    // 线程2 执行此方法
    public void actor2(I_Result r) {
        
    	num = 2;
    	ready = true;
    }

I\_Result 是一个对象，有一个属性 r1 用来保存结果，问，可能的结果有几种？  
有同学这么分析  
情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为 1  
情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为1  
情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4（因为 num 已经执行过了）  
但我告诉你，结果还有可能是 0 ，信不信吧！  
这种情况下是：线程2 执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2  
相信很多人已经晕了  
这种现象叫做`指令重排`，是 JIT 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现：  
借助 java 并发压测工具 jcstress https://wiki.openjdk.java.net/display/CodeTools/jcstress

mvn archetype:generate -DinteractiveMode=false -DarchetypeGroupId=org.openjdk.jcstress -
    DarchetypeArtifactId=jcstress-java-test-archetype -DarchetypeVersion=0.5 -DgroupId=cn.itcast -
    DartifactId=ordering -Dversion=1.0

创建 maven 项目，提供如下测试类

@JCStressTest
    @Outcome(id = {
        "1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
    @Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
    @State
    public class ConcurrencyTest {
        
    	int num = 0;
    	boolean ready = false;
    @Actor
    public void actor1(I_Result r) {
        
    	if(ready) {
        
    		r.r1 = num + num;
    	} else {
        
    		r.r1 = 1;
    	}
    }
    @Actor
    public void actor2(I_Result r) {
        
    	num = 2;
    	ready = true;
    }
    }

执行

mvn clean install
    java -jar target/jcstress.jar

会输出我们感兴趣的结果，摘录其中一次结果：\\

*** INTERESTING tests
    Some interesting behaviors observed. This is for the plain curiosity.
    2 matching test results.
    [OK] test.ConcurrencyTest
    (JVM args: [-XX:-TieredCompilation])
    Observed state Occurrences Expectation Interpretation
    0 1,729 ACCEPTABLE_INTERESTING !!!!
    1 42,617,915 ACCEPTABLE ok
    4 5,146,627 ACCEPTABLE ok
    [OK] test.ConcurrencyTest
    (JVM args: [])
    Observed state Occurrences Expectation Interpretation
    0 1,652 ACCEPTABLE_INTERESTING !!!!
    1 46,460,657 ACCEPTABLE ok
    4 4,571,072 ACCEPTABLE ok

可以看到，出现结果为 0 的情况有 638 次，虽然次数相对很少，但毕竟是出现了。

##### 解决方法 #####

volatile 修饰的变量，可以禁用指令重排

@Outcome(id = {
        "1", "4"}, expect = Expect.ACCEPTABLE, desc = "ok")
    @Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "!!!!")
    @State
    public class ConcurrencyTest {
        
    	int num = 0;
    	volatile boolean ready = false;
    	@Actor
    	public void actor1(I_Result r) {
        
    		if(ready) {
        
    			r.r1 = num + num;
    		} else {
        
    			r.r1 = 1;
    		}
    	}
    	@Actor
    	public void actor2(I_Result r) {
        
    		num = 2;
    		ready = true;
    	}
    }

结果为：

*** INTERESTING tests
    Some interesting behaviors observed. This is for the plain curiosity.
    0 matching test results.

[c7b8a9521a0648f9a8c2ffe535b172ec.png]: https://img-blog.csdnimg.cn/c7b8a9521a0648f9a8c2ffe535b172ec.png
[540edd2421fc4dae98590ef5c90888af.png]: https://img-blog.csdnimg.cn/540edd2421fc4dae98590ef5c90888af.png
[b591a56584ae422da2b098babf230f1f.png]: https://img-blog.csdnimg.cn/b591a56584ae422da2b098babf230f1f.png
[89d564657523471aa8bdb144be784a73.png]: https://img-blog.csdnimg.cn/89d564657523471aa8bdb144be784a73.png
[f208b5983f8d48fa9c408ffad630c82c.png]: https://img-blog.csdnimg.cn/f208b5983f8d48fa9c408ffad630c82c.png
[261eb8c854b84775af8a04b7c1483bf1.png]: https://img-blog.csdnimg.cn/261eb8c854b84775af8a04b7c1483bf1.png
[ff9f06f4ea5545d0af1a0bf313ae1e39.png]: https://img-blog.csdnimg.cn/ff9f06f4ea5545d0af1a0bf313ae1e39.png
[d239523b8c10454fb8083465f3efcbff.png]: https://img-blog.csdnimg.cn/d239523b8c10454fb8083465f3efcbff.png
[594662038d0f4f1c85109e75c6552be8.png]: https://img-blog.csdnimg.cn/594662038d0f4f1c85109e75c6552be8.png