深入理解Java多线程(2.1)- 线程安全详解

2020年9月9日15:01:39 评论 41

导读

1、为什么有多线程?
2、线程安全描述的本质问题是什么?
3、Java内存模型(JMM)数据可见性问题、指令重排序、内存屏障
4、工作内存与主内存的数据交换的细节
5、指令重排序与内存屏障
6、volatile、final、锁的内存语义
7、as-if-serial、happens-before

1、为什么有多线程

谈到多线程,我们很容易与高性能画上等号,但是并非如此,举个简单的例子,从1加到100,用四个线程计算不一定比一个线程来得快。因为线程的创建和上下文切换,是一笔巨大的开销。
那么设计多线程的初衷是什么呢?来看一个这样的实际例子,计算机通常需要与人来交互,假设计算机只有一个线程,并且这个线程在等待用户的输入,那么在等待的过程中,CPU什么事情也做不了,只能等待,造成CPU的利用率很低。如果设计成多线程,在CPU在等待资源的过程中,可以切到其他的线程上去,提高CPU利用率。
现代处理器大多含有多个CPU核心,那么对于运算量大任务,可以用多线程的方式拆解成多个小任务并发的执行,提高计算的效率。
总结起来无非两点,提高CPU的利用率、提高计算效率。

2、线程安全的本质

我们先来看一个例子:

public class Add {
	private int count = 0;

	public static void main(String[] args) {
		CountDownLatch countDownLatch = new CountDownLatch(4);
		Add add = new Add();
		add.doAdd(countDownLatch);
		try {
			countDownLatch.await();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		System.out.println(add.getCount());

	}
	public void doAdd(CountDownLatch countDownLatch) {
		for (int i = 0; i < 4; i++) {
			new Thread(new Runnable() {
				public void run() {
					for (int j = 0; j < 25; j++) {
						count++;
					}
					countDownLatch.countDown();
				}
			}).start();
		}
	}

	public int getCount() {
		return count;
	}

}

上面是一个把变量自增100次的例子,只不过用了4个线程,每个线程自增25次,用CountDownLatch等4个线程执行完,打印出最终结果。实际上,我们希望程序的结果是100,但是打印出来的结果并非总是100。

这就引出了线程安全所描述的问题,我们先用通俗的话来描述一下线程安全:

线程安全就是要让程序运行出我们想要的结果,或者话句话说,让程序像我们看到的那样执行

解释一下我总结的这句话,我们先new出了一个add对象,调用了对象的doAdd方法,本来我们希望每个线程有序的自增25次,最终得到正确的结果。如果程序增的像我们预先设定的那样运行,那么这个对象就是线程安全的。

下面我们来看看Brian Goetz对线程安全的描述:当多线程访问一个对象时,如果不用考虑这些线程在运行时环境下的调度和交替,也不需要进行额外的同步,或者在调用方进行任何其他的协调操作,调用这个对象的行为都可以获得正确的结果,那么这个对象就是线程安全的

下面我们就来分析这段代码为什么不能确保总是得到正确的结果。

3、Java内存模型(JMM)数据可见性问题、指令重排序、内存屏障

先从计算机的硬件效率说起,CPU的计算速度比内存快几个数量级,为了平衡CPU和内存之间的矛盾,引入的高速缓存,每个CPU都有高速缓存,甚至是多级缓存L1、L2和L3,那么缓存与内存的交互需要缓存一致性协议,这里就不深入讲解。那么最终处理器、高速缓存、主内存的交互关系如下:

深入理解Java多线程(2.1)- 线程安全详解

那么Java的内存模型(Java Memory Model,简称JMM)也定义了线程、工作内存、主内存之间的关系,非常类似于硬件方面的定义。(更详细Java内存模型介绍:深入理解Java虚拟机(4.1)- Java内存模型(易懂好文)深入理解Java虚拟机(4.2)- Java内存模型(深入详解)

深入理解Java多线程(2.1)- 线程安全详解

这里顺带提一下,Java虚拟机运行时内存的区域划分。

方法区:存储类信息、常量、静态变量等,各线程共享

虚拟机栈:每个方法的执行都会创建栈帧,用于存储局部变量、操作数栈、动态链接等,虚拟机栈主要存储这些信息,线程私有

本地方法栈:虚拟机使用到的Native方法服务,例如c程序等,线程私有

程序计数器:记录程序运行到哪一行了,相当于当前线程字节码的行号计数器,线程私有

:new出的实例对象都存储在这个区域,是GC的主战场,线程共享。

(注:关于内存区域更详细介绍请查看:深入理解Java虚拟机(1)- Java内存区域

所以对于JMM定义的主内存,大部分时候可以对应堆内存、方法区等线程共享的区域,这里只是概念上对应,其实程序计数器、虚拟机栈等也有部分是放在主内存的,具体看虚拟机的设计。

好了,了解了JMM内存模型,我们来分析一下,上面的程序为什么没得到正确的结果。请看下图,线程A、B同时去读取主内存的count初始值存放在各自的工作内存里,同时执行了自增操作,写回主内存,最终得到了错误的结果。

深入理解Java多线程(2.1)- 线程安全详解

我们再来深入分析一下,造成这个错误的本质原因:

(1)、可见性,工作内存的最新值不知道什么时候会写回主内存

(2)、有序性,线程之间必须是有序的访问共享变量,我们用“视界”这个概念来描述一下这个过程,以B线程的视角看,当他看到A线程运算好之后,把值写回之内存之后,马上去读取最新的值来做运算。A线程也应该是看到B运算完之后,马上去读取,在做运算,这样就得到了正确的结果。

接下来,我们来具体分析一下,为什么要从可见性和有序性两个方面来限定。

给count加上volatile关键字,就保证了可见性。

private volatile int count = 0;

volatile关键字,会在最终编译出来的指令上加上lock前缀,lock前缀的指令做三件事情

(1)、防止指令重排序(这里对本问题的分析不重要,后面会详细来讲)

(2)、锁住总线或者使用锁定缓存来保证执行的原子性,早期的处理可能用锁定总线的方式,这样其他处理器没办法通过总线访问内存,开销比较大,现在的处理器都是用锁定缓存的方式,在配合缓存一致性来解决。

(3)、把缓冲区的所有数据都写回主内存,并保证其他处理器缓存的该变量失效

既然保证了可见性,加上了volatile关键词,为什么还是无法得到正确的结果,原因是count++,并非原子操作,count++等效于如下步骤:

(1)、 从主内存中读取count赋值给线程副本变量:

temp=count

(2)、线程副本变量加1

temp=temp+1

(3)、线程副本变量写回主内存

count=temp

就算是真的严苛的给总线加锁,导致同一时刻,只能有一个处理器访问到count变量,但是在执行第(2)步操作时,其他cpu已经可以访问count变量,此时最新运算结果还没刷回主内存,造成了错误的结果,所以必须保证顺序性。

那么保证顺序性的本质,就是保证同一时刻只有一个CPU可以执行临界区代码。这时候做法通常是加锁,锁本质是分两种:悲观锁和乐观锁。如典型的悲观锁synchronized、JUC包下面典型的乐观锁ReentrantLock。

总结一下:要保证线程安全,必须保证两点:共享变量的可见性、临界区代码访问的顺序性。

 4、主内存与工作内存交互协议

JMM定义了8种基本操作来完成,主内存、工作内存和执行引擎之间的交互,分别是lock、unlock、read、load、use、assign、store、write,虚拟机的实现向程序员保证每一种操作都是原子的,不可分割,对于double和long类型的64为变量不做保证。了解了这些,有助于帮我们理解内存屏障。

别看有8个操作,实际上是成对定义的连贯操作。我们具体来看怎么记忆。
(1)、针对于主内存的单独操作lock和unlock
lock:作用于主内存、把变量标示为线程独占
unlock:作用于主内存、释放锁定状态

(2)、主内存到工作内存的读交换
read:作用于主内存,把主内存变量传递给工作内存
load:作用于工作内存,把read操作传过来的值放入工作内存

(3)、工作内存到主内存的写交换
store:作用于工作内存,把工作内存变量传递给主内存
write:作用于主内存,把store过来的值写入主内存变量

(4)、工作内存和执行引擎的数据交换
use:作用于工作内存,把工作内存变量传递给执行引擎
assign:作用于工作内存,把执行引擎的值赋给工作内存变量

上述的交互关系,可以用如下的图来表示:
深入理解Java多线程(2.1)- 线程安全详解
总体来说,工作内存和主内存的数据交换读写都是用两组操作来完成,而执行引擎和工作内存的数据交换由两个操作完成。当然,上述的8种操作必须满足一些规则,这里列举一些我认为重要的,例如:

(1)、read和load、store和write必须同时出现‘
(2)、对变量执行lock操作,会清空工作内存中缓存的该值,对变量执行unlock操作,必须先把值同步回主内存。

废了这么大的篇幅,讲我们Java程序员并不关心的数据交换细节,是为了帮助我们理解后面的内存屏障,系好安全带,我们继续来看一个完全错乱的Java微观世界。

    5、乱序的Java世界

在单线程的世界里,JMM向我们保证执行的正确性,那么我们可以逻辑的认为代码是根据我们编写的顺序执行。那么在多线程的世界里,站一个线程的视角看另一个线程,我们将完全看不清执行的顺序。并且也看不到对方执行结果。请看下面的代码:

public class ReorderTest {
	private int a = 0;
	private int b = 0;
	private int c = 2;

	public void write() {
		a = 1;
		b = 1;
	}

	public void read() {
		if (b == 1) {
			c = a;
		}
	}
}

假设有两个线程A、B分别要执行write和read方法,A先进去执行、B随后执行,先抛开a、b线程可见性问题,假设a、b对线程立即可见。最后c值是多少?可能是1,可能是2,甚至可能是0。接下来具体分析一下为什么。

站在B的视角看,它看不清a=1和b=1谁先执行,由于指令重排序,很可能b=1先执行,请看下表:   深入理解Java多线程(2.1)- 线程安全详解

站在B线程的视角,B线程中read方法里的代码是否会重排序呢,虽然这个方法的两句话存在依赖关系,JMM支持不改变结果的指令重排,JMM无法预先判断是否有其他线程在修改a的值,所以可能会重排,并且处理器会用猜测执行来重排。请看下表:

深入理解Java多线程(2.1)- 线程安全详解

指令重排序让线程看不清对方线程的执行顺序,也就是乱序的,那么会有哪些级别的指令重排序呢?有三种:编译器重排序、指令级重排序、内存级重排序。

3、内存屏障

指令重排序会导致多线程执行的无序,那么JMM会禁止特定类型的指令重排序,JMM通过内存屏障来禁止某些指令重排序,那么有哪些内存屏障呢?总共4类
LoadLoad:前面的load会先于后面的load装载
StoreStore:前面的store会先于后面的store执行,也就是保证内存可见性
LoadStore:前面的load先于后面的store执行
StoreLoad:前面的store先于后面的Load执行

接下来分别看volatile、final、锁,都有哪些内存语义,加了哪些内存屏障。

(1)、volatile
对volatile变量的写操作,前面插入StoreStore屏障,防止和上面的写发生重排序;后面插入StoreLoad屏障,防止和后面的读写发生重排序。

对volatile变量的读操作,后面会插入两个屏障,分别是LoadLoad、LoadStore,说白了就是,我是volatile变量,不管你下面的变量是读或者写,我都要先于你读。

(2)、final
final本质上定义是final域与构造对象的引用之间的内存屏障。

在构造函数对final变量的写人,与对构造函数对象引用的读,不能重排序,本质上是插入了storeStore屏障,保证对象引用被读之前,已经对final变量进行了写人。这里特别注意指针逃逸。

读含有final变量的对象的引用,与读final变量不能指令重排序,插入loadload屏障,保证先读到对象引用,在读final变量的值,也就是只要对象构造完成,并且在构造函数中将final值写入,另外一个线程肯定可以读到,这是JMM的保证。

(3)、锁
ReentrantLock中 有个private volatile int state,本质上是用的volatile的内存语义,这里就省略讲了。

4、as-if-serial、happens-before

前面说这么多,指令重排序重排序,弄乱了Java程序,JMM提供volatile、final、锁来禁止某些指令重排序,那么记住这些重排序规则并非简单的事,JMM用另外一种好记的理论来帮助程序员记忆。

 as-if-serial:用通俗的话来解释一下,单线中,程序逻辑的以我们看到的顺序执行,这里只是可以逻辑的认为顺序执行,其实也会有不影响结果的指令重排,例如:

int i=1;
int j=2;
int a=i*j;

这里i=1,j=1重排不影响结果,那么实际上JMM是允许的。  有了as-if-serial,在单线程中,程序员不用担心指令重排和内存可见性问题。

happens-before

happens-before保证如果A、B两个操作存在happens before关系,那么A操作的结果一定对B可见,有了可见性的保证,在加上正确的同步,就能写出线程安全的代码。JSR133定义了哪些天然的happens-before关系呢?请看下面:

(1)、一个线程内,每个操作happens-before后面的操作
(2)、unlock操作happens-before对这个这个锁的lock操作
(3)、volatile写操作happens-before读操作
(4)、线程的start方法happens-before此线程的所有其他操作
(5)、线程所有操作happens-before对此线程的终止监测,例如,A线程调用B线程的join方法,如果join返回,那么B线程的所有操作必定完成,且B线程的所有操作的数据必定对A线程可见。
(6)、传递性,A happens-before B、B happens-before C,那么A happens-before C

最后总结一下,前面3节围绕可见性和执行临界区代码的顺序性进行了说明,后面4节主要说的是可见性,就本质而言,加内存屏障,就是为了保证前面的操作对后面的操作可见,也就是我不能和你顺序弄乱了,我得看着你怎么执行,happens-before是JMM对Java程序员的承诺,记住这些规则,配合锁,必定线程安全。

最后还有两句话

在本线程内看,所有的操作都是有序的,这是as-if-serial的保证。

一个线程看另一个线程,所有的操作都是无序的,主要是两方面所致,一方面是指令重排序,另一方面是不知道工作内存的值什么时候同步到主内存。


2. Java多线程之线程同步

深入理解Java多线程(2.1)- 线程安全详解
深入理解Java多线程(2.2)- Java并发编程的3个特性(原子性,可见性,有序性)
深入理解Java多线程(2.3)- volatile详解和使用场景
深入理解Java多线程(2.4)- volatile底层实现原理
深入理解Java多线程(2.5)- synchronized用法和实现原理详解
深入理解Java多线程(2.6)- synchronized原理之锁优化
深入理解Java多线程(2.7)- 死锁的原因和如何避免死锁
深入理解Java多线程(2.8)- 彻底理解ThreadLocal的用法和原理

回到目录:深入理解Java多线程 - 教程系列详解
(转自:https://my.oschina.net/u/1778239/blog/1610185)

素课网
  • 本文由 发表于 2020年9月9日15:01:39
  • 转载请注明:https://www.suketech.com/9949.html
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: