线程sleep结束后会重新load主存吗?

前言

该问题在看JUC课程的时候遇到,记录一下

背景知识
  • 该问题主要与可见性有关
  • 从JMM我们可以知道,线程先将变量从主内存拷贝到工作内存,更新完成后再刷新回主内存。
  • 此时如果有多个线程并发修改共享变量,就会出现,A、B同时拷贝变量到工作内存,A修改后,B是感受不到的

举个例子

@Slf4j(topic = "c.VolatileDemo")
public class VolatileDemo {
    static  int cache = 0;
    public static void main(String[] args) {
        new Thread(() -> {
            try {TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) {e.printStackTrace(); }
            cache = 1;
            log.debug("cache=1");
        }, "t1").start();

        new Thread(() -> {
            while(cache!=1){
            }
            log.debug("捕捉到cache改变");
        }, "t2").start();
    }
}
  1. 上述例子中,t1线程对cache进行了修改,t2是感知不到的
  2. 结果就是t2线程一直while循环,不会捕捉到改变
  3. 这是一个描述可见性很好的例子

那么解决办法是给cache变量添加volatile关键字

问题

问题是在实践的过程中发现,线程在sleep后,会重新从主内存获取共享变量。即代码如下,不加volatile也能捕捉改变

@Slf4j(topic = "c.VolatileDemo")
public class VolatileDemo {
    static  int cache = 0;
    public static void main(String[] args) {
        new Thread(() -> {
            try {TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) {e.printStackTrace(); }
            cache = 1;
            log.debug("cache=1");
        }, "t1").start();

        new Thread(() -> {
            while(cache!=1){
                try {
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
            log.debug("捕捉到cache改变");
        }, "t2").start();
    }
}
15:03:00.024 c.VolatileDemo [t1] - cache=1
15:03:00.024 c.VolatileDemo [t2] - 捕捉到cache改变

据此猜测sleep后回重刷内存
后来查阅了一些资料得出的结论是

sleep前不一定会将工作内存更新到主内存,sleep后也不一定会重新load,只有volatile才是最可靠的

参考

https://ask.youkuaiyun.com/questions/772201
官方文档
在这里插入图片描述

### Java 字节码中的内存屏障及其作用 在 Java 的并发编程中,内存屏障(Memory Barrier 或 Memory Fence)是一种用于控制指令执行顺序以及数据可见性的机制。它通过强制某些操作按照指定的顺序完成,防止编译器和处理器级别的重排序行为,从而保障多线程环境下程序的一致性和正确性。 #### 1. 内存屏障的作用 内存屏障的主要功能在于阻止特定类型的指令被重新排列,以确保程序的行为符合预期。具体来说,在字节码生成的过程中,JVM 和 JIT 编译器会根据需要插入相应的内存屏障来满足 Java 内存模型 (JMM) 中定义的规则[^1]。这些规则主要包括: - **禁止写-读重排序**:当一个变量被标记为 `volatile` 时,JVM 会在该变量的每次写入之后插入一个 StoreStore 屏障,并在其后的读取之前插入 LoadLoad 屏障。这种设计可以有效避免其他线程看到未更新的数据版本[^2]。 - **保证可见性**:对于普通的共享变量而言,如果没有额外措施,则其最新可能仅存储于当前线程的工作缓存之中而无法及时传播给其它线程;然而借助恰当位置设置好的 fences 可促使修改立即反映至主存并通知所有观察者知晓变化情况[^3]。 #### 2. 处理器重排序的影响与限制规则 尽管现代 CPU 架构通常支持一定程度上的乱序执行技术以便提高性能表现,但在涉及跨多个独立运行单元间协作场景下却容易引发潜在问题——即所谓的“竞态条件”。因此有必要采取手段加以约束以免破坏逻辑连贯性。以下是几个关键点说明如何利用 memory barriers 来应对上述挑战: - **单一线程内的局部效应保持不变**: 即使存在各种形式变换(如寄存器分配调整),只要不影响最终结果呈现就不会违反规定[^4]. - **全局一致性维护**: 当两个或者更多相互依赖的操作跨越不同CPU核之间传递消息时候,必须遵循严格的先后次序关系以防止单侧提前感知到尚未正式确立的状态. 得注意的是,JDK 版本升级往往会伴随着底层实现细节方面的改进优化工作开展;比如针对字符串连接运算符(`+`)处理方式上,jdk1.8以后就不再单纯依靠显式的 StringBuilder 对象实例化调用来达成目的而是改由内部自动合成更高效表达式代替之[^5].不过这属于另一范畴话题暂不展开讨论. ```java // 示例代码展示 volatile 关键字配合内存屏障的效果 public class VolatileExample { private static volatile boolean flag = false; public static void main(String[] args) throws InterruptedException { Thread t1 = new Thread(() -> { System.out.println("Thread T1 started."); while (!flag); // spin-wait until flag is set to true by another thread. System.out.println("Flag detected as true!"); }); t1.start(); Thread.sleep(100); // Set the flag which should be visible across threads due to 'volatile'. flag = true; System.out.println("Main thread has set the flag to true."); } } ``` 此例子清晰展现了即使是在高频率循环等待条件下也能可靠检测到来自外部改变状态信号的现象背后原理正是依托了恰当地运用memory fence机制所致成果体现出来.
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值