第一章 并发编程基本概念

本文介绍了Java并发编程的三个关键概念:原⼦性、可⻅性和有序性。原⼦性确保操作不被打断,如Java的Atomic类操作。可⻅性保证线程间共享变量的修改能被其他线程立即看到,volatile关键字可保证可⻅性。有序性涉及到指令重排序,Java内存模型通过内存屏障防止特定类型的重排序。文章还探讨了内存模型、重排序和内存屏障的重要性,并强调了volatile在避免重排序中的作用。
摘要由CSDN通过智能技术生成

并发编程基本概念

一、原⼦性

⼀个操作或者多个操作,要么全部执⾏并且执⾏的过程不会被任何因素打断,要么就都不执⾏。

原⼦性是拒绝多线程操作的,不论是多核还是单核,具有原⼦性的量,同⼀时刻只能有⼀个线程来对它进⾏操作。 简⽽⾔之,在整个操作过程中不会被线程调度器中断的操作,都可认为是原⼦性。例如 a=1是原⼦性操作,但是 a++和a +=1就不是原⼦性操作。

Java中的原⼦性操作包括:

  • 基本类型的读取和赋值操作,且赋值必须是值赋给变量,变量之间的相互赋值不是原⼦性操作;
  • 所有引⽤reference的赋值操作;
  • java.concurrent.Atomic.* 包中所有类的⼀切操作。

二 、可⻅性

指当多个线程访问同⼀个变量时,⼀个线程修改了这个变量的值,其他线程能够⽴即看得到修改的值。

在多线程环境下,⼀个线程对共享变量的操作对其他线程是不可⻅的。Java提供了volatile来保证可⻅性,当⼀个变 量被volatile修饰后,表示着线程本地内存⽆效,当⼀个线程修改共享变量后他会⽴即被更新到主内存中,其他线 程读取共享变量时,会直接从主内存中读取。当然,synchronize和Lock都可以保证可⻅性。synchronized和Lock 能保证同⼀时刻只有⼀个线程获取锁然后执⾏同步代码,并且在释放锁之前会将对变量的修改刷新到主存当中。因 此可以保证可⻅性。

三、有序性

即程序执⾏的顺序按照代码的先后顺序执⾏。

Java内存模型中的有序性可以总结为:如果在本线程内观察,所有操作都是有序的;如果在⼀个线程中观察另⼀个 线程,所有操作都是⽆序的。前半句是指“线程内表现为串⾏语义”,后半句是指“指令重排序”现象和“⼯作内存主主 内存同步延迟”现象。 在Java内存模型中,为了效率是允许编译器和处理器对指令进⾏重排序,当然重排序不会影响单线程的运⾏结 果,但是对多线程会有影响。Java提供volatile来保证⼀定的有序性。最著名的例⼦就是单例模式⾥⾯的DCL(双重 检查锁)。另外,可以通过synchronized和Lock来保证有序性,synchronized和Lock保证每个时刻是有⼀个线程 执⾏同步代码,相当于是让线程顺序执⾏同步代码,⾃然就保证了有序性。

为了让⼤家更好理解可⻅性和有序性,这个就不得不了解“内存模型”、“重排序”和“内存屏障”,因为这三个概 念和他们关系⾮常密切。

内存模型

JMM决定⼀个线程对共享变量的写⼊何时对另⼀个线程可⻅,JMM定义了线程和主内存之间的抽象关系:共享变量 存储在主内存(Main Memory)中,每个线程都有⼀个私有的本地内存(Local Memory),本地内存保存了被该线 程使⽤到的主内存的副本拷⻉,线程对变量的所有操作都必须在⼯作内存中进⾏,⽽不能直接读写主内存中的变量。

对于普通的共享变量来讲,线程A将其修改为某个值发⽣在线程A的本地内存中,此时还未同步到主内存中去;⽽线 程B已经缓存了该变量的旧值,所以就导致了共享变量值的不⼀致。解决这种共享变量在多线程模型中的不可⻅性 问题,可以使⽤volatile、synchronized、final等,此时A、B的通信过程如下:

  • ⾸先,线程A把本地内存A中更新过的共享变量刷新到主内存中去;
  • 然后,线程B到主内存中去读取线程A之前已更新过的共享变量。

JMM通过控制主内存与每个线程的本地内存之间的交互,来为java程序员提供内存可⻅性保证,需要注意的 是,JMM是个抽象的内存模型,所以所谓的本地内存,主内存都是抽象概念,并不⼀定就真实的对应cpu缓 存和物理内存。

总结⼀句话,内存模型JMM控制多线程对共享变量的可⻅性!!!

重排序

重排序是指编译器和处理器为了优化程序性能⽽对指令序列进⾏排序的⼀种⼿段。

重排序需要遵守⼀定规则:

  • 重排序操作不会对存在数据依赖关系的操作进⾏重排序。⽐如:a=1;b=a; 这个指令序列,由于第⼆个操作依 赖于第⼀个操作,所以在编译时和处理器运⾏时这两个操作不会被重排序。
  • 重排序是为了优化性能,但是不管怎么重排序,单线程下程序的执⾏结果不能被改变。 ⽐如: a=1;b=2;c=a+b这三个操作,第⼀步(a=1)和第⼆步(b=2)由于不存在数据依赖关系, 所以可能会发⽣重排 序,但是c=a+b这个操作是不会被重排序的,因为需要保证最终的结果⼀定是c=a+b=3。

重排序在单线程下⼀定能保证结果的正确性,但是在多线程环境下,可能发⽣重排序,影响结果,请看下⾯的示例 代码:

class ReorderExample {
        int a = 0;
        boolean flag = false;
        public void writer() {
            a = 1; //1
            flag = true; //2
        }
        Public void reader() {
            if (flag) { //3
                int i = a * a; //4
                System.out.println(i);
            }
        }
    }

flag变量是个标记,⽤来标识变量a是否已被写⼊。这⾥假设有两个线程A和B,A⾸先执⾏writer()⽅法,随后B线程 接着执⾏reader()⽅法。线程B在执⾏操作4时,输出是多少呢?

答案是:可能是0,也可能是1。

由于操作1和操作2没有数据依赖关系,编译器和处理器可以对这两个操作重排序;同样,操作3和操作4没有数据依 赖关系,编译器和处理器也可以对这两个操作重排序。让我们先来看看,当操作1和操作2重排序时,可能会产⽣什 么效果?请看下⾯的程序执⾏时序图:

如上图所示,操作1和操作2做了重排序。程序执⾏时,线程A⾸先写标记变量flag,随后线程B读这个变量。由于条 件判断为真,线程B将读取变量a。此时,变量a还根本没有被线程A写⼊,在这⾥多线程程序的语义被重排序破坏 了!最后输出i的结果是0。

温馨提示:这⾥其实理解起来有点绕,⽐如线程A先执⾏了writer(),然后线程B执⾏reader(),对于线程A, 怎么会有这个重排序呢?其实这个重排序,是对线程B⽽⾔的,不是线程A哈!

有了线程B这第⼀视⻆,我们再理解⼀下,虽然线程A将writer()执⾏了,执⾏顺序是a=1,flag=true,但是对 于线程B来说,因为重排序,线程B是根据重排序后的结果去执⾏的,所以才会出现上述异常情况,这么给⼤ 家解释,是不是就清晰很多呢?

下⾯再让我们看看,当操作3和操作4重排序时会产⽣什么效果(借助这个重排序,可以顺便说明控制依赖性)。下 ⾯是操作3和操作4重排序后,程序的执⾏时序图:

在程序中,操作3和操作4存在控制依赖关系。当代码中存在控制依赖性时,会影响指令序列执⾏的并⾏度。为此, 编译器和处理器会采⽤猜测(Speculation)执⾏来克服控制相关性对并⾏度的影响。以处理器的猜测执⾏为例, 执⾏线程B的处理器可以提前读取并计算a*a,此时结果为0,然后把计算结果临时保存到⼀个名为重排序缓冲 (reorder buffer ROB)的硬件缓存中。当接下来操作3的条件判断为真时,就把该计算结果写⼊变量i中。

从图中我们可以看出,猜测执⾏实质上对操作3和4做了重排序。重排序在这⾥破坏了多线程程序的语义!因为 temp的值为0,所以最后输出i的结果是0。

那如何避免重排序对多线程的影响呢,答案是“内存屏障”!

内存屏障

为了保证内存可⻅性,可以通过volatile、final等修饰变量,java编译器在⽣成指令序列的适当位置会插⼊内存屏障 指令来禁⽌特定类型的处理器重排序。内存屏障主要有3个功能:

  • 它确保指令重排序时不会把其后⾯的指令排到内存屏障之前的位置,也不会把前⾯的指令排到内存屏障的后 ⾯;即在执⾏到内存屏障这句指令时,在它前⾯的操作已经全部完成;
  • 它会强制将对缓存的修改操作⽴即写⼊主存;
  • 如果是写操作,它会导致其他CPU中对应的缓存⾏⽆效。

假如我对上述示例的falg变量通过volatile修饰:

 class ReorderExample {
        int a = 0;
        boolean volatile flag = false;
        public void writer() {
            a = 1; //1
            flag = true; //2
        }
        public void reader(){
            if (flag) { //3
                int i = a * a; //4
                System.out.println(i);
            }
        }
    }

这个时候,volatile禁⽌指令重排序也有⼀些规则,因为篇幅原因,改规则将会在下⼀章讲解,根据happens before规则,这个过程建⽴的happens before 关系可以分为两类:

1. 根据程序次序规则,1 happens before 2; 3 happens before 4。

2. 根据volatile规则,2 happens before 3。

3. 根据happens before 的传递性规则,1 happens before 4。

happens before规则,其实就是重排序规则建⽴的代码前后依赖关系。 温馨提示:这⾥⼤家可能会有疑问,1、3的规则我理解,但是对于2,为什么“2 happens before 3”,还记得 前⾯讲的“内存模型”么?因为你对变量flag指定了volatile,所以当线程A执⾏完后,变量flag=true会直接刷到 内存中,然后B⻢上可⻅,所以说2⼀定是在3前⾯,不可能因为重排序,导致3在2前⾯执⾏。(然后还要提 示⼀下,这⾥执⾏时有个前提条件,就是线程A执⾏完,才能执⾏线程B⾥⾯的逻辑,因为线程A不执⾏完, flag⼀直是false,线程B根本就进不到主流程,所以你也可以直接理解为线程A执⾏完后,再执⾏线程B,才 有这么个先后关系。)

上述happens before关系的图形化表现形式如下:

在上图中,每⼀个箭头链接的两个节点,代表了⼀个happens before 关系。⿊⾊箭头表示程序顺序规则;橙⾊箭 头表示volatile规则;蓝⾊箭头表示组合这些规则后提供的happens before保证。

这⾥A线程写⼀个volatile变量后,B线程读同⼀个volatile变量。A线程在写volatile变量之前所有可⻅的共享变量, 在B线程读同⼀个volatile变量后,将⽴即变得对B线程可⻅。

总结

今天讲解了Java并发编程的3个特性,然后基于⾥⾯的两个特性“可⻅性”和“有序性”引出⼏个重要的概念,分别为“内 存模型JMM”、“重排序”和“内存屏障”,这个对后续理解volatile、synchronized、final,以及避免使⽤的各种坑, 真的是⾮常⾮常重要!!!所以这块知识要必须!⼀定!!要!!!掌握。

不算之前看的内容,光写这篇⽂章就写了⼀个下午。这篇⽂章涉及的知识,参考了⼤量⽹上的资料,我可以说,我 这篇⽂章写的⽐⽹上绝⼤部分的⽂章要好,我看了程晓明的《深⼊理解Java内存模型》,⾥⾯的内容虽然很好,但 是很多知识有些啰嗦,我只提取了最重要的部分,然后也有⽹上的⽂章,写的很经典,但是对于⼀些概念和示例的 阐述,深度还不够,我结合他们的利弊,然后整理了这篇⽂章,详细⼤家看完这篇⽂章后,再看其它的⽂章,应该 就感觉好理解很多。

后记

这篇⽂章是我对Java并发编程的⼊⻔⽂章,后⾯会继续分别写volatile、synchronized、final,相关内容已经看 完,后续直接整理输出即可。其实我也不知道这些基础知识学到哪个程度才算OK,那就边写边学,等基础知识写 的差不多了,就开始写实战部分。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

菜鸟码神

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值