前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Java线程安全性知识总结-0

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

作者头像
用户2032165
发布2019-03-04 11:00:59
5580
发布2019-03-04 11:00:59
举报

线程安全性:

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

线程安全性表现在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变量写入操作之前加入StoreStore屏障(将工作内存中的共享变量刷新到主内存),在写入操作之后加入StoreLoad屏障。
  • 在volatile变量读操作之后加入LoadLoad屏障(从主内存读取共享变量),在读操作之后加入LoadStore屏障。

volatile适用于以下情况:

  • 运行结果并不依赖变量的当前值,或者能够确保只有单一的线程修改变量的值。
  • 变量不需要与其他的状态变量一起参与不变约束。

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

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

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

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

  • 程序次序规则:一个线程内,按照代码程序,书写在前面的操作先行发生于书写在后面的操作。
  • 锁定规则:一个unlock操作先行发生于后面对同一个锁的lock操作。
  • volatile变量原则:对一个变量的写操作先行发生于后面对这个变量的读操作。
  • 传递规则:如果操作A先行发生于操作B,而操作B又先发生于操作C,则可以得出操作A先行发生于操作C。
  • 线程启动规则:Thread对象的start()方法先行发生于此线程的每一个动作。
  • 线程中断原则:对线程interrupt()方法的调用先行于被中断线程的代码检测到中断事件的发生。
  • 线程终结规则:线程中所有的操作都先行发生于线程的终止检测,我们可以通过Thread.join()方法结束,Thread.isAlive()的返回值手段检测到线程已经终止执行。
  • 对象终结规则:一个对象的初始化完成先行发生于它的finalize()方法的开始。

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

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2019.02.12 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档