Java 杂谈SpringFramework

Java线程安全性知识总结-0

2019-02-12  本文已影响113人  cmazxiaoma

线程安全性:
当多个线程访问某个类时,不管运行时环境采用何种调度方式或者这些进程将如何交替执行,并且在主调代码中不需要任何额外的同步或者协同,这个类都能表现出正确的行为,那么就称这个类是线程安全的。

线程安全性表现在3个方面:

1.原子性:提供了互斥访问,同一时刻只能有一个线程来对它进行操作。

Java中最常见就是AtomicXXX:CAS、Unsafe.compareAndSwapInt。

image.png

对于AtomicLong,JDK1.8有更多的解决方案,也就是LongAdder类。

CAS也是有适用场景的,比如资源竞争小,是非常适用的,不用进行内核态和用户态之间的线程上下文切换的,同时自旋概率也会大大减少,提升性能。但是资源竞争激烈时,比如大量线程对同一资源进行写和读操作,这样CAS就不适用了。因为在这种情况下自旋概率会大大增加,从而浪费CPU资源,降低性能。

对于long和double变量,JVM会将64位的读操作和写操作拆成2个32位的操作。LongAdder的实现思想:热点数据分离。把AtomicLong内部核心数据value分离成一个数组,每个线程访问时通过hash算法映射到其中一个数字进行计数。最终计数的结果就是数组的求和累加。热点数据value会被分离成多个Cell。每个Cell独立维护着内部的值。当前对象实际的值由所有Cell累计求和,这样热点得到了有效的分离,提高了并行度。相对于AtomicLong,LongAdder将单点的压力分离到各个节点上。在低并发压力下的时候,通过对base的直接更新,可以很好的保障和AtomicLong的性能保持一致。

LongAdder在统计的时候如果有并发更新,可能会导致统计的数据有误差。

CAS中最著名的ABA问题,可以通过版本号来解决。也就是AtomicStampedReference这个类,版本号对应着里面的stamp变量。


2.可见性:一个线程对主内存的修改可以及时的被其他线程观察到。导致共享变量在线程间不可见的原因:线程交叉执行、重排序结合线程交叉执行、共享变量更新后的值没有在工作内存与主存间及时更新。

在我之前的文章Java底层知识总结-0有提到过JMM中同步规则。

对于可见性,JVM提供了Volatile和Synchronized。

JMM关于synchronized的两条规定:

volatile是通过加入内存屏障和禁止指令重排序优化来实现的。

内存屏障也称之为内存栅栏或者栅栏指令,是一种屏障指令。它使CPU或者编译器对屏障指令之前和之后发出的内存操作执行一个排序约束。这通常意味着在屏障之前发布的操作被保证在屏障之后发布的操作之前执行。

Load Load屏障:Load1和Load2代表2条读取指令。在Load2要读取的数据被访问前要保证Load1要读取的数据已经被读取完毕。

StoreStore屏障:Store1和Store2代表2条写入指令。在Store2写入执行之前,要保证Store1的写入操作对其他处理器可见。

LoadStore屏障:在Store2被写入前,要保证Load1要读取的数据被读取完毕。

StoreLoad屏障:在Load2读取操作执行前,要保证Store1的写入对所有处理器可见。StoreLoad屏障的开销是4种屏障中最大的。

happens-before是JSR-133规范。内存屏障是CPU指令,可以简单认为前者是最终目的,后者是实现手段。

在一个变量被volatile修饰后,JVM会做2件事情:

volatile适用于以下情况:


3.有序性:一个线程观察其他线程中的指令执行顺序,由于指令重排序的存在,该观察结果一般杂乱无序。

Java内存模型中,允许编译器和处理器对指令进行重排序,但是重排序过程不会影响到单线程程序的执行,却会影响到多线程并发执行的正确性。

能够通过volatile、synchronized、Lock手段达到有序性。

JMM模型具备一些先天的有序性,不需要任何手段达到有序性。happen-before的先行发生原则如下:

如果2个操作的执行次序无法从happen-before的原则推导出来,就无法保证它们之间的有序性。JVM就可以随意的对它们进行指令重排序。

上一篇下一篇

猜你喜欢

热点阅读