扎心了，☹️

最好用的是 xshell

更有效地利用 CPU 资源

围观一下

最近想学经济学，😅

白色，黑色看久了费劲

@gejun123456 这个赞

可见性这个东西，我上面说的没有可见性问题，指的是硬件层面。我觉得 Java 里面的可见性指的是两个方面：

1. 软件层面，编译器重排。
2. 硬件层面上的多变量访问的顺序问题。

可能我们说的都没错，硬件上确实没有顺序问题，而由于 JIT 的优化确实产生了"不可见"的结果，一个概念的两个层面。

再补充几点。一个 CPU 在修改 cache line 之前首先要获得对其的排他控制权，即要向其它 CPU 发送使无效消息，而为了保证性能，每个 CPU 均有一个 Invalidate Queue 用于处理使无效消息，但是 CPU 不提供何时处理使无效消息的保证。Java 的 volatile 实现会在读时插入一个 smp_rmb()，但是 CPU 在遇到读屏障时不会马上刷新 Invalidate Queue，而是只保证顺序，这就是为什么我上面说 volatile 不会加速其它 CPU 看到修改。所以在单个变量的读写上，其实根本没必要使用 CPU 层面上的内存屏障，对付编译器的屏障足矣，这就是 Linux 内核 ACCESS_ONCE 宏的作用，然而 Java 却没得选。。。2333

进一步说，这是 jit 编译器的提升优化，楼主可以试下下面的代码:
public class Test {

private static boolean flag = true;

public static void main(String[] args) throws InterruptedException {

new Thread(new Runnable() {
@Override
public void run() {
while (flag);
System.out.println("退出");
}
}).start();

Thread.sleep(500);

flag = false;
}

}

在两种情况下可以退出，
1. flag 加 volatile
2. 加上 JVM 参数-Xint 关闭 JIT 编译。我觉着其实这里并没有什么可见性问题，这种单个变量的修改本身就应该是原子的，volatile 不可能加速其它 CPU 看到修改的过程，这里的 volatile 准确来说是对编译器的提示，告诉编译器这个变量是可能被修改的，不要随便搞事情。。。

个人觉得这是提升优化，不加 volatile，编译器会优化成在 while 循环外判断一次，内部则是死循环

@zzzhzyzy 我是在撕逼鱼收的二手，不能和新的比

我以前用的 i5-7200U，现在是 i7-4770hq，提升确实肉眼可见

码送完了，结贴了，😛

@gotounix 已发送

@springsummer emClient 给你发过去了哈

@x537196 给你发过去了哈

@x537196 [email protected] 么？

@gotounix 是 [email protected] 对吧