再谈多线程
在我们的操作系统之上，可以同时运行很多个进程，并且每个进程之间相互隔离互不干扰。
我们的CPU会通过时间片轮转算法，为每一个进程分配时间片，并在时间片使用结束后切换下一个进程继续执行，通过这种方式来实现宏观上的多个程序同时运行。
由于每个进程都有一个自己的内存空间，进程之间的通信就变得非常麻烦（比如要共享某些数据）而且执行不同进程会产生上下文切换，非常耗时，那么有没有一种更好地方案呢？
后来，线程横空出世，一个进程可以有多个线程，线程是程序执行中一个单一的顺序控制流程，现在线程才是程序执行流的最小单元，各个线程之间共享程序的内存空间（也就是所在进程的内存空间），上下文切换速度也高于进程。
现在有这样一个问题：
public static void main(String[] args) {
int[] arr = new int[]{3, 1, 5, 2, 4};
//请将上面的数组按升序输出
}
按照正常思维，我们肯定是这样：
public static void main(String[] args) {
int[] arr = new int[]{3, 1, 5, 2, 4};
//直接排序吧
Arrays.sort(arr);
for (int i : arr) {
System.out.println(i);
}
}
而我们学习了多线程之后，可以换个思路来实现：
public static void main(String[] args) {
int[] arr = new int[]{3, 1, 5, 2, 4};
for (int i : arr) {
new Thread(() -> {
try {
Thread.sleep(i * 1000); //越小的数休眠时间越短，优先被打印
System.out.println(i);
} catch (InterruptedException e) {
e.printStackTrace();
}
}).start();
}
}
我们接触过的很多框架都在使用多线程，比如Tomcat服务器，所有用户的请求都是通过不同的线程来进行处理的，这样我们的网站才可以同时响应多个用户的请求，要是没有多线程，可想而知服务器的处理效率会有多低。
在Java 5的时候，新增了java.util.concurrent（JUC）包，其中包括大量用于多线程编程的工具类，目的是为了更好的支持高并发任务，让开发者进行多线程编程时减少竞争条件和死锁的问题！
并发与并行
我们经常听到并发编程，那么这个并发代表的是什么意思呢？而与之相似的并行又是什么意思？它们之间有什么区别？
比如现在一共有三个工作需要我们去完成。
image.png
顺序执行
顺序执行其实很好理解，就是我们依次去将这些任务完成了：
image.png
实际上就是我们同一时间只能处理一个任务，所以需要前一个任务完成之后，才能继续下一个任务，依次完成所有任务。
并发执行
并发执行也是我们同一时间只能处理一个任务，但是我们可以每个任务轮着做（时间片轮转）：
image.png
而我们Java中的线程，正是这种机制，当我们需要同时处理上百个上千个任务时，很明显CPU的数量是不可能赶得上我们的线程数的，所以说这时就要求我们的程序有良好的并发性能，来应对同一时间大量的任务处理。
学习Java并发编程，能够让我们在以后的实际场景中，知道该如何应对高并发的情况。
并行执行
并行执行就突破了同一时间只能处理一个任务的限制，我们同一时间可以做多个任务：
image.png
比如我们要进行一些排序操作，就可以用到并行计算，只需要等待所有子任务完成，最后将结果汇总即可。包括分布式计算模型MapReduce，也是采用的并行计算思路。
再谈锁机制
谈到锁机制，相信各位应该并不陌生了，我们在JavaSE阶段，通过使用synchronized关键字来实现锁，
这样就能够很好地解决线程之间争抢资源的情况。
那么，synchronized底层到底是如何实现的呢？
我们知道，使用synchronized，一定是和某个对象相关联的，比如我们要对某一段代码加锁，那么我们就需要提供一个对象来作为锁本身：
public static void main(String[] args) {
synchronized (Main.class) {
//这里使用的是Main类的Class对象作为锁
}
}
我们来看看，它变成字节码之后会用到哪些指令：
image.png
其中最关键的就是monitorenter指令了，可以看到之后也有monitorexit与之进行匹配（注意这里有2个），monitorenter和monitorexit分别对应加锁和释放锁，在执行monitorenter之前需要尝试获取锁。
每个对象都有一个monitor监视器与之对应，而这里正是去获取对象监视器的所有权，一旦monitor所有权被某个线程持有，那么其他线程将无法获得（管程模型的一种实现）。
在代码执行完成之后，我们可以看到，一共有两个monitorexit在等着我们，那么为什么这里会有两个呢？
按理说monitorenter和monitorexit不应该一一对应吗，这里为什么要释放锁两次呢？
首先我们来看第一个，这里在释放锁之后，会马上进入到一个goto指令，
跳转到15行，而我们的15行对应的指令就是方法的返回指令，其实正常情况下只会执行第一个monitorexit释放锁，在释放锁之后就接着同步代码块后面的内容继续向下执行了。
而第二个，其实是用来处理异常的，可以看到，它的位置是在12行，如果程序运行发生异常，那么就会执行第二个monitorexit，并且会继续向下通过athrow指令抛出异常，而不是直接跳转到15行正常运行下去。
image.png
实际上synchronized使用的锁就是存储在Java对象头中的，我们知道，对象是存放在堆内存中的，而每个对象内部，都有一部分空间用于存储对象头信息。
而对象头信息中，则包含了Mark Word用于存放hashCode和对象的锁信息，在不同状态下，它存储的数据结构有一些不同。
image.png
重量级锁
在JDK6之前，synchronized一直被称为重量级锁，monitor依赖于底层操作系统的Lock实现。
Java的线程是映射到操作系统的原生线程上，切换成本较高。而在JDK6之后，锁的实现得到了改进。
我们先从最原始的重量级锁开始：
我们说了，每个对象都有一个monitor与之关联，在Java虚拟机（HotSpot）中，monitor是由ObjectMonitor实现的：
ObjectMonitor() {
_header = NULL;
_count = 0; //记录个数
_waiters = 0,
_recursions = 0;
_object = NULL;
_owner = NULL;
_WaitSet = NULL; //处于wait状态的线程，会被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ; //处于等待锁block状态的线程，会被加入到该列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
}
每个等待锁的线程都会被封装成ObjectWaiter对象，进入到如下机制：
image.png
设计思路：
ObjectWaiter首先会进入 Entry Set等着，
当线程获取到对象的monitor后进入 The Owner 区域并把monitor中的owner变量设置为当前线程，
同时monitor中的计数器count加1，若线程调用wait()方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，
同时该线程进入 WaitSet集合中等待被唤醒。若当前线程执行完毕也将释放monitor并复位变量的值，以便其他线程进入获取对象的monitor。
虽然这样的设计思路非常合理，但是在大多数应用上，每一个线程占用同步代码块的时间并不是很长，我们完全没有必要将竞争中的线程挂起然后又唤醒，并且现代CPU基本都是多核心运行的，我们可以采用一种新的思路来实现锁。
新思路：
在JDK1.4.2时，引入了自旋锁（JDK6之后默认开启），它不会将处于等待状态的线程挂起，而是通过无限循环的方式，不断检测是否能够获取锁。
由于单个线程占用锁的时间非常短，所以说循环次数不会太多，可能很快就能够拿到锁并运行，这就是自旋锁。
当然，仅仅是在等待时间非常短的情况下，自旋锁的表现会很好，但是如果等待时间太长，由于循环是需要处理器继续运算的，所以这样只会浪费处理器资源，因此自旋锁的等待时间是有限制的，默认情况下为10次，如果失败，那么会进而采用重量级锁机制。
image.png
在JDK6之后，自旋锁得到了一次优化，自旋的次数限制不再是固定的，而是自适应变化的。
比如在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行，那么这次自旋也是有可能成功的，所以会允许自旋更多次。
当然，如果某个锁经常都自旋失败，那么有可能会不再采用自旋策略，而是直接使用重量级锁。
轻量级锁
从JDK 1.6开始，为了减少获得锁和释放锁带来的性能消耗，就引入了轻量级锁。
轻量级锁的目标是，在无竞争情况下，减少重量级锁产生的性能消耗
（并不是为了代替重量级锁，实际上就是赌一手同一时间只有一个线程在占用资源），
包括系统调用引起的内核态与用户态切换、线程阻塞造成的线程切换等。
它不像是重量级锁那样，需要向操作系统申请互斥量。
运作机制：
在即将开始执行同步代码块中的内容时，会首先检查对象的Mark Word，查看锁对象是否被其他线程占用，
如果没有任何线程占用，那么会在当前线程中所处的栈帧中建立一个名为锁记录（Lock Record）的空间，用于复制并存储对象目前的Mark Word信息（官方称为Displaced Mark Word）。
接着，虚拟机将使用CAS操作将对象的Mark Word更新为轻量级锁状态（数据结构变为指向Lock Record的指针，指向的是当前的栈帧）
CAS（Compare And Swap）是一种无锁算法，
它并不会为对象加锁，而是在执行的时候，看看当前数据的值是不是我们预期的那样，
如果是，那就正常进行替换，
如果不是，那么就替换失败。
比如有两个线程都需要修改变量i的值，默认为10，
现在一个线程要将其修改为20，另一个要修改为30，
如果他们都使用CAS算法，那么并不会加锁访问i，而是直接尝试修改i的值，
但是在修改时，需要确认i是不是10，
如果是，表示其他线程还没对其进行修改，
如果不是，那么说明其他线程已经将其修改，此时不能完成修改任务，修改失败。
在CPU中，CAS操作使用的是cmpxchg指令，能够从最底层硬件层面得到效率的提升。
如果CAS操作失败了的话，那么说明可能这时有线程已经进入这个同步代码块了，
这时虚拟机会再次检查对象的Mark Word，是否指向当前线程的栈帧，
如果是，说明不是其他线程，而是当前线程已经有了这个对象的锁，直接放心大胆进同步代码块即可。
如果不是，那确实是被其他线程占用了。
这时，轻量级锁一开始的想法就是错的（这时有对象在竞争资源，已经赌输了），所以说只能将锁膨胀为重量级锁，按照重量级锁的操作执行（注意锁的膨胀是不可逆的）
如图所示：
image.png
所以，轻量级锁 -> 失败 -> 自适应自旋锁 -> 失败 -> 重量级锁
解锁过程同样采用CAS算法，如果对象的MarkWord仍然指向线程的锁记录，
那么就用CAS操作把对象的MarkWord和复制到栈帧中的Displaced Mark Word进行交换。
如果替换失败，说明其他线程尝试过获取该锁，在释放锁的同时，需要唤醒被挂起的线程。
偏向锁
偏向锁相比轻量级锁更纯粹，干脆就把整个同步都消除掉，不需要再进行CAS操作了。
它的出现主要是得益于人们发现某些情况下某个锁频繁地被同一个线程获取，
这种情况下，我们可以对轻量级锁进一步优化。
偏向锁实际上就是专门为单个线程而生的，当某个线程第一次获得锁时，如果接下来都没有其他线程获取此锁，那么持有锁的线程将不再需要进行同步操作。
可以从之前的MarkWord结构中看到，偏向锁也会通过CAS操作记录线程的ID，如果一直都是同一个线程获取此锁，那么完全没有必要在进行额外的CAS操作。
当然，如果有其他线程来抢了，那么偏向锁会根据当前状态，决定是否要恢复到未锁定或是膨胀为轻量级锁。
如果我们需要使用偏向锁，可以添加-XX:+UseBiased参数来开启。
所以，最终的锁等级为：未锁定 < 偏向锁 < 轻量级锁 < 重量级锁
值得注意的是，如果对象通过调用hashCode()方法计算过对象的一致性哈希值，
那么它是不支持偏向锁的，会直接进入到轻量级锁状态，
因为Hash是需要被保存的，而偏向锁的Mark Word数据结构，无法保存Hash值；
如果对象已经是偏向锁状态，再去调用hashCode()方法，那么会直接将锁升级为重量级锁，并将哈希值存放在monitor（有预留位置保存）中。
image.png
锁消除和锁粗化
锁消除和锁粗化都是在运行时的一些优化方案。
比如我们某段代码虽然加了锁，但是在运行时根本不可能出现各个线程之间资源争夺的情况，
这种情况下，完全不需要任何加锁机制，所以锁会被消除。
锁粗化则是我们代码中频繁地出现互斥同步操作，比如在一个循环内部加锁，这样明显是非常消耗性能的，所以虚拟机一旦检测到这种操作，会将整个同步范围进行扩展。
JMM内存模型
注意这里提到的内存模型和我们在JVM中介绍的内存模型不在同一个层次，
JVM中的内存模型是虚拟机规范对整个内存区域的规划，
而Java内存模型，是在JVM内存模型之上的抽象模型，具体实现依然是基于JVM内存模型实现的，以前的文章有介绍。
https://www.cnblogs.com/zwtblog/tag/，侧边栏支持搜索。
Java内存模型
我们在计算机组成原理中学习过，在我们的CPU中，一般都会有高速缓存，而它的出现，是为了解决内存的速度跟不上处理器的处理速度的问题。
所以CPU内部会添加一级或多级高速缓存来提高处理器的数据获取效率，
但是这样也会导致一个很明显的问题，因为现在基本都是多核心处理器，每个处理器都有一个自己的高速缓存，那么又该怎么去保证每个处理器的高速缓存内容一致呢？
image.png
为了解决缓存一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作。
这类协议有MSI、MESI（Illinois Protocol）、MOSI、Synapse、Firefly及Dragon Protocol等。
而Java也采用了类似的模型来实现支持多线程的内存模型：
image.png
JMM（Java Memory Model）内存模型规定如下：
- 所有的变量全部存储在主内存（注意这里包括下面提到的变量，指的都是会出现竞争的变量，包括成员变量、静态变量等，而局部变量这种属于线程私有，不包括在内）
- 每条线程有着自己的工作内存（可以类比CPU的高速缓存）线程对变量的所有操作，必须在工作内存中进行，不能直接操作主内存中的数据。
- 不同线程之间的工作内存相互隔离，如果需要在线程之间传递内容，只能通过主内存完成，无法直接访问对方的工作内存。
也就是说，每一条线程如果要操作主内存中的数据，那么得先拷贝到自己的工作内存中，并对工作内存中数据的副本进行操作，操作完成之后，也需要从工作副本中将结果拷贝回主内存中，具体的操作就是Save（保存）和Load（加载）操作。
那么各位肯定会好奇，这个内存模型，结合之前JVM所讲的内容，具体是怎么实现的呢？
- 主内存：对应堆中存放对象的实例的部分。
- 工作内存：对应线程的虚拟机栈的部分区域，虚拟机可能会对这部分内存进行优化，
- 将其放在CPU的寄存器或是高速缓存中。
- 比如在访问数组时，由于数组是一段连续的内存空间，
- 所以可以将一部分连续空间放入到CPU高速缓存中，那么之后如果我们顺序读取这个数组，那么大概率会直接缓存命中。
前面我们提到，在CPU中可能会遇到缓存不一致的问题，而Java中，也会遇到，比如下面这种情况：
public class Main {
private static int i = 0;
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
for (int j = 0; j < 100000; j++) i++;
System.out.println("线程1结束");
}).start();
new Thread(() -> {
for (int j = 0; j < 100000; j++) i++;
System.out.println("线程2结束");
}).start();
//等上面两个线程结束
Thread.sleep(1000);
System.out.println(i);
}
}
可以看到这里是两个线程同时对变量i各自进行100000次自增操作，但是实际得到的结果并不是我们所期望的那样。
那么为什么会这样呢？
在之前学习了JVM之后，相信各位应该已经知道，自增操作实际上并不是由一条指令完成的（注意一定不要理解为一行代码就是一个指令完成的）：
image.png
包括变量i的获取、修改、保存，都是被拆分为一个一个的操作完成的，那么这个时候就有可能出现在修改完保存之前，另一条线程也保存了，但是当前线程是毫不知情的。
image.png
所以说，在JavaSE阶段讲解这个问题的时候，是通过synchronized关键字添加同步代码块解决的，另外的解决方案（原子类）。
重排序
在编译或执行时，为了优化程序的执行效率，编译器或处理器常常会对指令进行重排序，有以下情况：
- 编译器重排序：Java编译器通过对Java代码语义的理解，根据优化规则对代码指令进行重排序。
- 机器指令级别的重排序：现代处理器很高级，能够自主判断和变更机器指令的执行顺序。
指令重排序能够在不改变结果（单线程）的情况下，优化程序的运行效率，比如：
public static void main(String[] args) {
int a = 10;
int b = 20;
System.out.println(a + b);
}
我们其实可以交换第一行和第二行：
public static void main(String[] args) {
int b = 10;
int a = 20;
System.out.println(a + b);
}
即使发生交换，但是我们程序最后的运行结果是不会变的，当然这里只通过代码的形式演示，实际上JVM在执行字节码指令时也会进行优化，可能两个指令并不会按照原有的顺序进行。
虽然单线程下指令重排确实可以起到一定程度的优化作用，但是在多线程下，似乎会导致一些问题：
public class Main {
private static int a = 0;
private static int b = 0;
public static void main(String[] args) {
new Thread(() -> {
if(b == 1) {
if(a == 0) {
System.out.println("A");
}else {
System.out.println("B");
}
}
}).start();
new Thread(() -> {
a = 1;
b = 1;
}).start();
}
}
上面这段代码，在正常情况下，按照我们的正常思维，是不可能输出A的，因为只要b等于1，那么a肯定也是1才对，因为a是在b之前完成的赋值。
但是，如果进行了重排序，那么就有可能，a和b的赋值发生交换，b先被赋值为1，而恰巧这个时候，线程1开始判定b是不是1了，这时a还没来得及被赋值为1，可能线程1就已经走到打印那里去了，所以，是有可能输出A的。
volatile关键字
关键字volatile，开始之前我们先介绍三个词语：
原子性：其实之前讲过很多次了，就是要做什么事情要么做完，要么就不做，不存在做一半的情况。
可见性：指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值。
有序性：即程序执行的顺序按照代码的先后顺序执行。
我们之前说了，如果多线程访问同一个变量，那么这个变量会被线程拷贝到自己的工作内存中进行操作，而不是直接对主内存中的变量本体进行操作。
下面这个操作看起来是一个有限循环，但是是无限的：
public class Main {
private static int a = 0;
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
while (a == 0);
System.out.println("线程结束！");
}).start();
Thread.sleep(1000);
System.out.println("正在修改a的值...");
a = 1; //很明显，按照我们的逻辑来说，a的值被修改那么另一个线程将不再循环
}
}
实际上这就是我们之前说的，虽然我们主线程中修改了a的值，但是另一个线程并不知道a的值发生了改变，所以循环中依然是使用旧值在进行判断，因此，普通变量是不具有可见性的。
要解决这种问题，我们第一个想到的肯定是加锁，同一时间只能有一个线程使用，这样总行了吧，确实，这样的话肯定是可以解决问题的：
public class Main {
private static int a = 0;
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
while (a == 0) {
synchronized (Main.class){}
}
System.out.println("线程结束！");
}).start();
Thread.sleep(1000);
System.out.println("正在修改a的值...");
synchronized (Main.class){
a = 1;
}
}
}
但是，除了硬加一把锁的方案，我们也可以使用volatile关键字来解决。
此关键字的第一个作用，就是保证变量的可见性。
当写一个volatile变量时，JMM会把该线程本地内存中的变量强制刷新到主内存中去，并且这个写会操作会导致其他线程中的volatile变量缓存无效。
这样，另一个线程修改了这个变时，当前线程会立即得知，并将工作内存中的变量更新为最新的版本。
那么我们就来试试看：
public class Main {
//添加volatile关键字
private static volatile int a = 0;
public static void main(String[] args) throws InterruptedException {
new Thread(() -> {
while (a == 0);
System.out.println("线程结束！");
}).start();
Thread.sleep(1000);
System.out.println("正在修改a的值...");
a = 1;
}
}
结果还真的如我们所说的那样，当a发生改变时，循环立即结束。
当然，虽然说volatile能够保证可见性，但是不能保证原子性，要解决我们上面的i++的问题，可以使用加锁来完成：
public class Main {
private static volatile int a = 0;
public static void main(String[] args) throws InterruptedException {
Runnable r = () -> {
for (int i = 0; i < 10000; i++) a++;
System.out.println("任务完成！");
};
new Thread(r).start();
new Thread(r).start();
//等待线程执行完成
Thread.sleep(1000);
System.out.println(a);
}
}
volatile不是能在改变变量的时候其他线程可见吗，那为什么还是不能保证原子性呢？
还是那句话，自增操作是被瓜分为了多个步骤完成的，虽然保证了可见性，但是只要手速够快，依然会出现两个线程同时写同一个值的问题（比如线程1刚刚将a的值更新为100，这时线程2可能也已经执行到更新a的值这条指令了，已经刹不住车了，所以依然会将a的值再更新为一次100）
那要是真的遇到这种情况，那么我们不可能都去写个锁吧？后面，我们会介绍原子类来专门解决这种问题。
最后一个功能就是volatile会禁止指令重排，也就是说，如果我们操作的是一个volatile变量，它将不会出现重排序的情况.
那么它是怎么解决的重排序问题呢？
若用volatile修饰共享变量，在编译时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序
内存屏障（Memory Barrier）又称内存栅栏，是一个CPU指令，它的作用有两个：
保证特定操作的顺序保证某些变量的内存可见性（volatile的内存可见性，其实就是依靠这个实现的）
由于编译器和处理器都能执行指令重排的优化，
如果在指令间插入一条Memory Barrier则会告诉编译器和CPU，
不管什么指令都不能和这条Memory Barrier指令重排序。
屏障类型指令示例说明LoadLoadLoad1;LoadLoad;Load2保证Load1的读取操作在Load2及后续读取操作之前执行StoreStoreStore1;StoreStore;Store2在Store2及其后的写操作执行前，保证Store1的写操作已刷新到主内存LoadStoreLoad1;LoadStore;Store2在Store2及其后的写操作执行前，保证Load1的读操作已读取结束StoreLoadStore1;StoreLoad;Load2保证load1的写操作已刷新到主内存之后，load2及其后的读操作才能执行
所以volatile能够保证，之前的指令一定全部执行，之后的指令一定都没有执行，并且前面语句的结果对后面的语句可见。
最后我们来总结一下volatile关键字的三个特性：
保证可见性
不保证原子性
防止指令重排
在之后我们的设计模式系列视频中，还会讲解单例模式下volatile的运用。
happens-before原则
经过我们前面的讲解，相信各位已经了解了JMM内存模型以及重排序等机制带来的优点和缺点.
综上，JMM提出了happens-before（先行发生）原则，定义一些禁止编译优化的场景，来向各位程序员做一些保证，只要我们是按照原则进行编程，那么就能够保持并发编程的正确性。具体如下：
程序次序规则：同一个线程中，按照程序的顺序，前面的操作happens-before后续的任何操作。
同一个线程内，代码的执行结果是有序的。
其实就是，可能会发生指令重排，但是保证代码的执行结果一定是和按照顺序执行得到的一致，
程序前面对某一个变量的修改一定对后续操作可见的，不可能会出现前面才把a修改为1，
接着读a居然是修改前的结果，这也是程序运行最基本的要求。
监视器锁规则：对一个锁的解锁操作，happens-before后续对这个锁的加锁操作。
就是无论是在单线程环境还是多线程环境，
对于同一个锁来说，一个线程对这个锁解锁之后，另一个线程获取了这个锁都能看到前一个线程的操作结果。
比如前一个线程将变量x的值修改为了12并解锁，
之后另一个线程拿到了这把锁，对之前线程的操作是可见的，可以得到x是前一个线程修改后的结果12（所以synchronized是有happens-before规则的）
volatile变量规则：对一个volatile变量的写操作happens-before后续对这个变量的读操作。
就是如果一个线程先去写一个volatile变量，紧接着另一个线程去读这个变量，那么这个写操作的结果一定对读的这个变量的线程可见。
线程启动规则：主线程A启动线程B，线程B中可以看到主线程启动B之前的操作。
在主线程A执行过程中，启动子线程B，那么线程A在启动子线程B之前对共享变量的修改结果对线程B可见。
线程加入规则：如果线程A执行操作join()线程B并成功返回，那么线程B中的任意操作happens-before线程Ajoin()操作成功返回。
传递性规则：如果A happens-before B，B happens-before C，那么A happens-before C。
那么我们来从happens-before原则的角度，来解释一下下面的程序结果：
public class Main {
private static int a = 0;
private static int b = 0;
public static void main(String[] args) {
a = 10;
b = a + 1;
new Thread(() -> {
if(b > 10) System.out.println(a);
}).start();
}
}
首先我们定义以上出现的操作：
A：将变量a的值修改为10
B：将变量b的值修改为a + 1
C：主线程启动了一个新的线程，并在新的线程中获取b，进行判断，如果为true那么就打印a
首先我们来分析，由于是同一个线程，并且B是一个赋值操作且读取了A，
那么按照程序次序规则，A happens-before B，接着在B之后，马上执行了C，按照线程启动规则，
在新的线程启动之前，当前线程之前的所有操作对新的线程是可见的，
所以 B happens-before C，
最后根据传递性规则，由于A happens-before B，B happens-before C，所以A happens-before C，因此在新的线程中会输出a修改后的结果10。
网友评论