Java并发编程实战
王宝令
资深架构师
立即订阅
14231 人已学习
课程目录
已完结 50 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 你为什么需要学习并发编程?
免费
学习攻略 (1讲)
学习攻略 | 如何才能学好并发编程?
第一部分:并发理论基础 (13讲)
01 | 可见性、原子性和有序性问题:并发编程Bug的源头
02 | Java内存模型:看Java如何解决可见性和有序性问题
03 | 互斥锁(上):解决原子性问题
04 | 互斥锁(下):如何用一把锁保护多个资源?
05 | 一不小心就死锁了,怎么办?
06 | 用“等待-通知”机制优化循环等待
07 | 安全性、活跃性以及性能问题
08 | 管程:并发编程的万能钥匙
09 | Java线程(上):Java线程的生命周期
10 | Java线程(中):创建多少线程才是合适的?
11 | Java线程(下):为什么局部变量是线程安全的?
12 | 如何用面向对象思想写好并发程序?
13 | 理论基础模块热点问题答疑
第二部分:并发工具类 (14讲)
14 | Lock和Condition(上):隐藏在并发包中的管程
15 | Lock和Condition(下):Dubbo如何用管程实现异步转同步?
16 | Semaphore:如何快速实现一个限流器?
17 | ReadWriteLock:如何快速实现一个完备的缓存?
18 | StampedLock:有没有比读写锁更快的锁?
19 | CountDownLatch和CyclicBarrier:如何让多线程步调一致?
20 | 并发容器:都有哪些“坑”需要我们填?
21 | 原子类:无锁工具类的典范
22 | Executor与线程池:如何创建正确的线程池?
23 | Future:如何用多线程实现最优的“烧水泡茶”程序?
24 | CompletableFuture:异步编程没那么难
25 | CompletionService:如何批量执行异步任务?
26 | Fork/Join:单机版的MapReduce
27 | 并发工具类模块热点问题答疑
第三部分:并发设计模式 (10讲)
28 | Immutability模式:如何利用不变性解决并发问题?
29 | Copy-on-Write模式:不是延时策略的COW
30 | 线程本地存储模式:没有共享,就没有伤害
31 | Guarded Suspension模式:等待唤醒机制的规范实现
32 | Balking模式:再谈线程安全的单例模式
33 | Thread-Per-Message模式:最简单实用的分工方法
34 | Worker Thread模式:如何避免重复创建线程?
35 | 两阶段终止模式:如何优雅地终止线程?
36 | 生产者-消费者模式:用流水线思想提高效率
37 | 设计模式模块热点问题答疑
第四部分:案例分析 (4讲)
38 | 案例分析(一):高性能限流器Guava RateLimiter
39 | 案例分析(二):高性能网络应用框架Netty
40 | 案例分析(三):高性能队列Disruptor
41 | 案例分析(四):高性能数据库连接池HiKariCP
第五部分:其他并发模型 (4讲)
42 | Actor模型:面向对象原生的并发模型
43 | 软件事务内存:借鉴数据库的并发经验
44 | 协程:更轻量级的线程
45 | CSP模型:Golang的主力队员
结束语 (1讲)
结束语 | 十年之后,初心依旧
用户故事 (2讲)
用户来信 | 真好,面试考到这些并发编程,我都答对了!
3 个用户来信 | 打开一个新的并发世界
Java并发编程实战
登录|注册

02 | Java内存模型:看Java如何解决可见性和有序性问题

王宝令 2019-03-02

上一期我们讲到在并发场景中,因可见性、原子性、有序性导致的问题常常会违背我们的直觉,从而成为并发编程的 Bug 之源。这三者在编程领域属于共性问题,所有的编程语言都会遇到,Java 在诞生之初就支持多线程,自然也有针对这三者的技术方案,而且在编程语言领域处于领先地位。理解 Java 解决并发问题的解决方案,对于理解其他语言的解决方案有触类旁通的效果。

那我们就先来聊聊如何解决其中的可见性和有序性导致的问题,这也就引出来了今天的主角——Java 内存模型

Java 内存模型这个概念,在职场的很多面试中都会考核到,是一个热门的考点,也是一个人并发水平的具体体现。原因是当并发程序出问题时,需要一行一行地检查代码,这个时候,只有掌握 Java 内存模型,才能慧眼如炬地发现问题。

什么是 Java 内存模型?

你已经知道,导致可见性的原因是缓存,导致有序性的原因是编译优化,那解决可见性、有序性最直接的办法就是禁用缓存和编译优化,但是这样问题虽然解决了,我们程序的性能可就堪忧了。

合理的方案应该是按需禁用缓存以及编译优化。那么,如何做到“按需禁用”呢?对于并发程序,何时禁用缓存以及编译优化只有程序员知道,那所谓“按需禁用”其实就是指按照程序员的要求来禁用。所以,为了解决可见性和有序性问题,只需要提供给程序员按需禁用缓存和编译优化的方法即可。

© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Java并发编程实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(175)

  • Handongyang
    老师,还差两个规则,分别是:
    线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生,可以通过Thread.interrupted()方法检测到是否有中断发生。
    对象终结规则:一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。

    所以,个人对于Java内存模型总结起来就是:
    1. 为什么定义Java内存模型?现代计算机体系大部是采用的对称多处理器的体系架构。每个处理器均有独立的寄存器组和缓存,多个处理器可同时执行同一进程中的不同线程,这里称为处理器的乱序执行。在Java中,不同的线程可能访问同一个共享或共享变量。如果任由编译器或处理器对这些访问进行优化的话,很有可能出现无法想象的问题,这里称为编译器的重排序。除了处理器的乱序执行、编译器的重排序,还有内存系统的重排序。因此Java语言规范引入了Java内存模型,通过定义多项规则对编译器和处理器进行限制,主要是针对可见性和有序性。
    2. 三个基本原则:原子性、可见性、有序性。
    3. Java内存模型涉及的几个关键词:锁、volatile字段、final修饰符与对象的安全发布。其中:第一是锁,锁操作是具备happens-before关系的,解锁操作happens-before之后对同一把锁的加锁操作。实际上,在解锁的时候,JVM需要强制刷新缓存,使得当前线程所修改的内存对其他线程可见。第二是volatile字段,volatile字段可以看成是一种不保证原子性的同步但保证可见性的特性,其性能往往是优于锁操作的。但是,频繁地访问 volatile字段也会出现因为不断地强制刷新缓存而影响程序的性能的问题。第三是final修饰符,final修饰的实例字段则是涉及到新建对象的发布问题。当一个对象包含final修饰的实例字段时,其他线程能够看到已经初始化的final实例字段,这是安全的。
    4. Happens-Before的7个规则:
    (1).程序次序规则:在一个线程内,按照程序代码顺序,书写在前面的操作先行发生于书写在后面的操作。准确地说,应该是控制流顺序而不是程序代码顺序,因为要考虑分支、循环等结构。
    (2).管程锁定规则:一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁,而"后面"是指时间上的先后顺序。
    (3).volatile变量规则:对一个volatile变量的写操作先行发生于后面对这个变量的读操作,这里的"后面"同样是指时间上的先后顺序。
    (4).线程启动规则:Thread对象的start()方法先行发生于此线程的每一个动作。
    (5).线程终止规则:线程中的所有操作都先行发生于对此线程的终止检测,我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值等手段检测到线程已经终止执行。
    (6).线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生,可以通过Thread.interrupted()方法检测到是否有中断发生。
    (7).对象终结规则:一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。
    5. Happens-Before的1个特性:传递性。
    6. Java内存模型底层怎么实现的?主要是通过内存屏障(memory barrier)禁止重排序的,即时编译器根据具体的底层体系架构,将这些内存屏障替换成具体的 CPU 指令。对于编译器而言,内存屏障将限制它所能做的重排序优化。而对于处理器而言,内存屏障将会导致缓存的刷新操作。比如,对于volatile,编译器将在volatile字段的读写操作前后各插入一些内存屏障。

    作者回复: 厉害厉害!!!

    2019-03-02
    6
    436
  • senekis

    我思考下认为有三种方式可以实现:
    1.声明共享变量abc,并使用volatile关键字修饰abc
    2.声明共享变量abc,在synchronized关键字对abc的赋值代码块加锁,由于Happen-before管程锁的规则,可以使得后续的线程可以看到abc的值。
    3.A线程启动后,使用A.JOIN()方法来完成运行,后续线程再启动,则一定可以看到abc==3

    如有错误,请给指出错误所在!谢谢大家!谢谢老师!

    听课后感觉对我帮助好大,以前零碎的知识被重新系统的整理。错误的理解也得到修正,感谢老师!

    作者回复: 这三种方式都正确,理解的不错!

    2019-03-02
    1
    85
  • Junzi
    参考1中write()方法代码:
    x=45; // 1
    v=true; // 2
    这两行会不会导致指令重排?

    因为volatile关键字应该只保证了变量v的可见性,happen-before第一条原则在单线程中,1与2重排并不影响结果,那应该有可能出现重排的情况,这样线程B读取到read()的时候也有可能出现x=0。还请老师解答。
    2019-03-04
    9
    58
  • 狂战俄洛伊
    回复tracer的问题@tracer,你说的这个问题其实就是一个happens-before原则。例如有以下代码:
         int a = 1;//代码1
         int b = 2;//代码2
         volatile int c = 3;//代码3
         int d = 4;//代码4
         int e = 5;//代码5
    编译器解释这5行代码的时候,会保证代码1和代码2会在代码3之前执行,而代码1和代码2的执行顺序则不一定(这就是重排序,在不影响执行结果的情况下,虚拟机可能会对命令重排。当然所谓的不影响执行结果,java只保证在单线程中不影响执行结果)。代码4和代码5也一定会在代码3之后执行,同理代码4和代码5的执行顺序也是不一定的。
        所以这篇文章中你说的那段代码,由于v是volatile修饰的,对v的赋值永远在对x的赋值之后。所以在reader中输出的x一定是42

    作者回复: 感谢回复!

    2019-03-02
    1
    45
  • 小和尚笨南北
    补充一个: 在abc赋值后对一个volatile变量A进行赋值操作,然后在其他线程读取abc之前读取A的值,通过volatile的可见性和happen-before的传递性实现abc修改后对其他线程立即可见

    作者回复: 这个我称为炫技!

    2019-03-02
    2
    31
  • Jerry银银
    思考题的通用性表述为:如何保证一个共享变量的可见性?
    有以下方法:
    1. 保证共享变量的可见性,使用volatile关键字修饰即可
    2. 保证共享变量是private,访问变量使用set/get方法,使用synchronized对方法加锁,此种方法不仅保证了可见性,也保证了线程安全
    3. 使用原子变量,例如:AtomicInteger等
    4. 最后一种不是办法的办法:保证多个线程是「串行执行」^_^

    作者回复: 很全面了!

    2019-03-02
    5
    27
  • 发条橙子 。
    感悟 :
    老师用第一篇介绍了造成并发问题的由来引出了此文如果解决其中的 可见性、排序性问题 。 有了第一篇做铺垫让此篇看起来更加的流畅 。

    尤其以前看书中讲解 happens-before原则只是单单把六个规则点列了出来,很难吃透。此篇文章给出详细的事例逐点分析,使得更好的去理解每个点。

    例如 我之前看到的文章都说 在单线程中不会出现有序性问题 ,在多线程中会出现有序性问题。 之前很难理解单线程中没有有序性的问题是什么原因, 原来是happens-before第一条规则限制住了编译器的优化

    问题:
    第一个例子中添加了 volatile 关键字, 如果例子中 , v变量没有使用volatile ,那么x会是什么呢 ??
    答案: 42

    我的思考是, 没有了volatile那么规则二就不满足 , 但是规则一和规则三还是满足 ,虽然 writer()方法修改 v不能让其他立即可见,但是如果是循环调用reader()方法 ,等到可见到 v == true,根据第一条原则 , x happens-before v ,所以能读到 x=42

    老师请问我的判断正确么?


    思考题 :

    一个共享变量在一个线程中修改让另其他线程可见, 那就是解决可见性(缓存)的问题 , happens-before的规则就是用于对可见性进行约束的

    按照老师课中所讲 :
    思考如下:

      1. 第一条规则同线程中编译会保证顺序性 , 和问题不符合

     2. 第二条规则 , 使用volatile关键字 , 这个关键字可以让其他线程写之前先读最新的值,所以保证读到的是最新的值 ,可行

    3. 第三条规则 ,传递性, 和问题不符

    4. 第四条规则, 使用管程,由于是访问共享变量,如果是在syn中修改值只能保证当前线程下一次进入syn可以看见最新的值,其他线程直接访问还可能不是最新值 , 不行

    5. 第五条规则 , 如果前提是其他线程都在 主线程修改abc变量后 start(),则可见

    6. 第六条规则 ,如果前提是其他线程等 修改abc变量线程 join()执行,则可见

      7. Final关键字, 由于final关键字表示已经定义了常量,任意线程都不可以修改, 不可用

    综上总结 :

    使用2 添加volatile可行 。在符合某些场景下时,56可让其他线程可见


    作者回复: 你分析的比我还要好!

    2019-03-02
    3
    25
  • tracer
    我明白了,写先于读指的是不会因为cpu缓存,导致a线程已经写了,但是b线程没读到的情况。我错误理解成了b要读,一定要等a写完才行

    作者回复: 终于理解了!

    2019-03-02
    19
  • 老师,第一章里提到程序中x=5;x=6可能被重排。可是今天第一个规则里提到,同一个线程里,是顺序的。这两个不就矛盾了吗?

    作者回复: 可以重排,但是要保证符合Happens-Before规则,Happens-Before规则关注的是可见性,
    x=5;
    y=6;
    z=x+y;
    上面的代码重排成这样:
    y=6;
    x=5;
    z=x+y;
    也是可以的。

    所谓顺序,指的是你可以用顺序的方式推演程序的执行,但是程序的执行不一定是完全顺序的。编译器保证结果一定 == 顺序方式推演的结果

    这几条规则,都是告诉你,可以按照这个规则推演程序的执行。但是编译怎么优化,那就百花齐放了。

    2019-03-03
    12
  • WL
    想问一下老师最后关于逸出的例子,是因为有可能通过global.obj 可能访问到还没有初始化的this对象吗,但是将this赋值给global.obj不也是初始化时才赋值的吗,这部分不太理解,请老师指点一下

    作者回复: 有可能通过global.obj 可能访问到还没有初始化的this对象
    将this赋值给global.obj时,this还没有初始化完,this还没有初始化完,this还没有初始化完。

    2019-03-02
    1
    12
  • 小麦
    @发条橙子 ...
    有问题吧,我是这样理解的,第一条规则是串行语义,在单线程的场景下,优化后的结果会与顺序执行一致,但是不代表对x的写操作会比对v的写先执行,所以多线程下会出现问题。加volatile关键字后,volatile变量在写操作之后会插入一个store屏障(Store屏障,是x86的”sfence“指令,强制所有在store屏障指令之前的store指令,都在该store屏障指令执行之前被执行,并把store缓冲区的数据都刷到CPU缓存。这会使得程序状态对其它CPU可见,这样其它CPU可以根据需要介入。--并发编程网),所以禁止了重排序,这才保证了对x的写操作会比对v的写先执行,然后再根据volatile变量规则跟传递性原则,才保证了x=42对线程B可见。

    2019-03-04
    1
    11
  • 强哥
    关于java内存模型、jvm内存结构及java对象模型分别深入讲解一下,这样效果更好一些。

    作者回复: 咱们这个专栏还是专注于并发相关的部分,我怕有人说挂羊头卖狗肉

    2019-03-02
    11
  • Nevermore
    // 以下代码来源于【参考 1】
    class VolatileExample {
      int x = 0;
      volatile boolean v = false;
      public void writer() {
        x = 42;
        v = true;
      }
      public void reader() {
        if (v == true) {
          // 这里 x 会是多少呢?
        }
      }
    }


    感觉老师对这个volatile变量规则这块讲的有点草率,volatile变量的写对于读是可见的,对于程序来说,也就是线程A执行write中的v=true对于reader中的v==true是可见的 ,但是这对于x有什么关系?x并没有被volatile修饰。
    根据我的理解,volatile强制所修饰的变量及它前边的变量刷新至内存,并且volatile禁止了指令的重排序。
     
    望指正

    作者回复: 你的理解是对的,volatile的实现就是这样的。指导JVM这么实现的规范就是内存模型。这个专栏的侧重点是让大家学会写并发程序,至于底层是怎么实现的,有精力和兴趣的同学,可以自己来把握。

    2019-03-02
    1
    11
  • magict4
    老师你好,

    我对『3. 传递性』中您的解释,还是有点疑惑。感觉许多留言的小伙伴们也都有类似的疑惑,还请老师再耐心回答一次。

    您提到:
    > “x=42” Happens-Before 写变量 “v=true” ,这是规则 1 的内容;
    我的疑惑:变量 x 和 v 没有任何依赖关系,为什么对 x 的赋值 Happens-Before 对 v 的赋值呢?

    这个 Happens-Before 关系,根据我的理解,不是由规则 1 决定的,而是有 volatile 决定的。如果 v 没有被 volatile 修饰,编译器是可以对 x、v 的赋值语句进行重排的。 不知道我的理解是否有问题?

    作者回复: “x=42” Happens-Before 写变量 “v=true”
    是因为程序顺序就是这么写的:x=42;v=true

    这个案例是综合了 程序的顺序规则+传递规则+volatile 规则

    这三这个规则组合在一起就是你所谓的:“而是有 volatile 决定的”。编译器优化要遵循所有的HB规则。所有,不是一条。所以只有把他们组合在一起才有意义。

    2019-03-04
    9
  • 我觉得课后题其实就是利用happenbefore规则去构建abc的写入happenfore于另外一个线程的读取。而6条规则中传递性规则是纽带,然后采用比如规则4,就是把abc的赋值加入一同步块,并先执行,同时另外一个线程申请同一把锁即可。其他的也类似。

    java内存模型对程序员来说提供了按需禁止缓存禁止指令重排的方法。这是我第一次看到这么简单又深刻的解释,老师棒棒哒!!!

    作者回复: 多谢鼓励啊!

    2019-03-02
    7
  • 鸠翱
    对于@Junzi的问题:
    x=45; // 1
    v=true; // 2
    这两行会不会导致指令重排? 答:不会
    如果这两行重排序了,那么线程B读取到read()的时候也有可能出现x=0,也就是说线程B看到了v=true却没又看到x=45,这不符合第一条规则(请问老师 这么理解对不对)
    我课外查询了一下,从实现方法上,volatile的读写前后会插入内存屏障,保证一些操作是无法没重排序的,其中就有对于volatile的写操作之前的动作不会被重排序到之后

    作者回复: 是这样。

    2019-03-04
    3
    6
  • 王位庆
    @Junzi,您提的问题刚开始我也很疑惑,但查看了java并发编程的艺术,书上写了jdk1.5之后,增强了volatile的内存含义,限制了编译器和处理器对volatile变量和普通变量的重排序。p47页
    2019-04-03
    5
  • wang
    老师。对呀 发条橙子 提到如果不加 volatile,当读到v的时候,x就一定能读到42,使用的是使用的是规则1。
    我认为不对呀,规则一不是只适用于单线程吗?而读取v是在另一个线程,所以不能使用规则一判断吧。
    希望老师可以解释一下,谢谢

    作者回复: 不加volatile,多线程会有问题

    2019-03-02
    5
  • 飞翔的花狸猫
    Happen-before 这个知识点终于理解了,追并发专栏比以前看小说还勤快,盼老师速更啊

    作者回复: 那小说得写的有多烂!

    2019-03-02
    4
  • null
    @发条橙子… 的思考题分析,有些不太准确吧,例如评论里指出的程序顺序性。还有 synchronized 的分析也不太准确吧,synchronized(abc) 可能保证后续操作可见。

    老师是否应该在回复评论时指正,否则童鞋们看到“分析得比我好”的回复,很大可能就照着分析来理解了。

    作者回复: synchronized 的分析没有问题,其他线程直接访问还可能不是最新值,我理解直接就是没有使用任何同步手段。
    即便用 synchronized,用法不对,也达不到效果。
    语言本来就不准确,留言的同学,写的都很随意,实在不太适合以批判的眼光来看待。

    2019-04-10
    3
收起评论
99+
返回
顶部