《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！
// 以下操作在线程 A 中执行
i = 1; // a
// 以下操作在线程 B 中执行
j = i; // b
// 以下操作在线程 C 中执行
i = 2; // c
假设线程 A 中的操作 a Happens-before 线程 B 的操作 b，那我们就可以确定操作 b 执行后，变量 j 的值一定是等于 1。
得出这个结论的依据有两个：一是根据 Happens-before 原则，a 操作的结果对 b 可见，即 “i=1” 的结果可以被观察到；二是线程 C 还没运行，线程 A 操作结束之后没有其他线程会修改变量 i 的值。
现在再来考虑线程 C，我们依然保持 a Happens-before b ，而 c 出现在 a 和 b 的操作之间，但是 c 与 b 没有 Happens-before 关系，也就是说 b 并不一定能看到 c 的操作结果。那么 b 操作的结果也就是 j 的值就不确定了，可能是 1 也可能是 2，那这段代码就是线程不安全的。
再来看 Happens-before 的第 2 条定义，这是 JMM 对编译器和处理器弱内存模型的保证，在给予充分的可操作空间下，对编译器和处理器的重排序进行一定的约束。也就是说，JMM 其实是在遵循一个基本原则：只要不改变程序的执行结果（指的是单线程程序和正确同步的多线程程序），编译器和处理器怎么优化都行。
JMM 这么做的原因是：程序员对于这两个操作是否真的被重排序并不关心，程序员关心的是执行结果不能被改变。
文字可能不是很好理解，我们举个例子，来解释下第 2 条定义：虽然两个操作之间存在 Happens-before 关系，但不意味着 Java 平台的具体实现必须要按照 Happens-before 关系指定的顺序来执行。
int a = 1; // A
int b = 2; // B
int c = a + b; // C
根据 Happens-before 规则（下文会讲），上述代码存在 3 个 Happens-before 关系：
-
A Happens-before B
-
B Happens-before C
-
A Happens-before C
可以看出来，在 3 个 Happens-before 关系中，第 2 个和第 3 个是必需的，但第 1 个是不必要的。
也就是说，虽然 A Happens-before B，但是 A 和 B 之间的重排序完全不会改变程序的执行结果，所以 JMM 是允许编译器和处理器执行这种重排序的。
看下面这张 JMM 的设计图更直观：
其实，可以这么简单地理解，为了避免 Java 程序员为了理解 JMM 提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现方法，JMM 就出了这么一个简单易懂的 Happens-before 原则，一个 Happens-before 规则就对应于一个或多个编译器和处理器的重排序规则，这样，我们只需要弄明白 Happens-before 就行了。
8 条 Happens-before 规则
=====================
《JSR-133:Java Memory Model and Thread Specification》定义了如下 Happens-before 规则， 这些就是 JMM 中“天然的” Happens-before 关系，这些 Happens-before 关系无须任何同步器协助就已经存在，可以在编码中直接使用。如果两个操作之间的关系不在此列，并且无法从下列规则推导出来，则它们就没有顺序性保障，JVM 可以对它们随意地进行重排序：
1）程序次序规则（Program Order Rule）：在一个线程内，按照控制流顺序，书写在前面的操作先行发生（Happens-before）于书写在后面的操作。注意，这里说的是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。
这个很好理解，符合我们的逻辑思维。比如我们上面举的例子：
int a = 1; // A
int b = 2; // B
int c = a + b; // C
根据程序次序规则，上述代码存在 3 个 Happens-before 关系：
-
A Happens-before B
-
B Happens-before C
-
A Happens-before C
2）管程锁定规则（Monitor Lock Rule）：一个 unlock 操作先行发生于后面对同一个锁的 lock 操作。这里必须强调的是 “同一个锁”，而 “后面” 是指时间上的先后。
这个规则其实就是针对 synchronized 的。JVM 并没有把 lock 和 unlock 操作直接开放给用户使用，但是却提供了更高层次的字节码指令 monitorenter 和 monitorexit 来隐式地使用这两个操作。这两个字节码指令反映到 Java 代码中就是同步块 — synchronized。
举个例子：
synchronized (this) { // 此处自动加锁
if (x < 1) {
x = 1;
}
} // 此处自动解锁
根据管程锁定规则，假设 x 的初始值是 10，线程 A 执行完代码块后 x 的值会变成 1，执行完自动释放锁，线程 B 进入代码块时，能够看到线程 A 对 x 的写操作，也就是线程 B 能够看到 x == 1。
3）volatile 变量规则（Volatile Variable Rule）：对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作，这里的 “后面” 同样是指时间上的先后。
这个规则就是 JDK 1.5 版本对 volatile 语义的增强，其意义之重大，靠着这个规则搞定可见性易如反掌。
举个例子：
假设线程 A 执行 writer() 方法之后，线程 B 执行 reader() 方法。
根据根据程序次序规则：1 Happens-before 2；3 Happens-before 4。
根据 volatile 变量规则：2 Happens-before 3。
根据传递性规则：1 Happens-before 3；1 Happens-before 4。
也就是说，如果线程 B 读到了 “flag==true” 或者 “int i = a” 那么线程 A 设置得“a=42”对线程 B 是可见的。
看下图：
4）线程启动规则（Thread Start Rule）：Thread 对象的 start() 方法先行发生于此线程的每一个动作。
比如说主线程 A 启动子线程 B 后，子线程 B 能够看到主线程在启动子线程 B 前的所有操作。
5）线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过 Thread 对象的 join() 方法是否结束、Thread 对象的 isAlive() 的返回值等手段检测线程是否已经终止执行。
6）线程中断规则（Thread Interruption Rule）：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过 Thread 对象的 interrupted() 方法检测到是否有中断发生。
7）对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的 finalize() 方法的开始。
8）传递性（Transitivity）：如果操作 A 先行发生于操作 B，操作 B 先行发生于操作 C，那就可以得出操作 A 先行发生于操作 C 的结论。
“时间上的先发生” 与 “先行发生”
==================
上述 8 种规则中，还不断提到了时间上的先后，那么，“时间上的先发生” 与 “先行发生（Happens-before）” 到底有啥区别？
一个操作 “时间上的先发生” 是否就代表这个操作会是“先行发生” 呢？一个操作 “先行发生” 是否就能推导出这个操作必定是“时间上的先发生”呢？
很遗憾，这两个推论都是不成立的。
举两个例子论证一下：
private int value = 0;
// 线程 A 调用
pubilc void setValue(int value){
this.value = value;
}
// 线程 B 调用
最后总结我的面试经验
2021年的金三银四一眨眼就到了，对于很多人来说是跳槽的好机会，大厂面试远没有我们想的那么困难，摆好心态，做好准备，你也可以的。
另外，面试中遇到不会的问题不妨尝试讲讲自己的思路，因为有些问题不是考察我们的编程能力，而是逻辑思维表达能力；最后平时要进行自我分析与评价，做好职业规划，不断摸索，提高自己的编程能力和抽象思维能力。
BAT面试经验
实战系列：Spring全家桶+Redis等
其他相关的电子书：源码+调优
面试真题：
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！
图片转存中…(img-9LLvscUL-1714697656475)]
其他相关的电子书：源码+调优
[外链图片转存中…(img-Pbf5um6W-1714697656475)]
面试真题：
[外链图片转存中…(img-HxrUuPpv-1714697656475)]
[外链图片转存中…(img-ho20uLgH-1714697656475)]
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门，即可获取！
420
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
