深入浅出 Java 并发编程 (2)

本文目录

  • Java 内存模型与可见性
  • 指令重排序
  • 使用 volatile 关键字保证可见性
  • 使用 synchronized 关键字保证可见性
  • synchronized 和 volatile 关键字的异同

Java 内存模型与可见性

上一篇文章主要介绍了 synchronized 关键字的使用，synchronized 关键字本质是互斥锁，保证了程序在不同线程之间执行的顺序以及同步。对于 Java 程序之中的变量，在不同的线程之中，还有一个关键的性质需要了解：可见性。

那么什么是可见性呢？

在理解可见性之前我们需要稍微了解一下 Java 的内存模型 (JMM)，所谓 Java 内存模型，实际上指的是 Java 用于管理内存的一种规范，它描述了Java程序中各种变量（线程共享变量）的访问规则，以及在 JVM 中将变量存储到内存和从内存中读取变量这样的底层细节。对于 Java 线程来说，Java 内存模型主要把内存分成了两类：

  • 主内存：主要对应于Java堆中的对象实例数据部分
  • 线程工作内存 (本地内存)：对应于虚拟机栈中的部分区域，是JMM的一个抽象概念，并不真实存在

在理解这两个内存的时候，我曾一直想把他们和之前提到过的 堆内存 和 栈内存 进行比较，但是实际上来说，主内存和工作内存与堆、栈内存并没有什么直接的联系。关于这几种内存联系的争论，可以参考这个知乎问答：

JVM中内存模型里的『主内存』是不是就是指『堆』，而『工作内存』是不是就是指『栈』？

言归正传，我们可以用一个简单的抽象示意图来理解 Java 内存模型:

Java 内存模型抽象示意图

从上面的图可以看到，假设有三个线程Thread1、Thread2 和 Thread3，它们在运行的过程中都会对变量 a 进行一定程度的操作，这些操作都是基于 JMM 给出的规定:

  • 所有的变量都存储在主内存中
  • 每个线程都有自己独立的工作内存，里面保存该线程使用到的变量的副本（主内存中该变量的一份拷贝）
  • 线程对共享变量的所有操作都必须在自己的工作内存中进行，不能直接从主内存中读写
  • 不同线程之间无法直接访问其他线程工作内存中的变量，线程间变量值的传递需要通过主内存来完成。

也就是说，线程想要对变量 a 进行操作，首先得从主内存之中获取一个 a 的副本，然后在自己的本地内存（工作内存）之中对 a 的副本进行修改。当修改操作完成以后，再将本地内存中的 “新版a” 更新到主内存之中。

说了这么多，这些东西和可见性有什么关系呢？我们先看下面的图：

线程之间通信

在图中，一开始Thread1和Thread2都从主内存中获取了共享变量a的一个副本：a1和a2，它们的初始值满足：a1 = a2 = a = 0，但是随着线程操作的进行，Thread2把a2的值改为了1，由于线程1和线程2之间的不可见性，所以造成了a1和a2值不一致，为了解决这个问题，线程2需要把自己修改过的a2先同步到主内存中（如图中红色箭头所示），然后再经由主内存刷新到Thread1中，这就是 Java 内存模型中线程同步变量的方法。

所以稍微总结一下，可见性指的是在不同的线程之中，一个线程对共享变量值的修改，能够及时地被其他线程看到。而线程1对共享变量的修改要想被线程2及时看到，必须要经过如下2个步骤：

  1. 把工作内存1中更新过的共享变量刷新到主内存中
  2. 将主内存中最新的共享变量的值更新到工作内存2中

指令重排序

在多线程环境里，除了 Java 线程本地工作内存造成的不可见性，指令重排序也会对线程间的语意和运行结果造成一定程度的影响。那么，什么是重排序？

以前有一句古话 “所见即所得” ，但是在计算机程序执行的时候却不是这个样子的，为了提高程序的性能，编译器或处理器会对程序执行的顺序进行优化，使得代码书写的顺序与实际执行的顺序未必相同。

指令重排序

而计算机程序重排序主要又可以分为以下几类：

  • 编译器优化的重排序（编译器优化）
  • 指令集并行重排序（处理器优化）
  • 内存系统的重排序（处理器优化）

虽然代码执行不一定按照其书写顺序执行，但是为了保证在单线程中代码最终输出结果不会因为指令重排序而改变，编译器、运行时环境和处理器都会遵循一定的规范，这里主要是指 as-if-serial语义 和 happens- before的程序顺序规则。

as-if-serial语义： 不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。

为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作可能被编译器和处理器重排序。为了具体说明，我们继续使用上面的例子：

int A = 1; // 1
int B = 2; // 2
int C = A + B; // 3

其中第一行和第二行执行的结果之间不存在数据的依赖性，因为第一行第二行的成功运行不需要对方的计算结果，但是第三行C的计算结果却是依赖于A和B的。这个依赖关系可以用下面的示意图表示：

依赖关系

所以根据依赖关系，as-if-serial语义将会允许上述程序的第一行和第二行进行重排序，而第三行的执行一定会放在前两行程序之后。as-if-serial 语义把单线程程序保护了起来，遵守as-if-serial语义的编译器、运行时环境和处理器共同为编写单线程程序的程序员们创建了一个幻觉：单线程程序是按程序的顺序来执行的。as-if-serial 语义使单线程程序员无需担心重排序会干扰他们，也无需担心内存可见性问题。

然而在多线程情况下就不是这么简单的了，指令重排序有可能会导致交叉工作的线程在执行完相同的程序之后得到不同的结果。为此我们可以看一下下面的这个小程序：

public class Test {
    int count = 0;
    boolean running = false;

    public void write() {
        count = 1;                  // 1
        running = true;             // 2
    }

    public void read() {
        if (running) {                // 3
            int result =  count++;    // 4
        }
    }
}

这里我们定义了一个布尔值标记 running ，用来表示变量 count 的值是否已经被写入。我们假设这里现在有两个线程（分别为Thread1和Thread2），Thread1 首先执行 write()，对变量 count 进行写入，然后Thread2 随即执行read()方法，那么，当Thread2运行到第四行的时候，是否能够看到Thread1对变量count进行的写入操作呢？

答案是不一定能够看得见。

我们对write()来分析，语句1和语句2实际上并没有数据依赖关系，根据as-if-serial 语义，这两行代码在实际运行的时候很可能会被重排序过。同样的，对read()方法来说，if(runnig)和int result = count++; 这两个语句也没有数据依赖关系，也会被重排序。那么对于线程Thread1和Thread2来说，语句1和语句2被重排序的时候，程序执行会出现如下的效果：

可能出现的一种执行顺序

在这种情况下，count++ 这句话在 Thread2 里面比在 Thread1中 count = 1 更早得到了执行，相比于重排序之前，这样得到的 count 最终的值为1，而不进行重排序的话结果是2，如此一来，重排序在多线程环境中破坏了原有的语意。同样，对于语句3和语句4，大家也可以对重排序是否会导致线程不安全做出类似的分析（先考虑数据依赖关系和控制流程依赖关系）。

使用 volatile 关键字保证可见性

为了解决 Java 内存模型之中多线程变量可见性的问题，在上一篇文章中，我们可以利用synchronized互斥锁的特性来保证多线程之间的变量可见性。

但是之前也有提到，synchronized关键字实际上是一种重量级的锁，为了在这种情况下优化它，我们可以使用volatile关键字。volatile关键字可以修饰变量，一个被其修饰的变量将会具有如下特性：

  • 保证了不同线程对这个变量进行操作时的可见性（一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的）

  • 禁止进行指令重排序

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量刷新到主内存。另外的，当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。这也是为什么volatile关键字能够保证不同线程对同一个变量的可见性。

关于volatile的底层实现，我不打算深究，但是可以简要的了解一下：如果把加入volatile关键字的代码和未加入volatile关键字的代码都生成汇编代码，会发现加入volatile关键字的代码会多出一个lock前缀指令。

那这个lock前缀指令是干嘛用的呢？

  • 重排序时不能把后面的指令重排序到内存屏障之前的位置
  • 使得本CPU的 cache 写入内存
  • 写入动作也会引起别的CPU或者别的内核无效化其cache，相当于让新写入的值对别的线程可见

说了那么多，volatile的使用其实很简单，让我们一起来看个demo：

public class VolatileUse {

    private volatile boolean running = true; // 对比一下有无 volatile 关键字的时候，运行结果的差别。

    void m() {
        System.out.println("m start...");
        while (running) {

        }
        System.out.println("m end...");
    }

    public static void main(String[] args) {
        VolatileUse t = new VolatileUse();
        new Thread(t::m, "t1").start();

        try {
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        t.running = false;
    }
}

在这个小程序中，如果对 running 加上了 volatile关键字，那么最后处于主线程的操作t.running = false; 将会被 线程t 所看到，从而打破死循环，使方法m()正常结束。如果不加关键字，那么程序将一直卡在m()方法的死循环中，永远也不会输出m end...。

那么volatile关键字能不能取代synchronized呢？我们再来看一个demo：

import java.util.ArrayList;
import java.util.List;

/**
 * volatile 关键字，使一个变量在多个线程间可见。
 * volatile 只有可见性，synchronized 既保证了可见性，又保证了原子性，但是效率远不如 volatile。
 *
 * @author huangyz0918
 */
public class VolatileUse02 {

    volatile int count = 0;

    void m() {
        for (int i = 0; i < 10000; i++) {
            count++;
        }
    }

    public static void main(String[] args) {
        VolatileUse02 t = new VolatileUse02();
        List<Thread> threads = new ArrayList<>();

        for (int i = 0; i < 10; i++) {
            threads.add(new Thread(t::m, "thread-" + i));
        }

        threads.forEach((o) -> o.start());

        threads.forEach((o) -> {
            try {
                o.join();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        });

        System.out.println(t.count);
    }
}

尝试运行了一下：

94141

再运行一次：

97096

我们可以看到两次运行的结果不同，并且都没有达到理论上所需要达到的目标值：100000。这是为什么呢？(count++语句包含了读取count的值，自增，重新赋值操作)

可以这样理解：有两个线程 (线程A 和 线程B) 都对变量count进行自加操作，如果某一个时刻线程 A 读取了count的值为100，这时候被阻塞了，因为没有对变量进行修改，触发不了volatile的规则。

线程B 此时也读读count的值，主内存里count的值依旧为100，做自增，然后立刻就被写回主存了，为101。此时又轮到 线程A 执行，由于工作内存里保存的是100，所以继续做自增，再写回主存，101又被写了一遍。所以虽然两个线程执行了两次自增操作，结果却只加了一次。

有人说，volatile不是会使缓存行无效的吗？但是这里从线程A开始读取count的值一直到 线程B 也进行操作之前，并没有修改count的值，所以 当线程B 读取的时候，还是读的100。

又有人说，线程B将101写回主内存，不会把线程A的缓存设为无效吗？但是线程A的读取操作已经做过了啊，只有在做读取操作时，发现自己缓存行无效，才会去读主内存的值，所以这里线程A只能继续做自增了。

总的来说，volatile其实是无法完全替代synchronied关键字的，因为在某些复杂的业务逻辑里面，volatile并不能保证多线程之间的完全同步和操作的原子性。

使用 synchronized 关键字保证可见性

在看过《深入浅出 Java 并发编程 (1)》 之后，想必大家都对synchronized关键字同步锁的性质有所了解了，但是关于为什么synchronized关键字能够保证可见性还需要从synchronized实现的步骤和原理去理解。

在 Java 内存模型中，对synchronized关键字有两条规定：

  • 线程解锁前，必须把共享变量的最新值刷新到主内存中。

  • 线程加锁前，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新读取最新的值（注意：加锁和解锁需要是同一把锁）。

这两条规定保证了线程解锁前对共享变量的修改在下次加锁时对其他线程可见，从而实现了可见性，我们再来看一下synchronized加锁前后代码具体的实现步骤：

  1. 获得互斥锁
  2. 清空工作内存
  3. 从主内存拷贝变量的最新副本到工作内存
  4. 执行代码
  5. 将更改后的共享变量的值刷新到主内存
  6. 释放互斥锁

保证可见性的步骤显而易见。

synchronized 和 volatile 关键字的异同

最后我们再来聊一聊这两个关键字的异同，这在很多互联网公司面试的过程中都属于热门考点。

简要总结概括如下：

  • volatile 不需要加锁，比 synchronized 更轻量级，不会阻塞线程。
  • 从内存可见性角度，volatile读相当于加锁，volatile写相当于解锁。
  • synchronized 既能保证可见性，又能保证原子性，而volatile只能保证可见性，无法保证原子性。
  • volatile 只能修饰变量，synchronized 还可修饰方法。

关于所谓线程阻塞和死锁以及相关的问题和解决方法，我们将在以后的文章中具体介绍。

相关阅读：

本教程纯属原创，转载请声明
本文提供的链接若是失效请及时联系作者更新

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 206,013评论 6赞 481
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 88,205评论 2赞 382
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 152,370评论 0赞 342
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 55,168评论 1赞 278
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 64,153评论 5赞 371
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,954评论 1赞 283
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,271评论 3赞 399
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,916评论 0赞 259
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 43,382评论 1赞 300
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,877评论 2赞 323
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,989评论 1赞 333
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,624评论 4赞 322
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,209评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,199评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,418评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,401评论 2赞 352
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,700评论 2赞 345

推荐阅读更多精彩内容

  • ［每日一问］敢担当这么难吗？
    今天，因为单位没有发工资的事，离职员工大闹单位，在佩服他们为自己勇敢维权的同事，还想对整件事里各角色不承担责任而导...
    黄家小妞阅读 131评论 0赞 0
  • 你的教养，体现在吃饭方式上
    有教养不是吃饭不洒汤，是别人洒汤的时候别去看他。——契科夫 01 单位里，我认识的一个特别秀气的女孩子叫昕薇，每次...
    hello志敏阅读 622评论 1赞 3
  • 简单爱
    昨天晚上，我坐在床边，抱着女儿，在玩， 慧妹看到了，可能是感觉这个角度不错，拿起手机，咔咔咔，帮我和女儿照了几张相...
    旦旦日记阅读 327评论 1赞 1