看课学校网站建设,wordpress 微信抓取,免费h5页面制作软件工具,做网站与做游戏那个好什么是 happen-before 原则#xff1f;
happen-before 是一个逻辑关系#xff0c;用于描述两个操作之间的 “先后顺序”—— 如果操作 A happen-before 操作 B#xff0c;那么 A 的执行结果必须对 B 可见#xff0c;且 A 的执行顺序在逻辑上先于 B。也就是保证指令有序性和…什么是 happen-before 原则
happen-before 是一个逻辑关系用于描述两个操作之间的 “先后顺序”—— 如果操作 A happen-before 操作 B那么 A 的执行结果必须对 B 可见且 A 的执行顺序在逻辑上先于 B。也就是保证指令有序性和共享变量的可见性。
具体的 happen-before 规则
JMM 定义了 9 条核心 happen-before 规则每条规则都直接或间接关联可见性规则名称描述代码示例可见性体现与说明程序次序规则在同一个线程中按照程序的控制流顺序前面的操作 Happens-Before 于后面的任何操作。int a 1;int b a; // b 一定能看到 a1线程内后面的操作一定能看到前面操作对变量的修改。这是单线程语义的基础。管程锁定规则对一个锁的解锁操作 Happens-Before 于后续对同一个锁的加锁操作。// 线程Asynchronized(lock) { sharedVar 100;} // 解锁// 线程Bsynchronized(lock) { // 加锁 print(sharedVar); // 保证看到100}线程B在获得锁之后一定能看到线程A在释放同一把锁之前对所有共享变量所做的修改。管程(Monitor) 指锁synchronized 及 Lock 实现类如 ReentrantLock都遵守此规则。volatile 变量规则对一个 volatile 变量的写操作 Happens-Before 于后续任何一个对该变量的读操作。// 线程AsharedData ...; // 普通写volatileFlag true; // volatile写// 线程Bif (volatileFlag) { // volatile读 print(sharedData); // 能看到sharedData的修改}线程B读到 volatileFlag 为 true 时不仅能看到 volatileFlag 的最新值也能看到线程A在写 volatileFlag 之前的所有写操作。线程启动规则主线程调用子线程的 start() 方法 Happens-Before 于该子线程中的任何操作。int x 10; // 启动前修改Thread t new Thread(() - { int finalX x; // 子线程读取 System.out.println(finalX); // 输出10});// x 20; // 此处赋值会导致编译错误t.start();子线程开始执行时能看到主线程在调用 start() 之前对effectively final的变量x的修改。注意由于Lambda与匿名内部类要求局部变量是final或effectively final的主线程无法在创建线程后再修改x。 如果x是成员变量那么修改x 20,子线程可以读取到20线程终止规则一个线程中的所有操作都 Happens-Before 于其他线程成功从该线程的 join() 方法返回。// 子线程Thread t new Thread(() - { result compute(); // 子线程中计算});t.start();t.join(); // 等待子线程终止System.out.println(result); // 能看到result的修改主线程在 join() 成功返回后能 guaranteed 看到子线程在执行过程中对共享变量如result的所有修改。线程中断规则调用线程 interrupt() 方法 Happens-Before 于被中断线程检测到中断状态。// 线程AthreadB.interrupt(); // 中断操作// 线程Bif (Thread.interrupted()) { // 一定能感知到中断操作}如果一个线程被中断它之后检测中断状态时一定能看到那个中断请求。对象终结规则一个对象的构造函数执行结束 Happens-Before 于它的 finalize() 方法的开始。public class MyClass { private int value; MyClass() { value 50; // 构造器内初始化 } // 构造结束 protected void finalize() { // 此处一定能看到 value 50 }}保证垃圾回收器在回收对象之前该对象已经被完全正确地初始化了。传递性如果操作 A Happens-Before B且操作 B Happens-Before C那么可以得出操作 A Happens-Before C。// 线程AsharedVar 1; // (A) 普通写volatileFlag true; // (B) volatile写// 线程Cif (volatileFlag) { // (C) volatile读 (B hb C) // 根据传递性: A hb B, B hb C, 所以 A hb C // 故此处能看到 A 的写入结果 (sharedVar1)}该规则是连接其他规则的桥梁使得跨线程的可见性保证能够通过中间操作进行传递。final 字段规则对于一个包含 final 字段的对象其构造函数的结束 Happens-Before 于任何其他线程获取到该对象引用并访问其 final 字段。public class FinalExample { private final int x 42; // final字段}// 其他线程FinalExample obj ...; // 获取对象引用System.out.println(obj.x); // 保证看到42其他线程在拿到一个包含final字段的对象引用后无须额外的同步就能 guaranteed 看到 final 字段被构造器初始化的值。补充说明第四条规则中局部变量与成员变量在匿名内部类中的访问区别
生命周期不匹配
局部变量 x 存储在栈内存中其生命周期与 方法的执行周期相同
匿名内部类对象task存储在堆内存中其生命周期可能比 方法更长
如果允许内部类访问非 final 的局部变量当 方法执行完毕x 的栈帧被销毁后内部类对象可能还在运行这将导致访问无效内存
成员变量 x 存储在堆内存中与匿名内部类对象具有相同的生命周期
内部类通过隐式持有外部类的引用RunnableExample.this来访问成员变量
值捕获机制
Java 通过值捕获来解决这个问题在创建内部类实例时将局部变量的值复制一份到内部类中
为了保证复制值与原始变量的一致性Java 要求局部变量必须是 final 或 effectively final
这样内部类使用的就是捕获时的值快照不会受到外部修改的影响
内部类不是捕获成员变量的值而是通过引用访问它
因此对成员变量的修改会反映到内部类中
总结对比特性局部变量成员变量存储位置栈内存堆内存生命周期与方法调用相同与对象实例相同内部类访问方式值捕获复制引用访问final 要求必须为 final 或 effectively final无要求修改可见性内部类看不到外部修改内部类可以看到外部修改线程安全性由语言机制保证需要开发者自己保证synchronized 关键字
最基础的内置锁通过同步代码块或同步方法实现
进入 synchronized 块加锁时线程会清空本地缓存从主内存加载共享变量的最新值。
退出 synchronized 块解锁时线程会将本地缓存中修改的共享变量刷新到主内存。
示例
private int count 0;// 同步方法
public synchronized void increment() {count; // 解锁时会将修改刷新到主内存
}// 同步代码块
public void getCount() {synchronized (this) {return count; // 加锁时会从主内存加载最新值}
}java.util.concurrent.locks.Lock 接口的实现类
显式锁最常用的实现是 ReentrantLock还包括 ReentrantReadWriteLock 等
调用 lock() 方法加锁时线程会失效本地缓存强制从主内存加载变量。
调用 unlock() 方法解锁时线程会将本地缓存中的修改刷新到主内存。
示例ReentrantLock
private final Lock lock new ReentrantLock();
private int count 0;public void increment() {lock.lock();try {count; // 解锁时刷新到主内存} finally {lock.unlock();}
}public int getCount() {lock.lock();try {return count; // 加锁时从主内存加载} finally {lock.unlock();}
}读写锁 ReentrantReadWriteLock
分离读锁和写锁更细粒度的控制
写锁writeLock()获取时会强制加载最新值释放时会刷新修改到主内存同普通锁。
读锁readLock()多个线程可同时获取能看到之前写锁释放的所有修改保证读操作可见性。
著名的双重检查单例模式
public class Singleton {// 关键1使用volatile修饰单例实例private static volatile Singleton instance;// 关键2私有构造函数防止外部直接实例化private Singleton() {// 初始化逻辑}// 关键3双重检查锁定获取实例public static Singleton getInstance() {// 第一次检查避免不必要的同步提高性能if (instance null) {// 关键4同步块保证多线程安全synchronized (Singleton.class) {// 第二次检查防止多线程同时进入同步块后重复创建实例if (instance null) {// 关键5创建实例volatile在此处防止指令重排序instance new Singleton();}}}return instance;}
}关键代码解析
volatile 修饰符的作用
volatile 在这里有两个核心作用
保证 instance 变量的可见性多线程环境下一个线程对 instance 的修改会立即被其他线程感知因为第一次检查并使用synchronized 关键字将instance 包含在内所以必须使用volatile关键字保证可见性。
禁止指令重排序这是 DCL 模式中 volatile 的核心价值。
双重检查的意义
第一次检查同步块外避免每次调用 getInstance() 都进入同步块提高性能多数情况下 instance 已初始化无需同步。
第二次检查同步块内防止多个线程同时通过第一次检查后在同步块内重复创建实例。
volatile 如何禁止指令重排序
对象创建过程instance new Singleton()在 JVM 中会被拆分为三步操作
1. memory allocate(); // 分配内存空间
2. ctorInstance(memory); // 初始化对象执行构造函数
3. instance memory; // 将引用指向内存地址问题场景
如果没有 volatile 修饰编译器或 CPU 可能对步骤 2 和 3 进行重排序导致执行顺序变为1 → 3 → 2。
此时会出现严重问题
线程 A 执行到步骤 3 后instance 已非 null引用已指向内存但步骤 2 尚未完成对象未初始化。
线程 B 此时进行第一次检查instance null会发现 instance 不为 null直接返回一个未初始化完成的对象导致程序异常。
volatile 的解决方案
volatile 通过在对象创建指令前后插入内存屏障Memory Barrier 禁止这种重排序
在步骤 3 之后插入 StoreStore 屏障禁止初始化对象步骤 2与设置引用步骤 3的重排序。
在步骤 3 之后插入 StoreLoad 屏障确保引用赋值步骤 3完成后才允许其他线程读取 instance。
这两个内存屏障强制保证了执行顺序为 1 → 2 → 3即对象完全初始化后才会将引用赋值给 instance从而避免线程 B 读取到未初始化的对象。
