平武建站

java可见性、原子性、有序性在并发场景下的原理

这篇文章主要讲解了“java可见性、原子性、有序性在并发场景下的原理”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“java可见性、原子性、有序性在并发场景下的原理”吧！

成都创新互联公司坚持“要么做到，要么别承诺”的工作理念，服务领域包括：网站制作、网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的金坛网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

源头一：缓存导致的可见性问题

在单核时代，所有的线程都是在一颗 CPU 上执行，CPU 缓存与内存的数据一致性容易解 决。因为所有线程都是操作同一个 CPU 的缓存，一个线程对缓存的写，对另外一个线程来 说一定是可见的。例如在下面的图中，线程 A 和线程 B 都是操作同一个 CPU 里面的缓 存，所以线程 A 更新了变量 V 的值，那么线程 B 之后再访问变量 V，得到的一定是 V 的 最新值（线程 A 写过的值）。
java可见性、原子性、有序性在并发场景下的原理
一个线程对共享变量的修改，另外一个线程能够立刻看到，我们称为可见性。

多核时代，每颗 CPU 都有自己的缓存，这时 CPU 缓存与内存的数据一致性就没那么容易 解决了，当多个线程在不同的 CPU 上执行时，这些线程操作的是不同的 CPU 缓存。比如 下图中，线程 A 操作的是 CPU-1 上的缓存，而线程 B 操作的是 CPU-2 上的缓存，很明 显，这个时候线程 A 对变量 V 的操作对于线程 B 而言就不具备可见性了。这个就属于硬 件程序员给软件程序员挖的“坑”。
java可见性、原子性、有序性在并发场景下的原理

下面我们再用一段代码来验证一下多核场景下的可见性问题。下面的代码，每执行一次 add10K() 方法，都会循环 10000 次 count+=1 操作。在 calc() 方法中我们创建了两个 线程，每个线程调用一次 add10K() 方法，我们来想一想执行 calc() 方法得到的结果应该 是多少呢？

    public class Test {
        private long count = 0;

        private void add10K() {
            int idx = 0;
            while (idx++ < 10000) {
                count += 1;
            }
        }

        public static long calc() {
            final Test test = new Test();
            // 创建两个线程，执行 add() 操作
            Thread th2 = new Thread(() -> {
                test.add10K();
            });
            Thread th3 = new Thread(() -> {
                test.add10K();
            });
            // 启动两个线程
            th2.start();
            th3.start();
            // 等待两个线程执行结束

            th2.join();
            th3.join();
            return count;
        }
    }

直觉告诉我们应该是 20000，因为在单线程里调用两次 add10K() 方法，count 的值就是 20000，但实际上 calc() 的执行结果是个 10000 到 20000 之间的随机数。为什么呢？ 我们假设线程 A 和线程 B 同时开始执行，那么第一次都会将 count=0 读到各自的 CPU 缓存里，执行完 count+=1 之后，各自 CPU 缓存里的值都是 1，同时写入内存后，我们 会发现内存中是 1，而不是我们期望的 2。之后由于各自的 CPU 缓存里都有了 count 的 值，两个线程都是基于 CPU 缓存里的 count 值来计算，所以导致最终 count 的值都是小 于 20000 的。这就是缓存的可见性问题。
循环 10000 次 count+=1 操作如果改为循环 1 亿次，你会发现效果更明显，最终 count 的值接近 1 亿，而不是 2 亿。如果循环 10000 次，count 的值接近 20000，原因是两个线程不是同时启动的，有一个时差。
java可见性、原子性、有序性在并发场景下的原理

源头二：线程切换带来的原子性问题

由于 IO 太慢，早期的操作系统就发明了多进程，即便在单核的 CPU 上我们也可以一边听 着歌，一边写 Bug，这个就是多进程的功劳。
操作系统允许某个进程执行一小段时间，例如 50 毫秒，过了 50 毫秒操作系统就会重新选择一个进程来执行（我们称为“任务切换”），这个 50 毫秒称为“时间片”。
java可见性、原子性、有序性在并发场景下的原理

Java 并发程序都是基于多线程的，自然也会涉及到任务切换，也许你想不到，任务切换竟 然也是并发编程里诡异 Bug 的源头之一。任务切换的时机大多数是在时间片结束的时候， 我们现在基本都使用高级语言编程，高级语言里一条语句往往需要多条 CPU 指令完成，例 如上面代码中的count += 1，至少需要三条 CPU 指令。

  • 指令 1：首先，需要把变量 count 从内存加载到 CPU 的寄存器；

  • 指令 2：之后，在寄存器中执行 +1 操作；

  • 指令 3：最后，将结果写入内存（缓存机制导致可能写入的是 CPU 缓存而不是内存）。

操作系统做任务切换，可以发生在任何一条CPU 指令执行完，是的，是 CPU 指令，而不 是高级语言里的一条语句。对于上面的三条指令来说，我们假设 count=0，如果线程 A 在指令 1 执行完后做线程切换，线程 A 和线程 B 按照下图的序列执行，那么我们会发现 两个线程都执行了 count+=1 的操作，但是得到的结果不是我们期望的 2，而是 1。
java可见性、原子性、有序性在并发场景下的原理
我们潜意识里面觉得 count+=1 这个操作是一个不可分割的整体，就像一个原子一样，线 程的切换可以发生在 count+=1 之前，也可以发生在 count+=1 之后，但就是不会发生 在中间。我们把一个或者多个操作在 CPU 执行的过程中不被中断的特性称为原子性。

源头之三：编译优化带来的有序性问题

有序性指的是程序按照代码的先后顺序执行。编译器为了优化性能，有时候会改 变程序中语句的先后顺序，例如程序中：“a=6；b=7；”编译器优化后可能变 成“b=7；a=6；”，在这个例子中，编译器调整了语句的顺序，但是不影响程序的最终 结果。不过有时候编译器及解释器的优化可能导致意想不到的 Bug。
在 Java 领域一个经典的案例就是利用双重检查创建单例对象（DCL单例模式），例如下面的代码：在获取实 例 getInstance() 的方法中，我们首先判断 instance 是否为空，如果为空，则锁定 Singleton.class 并再次检查 instance 是否为空，如果还为空则创建 Singleton 的一个实例。

    public class Singleton {
        static Singleton instance;

        static Singleton getInstance() {
            if (instance == null) {
                synchronized (Singleton.class) {
                    if (instance == null)
                        instance = new Singleton();
                }
            }
            return instance;
        }
    }

这看上去一切都很完美，无懈可击，但实际上这个 getInstance() 方法并不完美。问题出 在哪里呢？出在 new 操作上，我们以为的 new 操作应该是：

  1. 分配一块内存 M；

  2. 在内存 M 上初始化 Singleton 对象；

  3. 然后 M 的地址赋值给 instance 变量。

但是实际上优化后的执行路径却是这样的：

  1. 分配一块内存 M；

  2. 将 M 的地址赋值给 instance 变量；

  3. 最后在内存 M 上初始化 Singleton 对象。

那么优化后会导致什么问题呢？看下图，相信你一定会明白了！ java可见性、原子性、有序性在并发场景下的原理

感谢各位的阅读，以上就是“java可见性、原子性、有序性在并发场景下的原理”的内容了，经过本文的学习后，相信大家对java可见性、原子性、有序性在并发场景下的原理这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！


标题名称：java可见性、原子性、有序性在并发场景下的原理
本文路径：http://pwwzsj.com/article/ghesie.html

其他资讯