一、定义:什么是线程安全性
当多个线程访问某个类时,不管运行时环境采用 何种调度方式 或者这些进程将如何交替执行,并且在主调代码中不需要任何额外的同步或协同,这个类都能表现出正确的行为,那么就称这个类就是线程安全的。
二、线程安全性的三个体现
原子性:提供互斥访问,同一时刻只能有一个线程对数据进行操作(Atomic 原子类操作、CAS算法、synchronized、Lock)
可见性:一个主内存的线程如果进行了修改,可以及时被其他线程观察到(synchronized、volatile)
有序性:如果两个线程不能从 happens-before原则 观察出来,那么就不能观察他们的有序性,虚拟机可以随意的对他们进行重排序,导致其观察观察结果杂乱无序(happens-before原则)
CAS中ABA问题的解决
CAS并非完美的,它会导致ABA问题,例如:当前内存的值一开始是A,被另外一个线程先改为B然后再改为A,那么当前线程访问的时候发现是A,则认为它没有被其他线程访问过。在某些场景下这样是存在错误风险的。比如在链表中。如何解决这个ABA问题呢,大多数情况下乐观锁的实现都会通过引入一个版本号标记这个对象,每次修改版本号都会变话,比如使用时间戳作为版本号,这样就可以很好的解决ABA问题。在JDK中提供了 AtomicStampedReference类来解决这个问题,这个类维护了一个int类型的标记stamp,每次更新数据的时候顺带更新一下stamp。
线程安全性:原子性
synchronized
synchronized是一种同步锁,通过锁实现原子操作。1、修饰代码块:大括号括起来的代码,作用于调用的对象 2、修饰方法:整个方法,作用于调用的对象 3、修饰静态方法:整个静态方法,作用于所有对象 4、修饰类:括号括起来的部分,作用于所有对象
原子性 — 对比
Atomic:竞争激烈时能维持常态,比Lock性能好, 只能同步一个值
synchronized:不可中断锁,适合竞争不激烈,可读性好的情况
Lock:可中断锁,多样化同步,竞争激烈时能维持常态
线程安全性:可见性
简介:一个线程对主内存的修改可以及时被其他线程观察到
导致共享变量在线程间不可见的原因:1.线程交叉执行 2.重新排序结合线程交叉执行 3.共享变量更新后的值没有在工作内存中与主内存间及时更新
可见性 — syncronized
JMM关于 syncronized的两条规定:
线程解锁前,必须把共享变量的最新值刷新到主内存中
线程加锁时,将清空工作内存中共享变量的值,从而使得使用共享变量时需要从主内存中重新读取最新的值(注意:加锁与解锁是同一把锁) 由于syncronized可以保证原子性及可见性,变量只要被syncronized修饰,就可以放心的使用
可见性 — volatile
通过加入 内存屏障和 禁止重排序优化来实现可见性。具体实现过程:
对 volatile变量写操作时,会在写操作后加入一条 store屏障指令,将本地内存中的共享变量值刷新到主内存
对 volatile变量读操作时,会在读操作前加入一条 load屏障指令,从主内存中读取共享变量
volatile 不能保证操作的原子性,也就是不能保证线程安全性, 如果需要使用 volatile 必须满足以下两个条件:
对变量的写操作不依赖与变量当前的值。
该变量没有包含在具有其他变量的不变的式子中。
所以 volatile修饰的变量适合作为状态标记量。
import lombok.extern.slf4j.Slf4j;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;
@Slf4j
public class VolatileExample {
// 请求总数
public static int clientTotal = 5000;
// 同时并发执行的线程数
public static int threadTotal = 200;
public static volatile int count = 0;
public static void main(String[] args) throws Exception {
ExecutorService executorService = Executors.newCachedThreadPool();
final Semaphore semaphore = new Semaphore(threadTotal);
final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
for (int i = 0; i < clientTotal ; i++) {
executorService.execute(() -> {
try {
semaphore.acquire();
add();
semaphore.release();
} catch (Exception e) {
log.error("exception", e);
}
countDownLatch.countDown();
});
}
countDownLatch.await();
executorService.shutdown();
log.info("count:{}", count);
}
private static void add() {
count++;
}
}
结果返回
16:12:01.404 [main] INFO com.mmall.concurrency.example.count.VolatileExample4 - count:4986
通过执行代码我们可以发现,返回结果并不是我们想看到的5000,说明这个是线程不安全的类
主要是因为当我们执行 conut++时分成了三步:
- 取出当前内存count值,这时count值时最新的
- +1操作
- 重新写回主存
例如:有两个线程同时在执行 count++,两个内存都执行了第一步,比如当前count值为99,它们都读到了这个count值,然后两个线程分别执行了 +1,并写回主存,这样就丢掉了一次 +1的操作。
线程安全性:有序性
在JMM中,允许编译器和处理器对指令进行重排序,但是重排序过程不会影响到单线程程序的执行,却会影响到多线程并发执行的正确性。
通过volatile、synchronized、lock保证有序性
线程安全有序性需要遵循两个原则
- as-if-serial语义规则
- happens-before原则
happens-before原则
- 程序次序规则:一个线程内,按照代码顺序,书写在前面的操作先行发生于书写在后面的操作
- 锁定规则:一个 unLock操作先行发生于后面对同一个锁的 Lock()操作,也就是说只有先解锁才能对下面的线程进行加锁
- volatile变量规则:对一个变量的写操作先行发生于后面对这个变量的读操作
- 传递规则:如果操作A先行发生与操作B,而操作B先行发生于操作C,则操作A先行发生于操作C
- 线程启动规则: Thread对象的 start()方法先行发生于此线程的每一个动作,一个线程只有执行了 start()方法后才能做其他的操作
- 线程终端规则:对线程 interrupt()方法的调用先行发生与被中断线程的代码检测到中断事件的发生(只有执行了 interrupt()方法才可以检测到中断事件的发生)
- 线程终结规则:线程中所有操作都先行发生于线程的终止检测,我们可以通过 Thread.join()方法结束, Thread.isAlive()的返回值手段检测到线程已经终止执行
- 对象终结规则:一个对象的初始化完成先行发生于他的 finalize()方法的开始
as-if-serial语义规则
不管怎么重排序(编译器和处理器为了提供并行度),(单线程)程序的执行结果不能被改变。编译器,runtime和处理器都必须遵守as-if-serial语义。as-if-serial语义把单线程程序保护了起来,遵守as-if-serial语义的编译器,runtime和处理器共同为编写单线程程序的程序员创建了一个幻觉:单线程程序是按程序的顺序来执行的。比如上面计算圆面积的代码,在单线程中,会让人感觉代码是一行一行顺序执行上,实际上A,B两行不存在数据依赖性可能会进行重排序,即A,B不是顺序执行的。as-if-serial语义使程序员不必担心单线程中重排序的问题干扰他们,也无需担心内存可见性问题。
线程安全性:总结
- 原子性:Atomic包、CAS算法、synchronized、Lock
- 可见性:synchronized、volatile
一个主内存的线程如果进行了修改,可以及时被其他线程观察到,介绍了volatile如何被观察到的 - 有序性:happens-before原则 happens-before原则,观察结果,如果两个线程不能偶从happens-before原则观察出来,那么就不能观察他们的有序性,虚拟机可以随意的对他们进行重排序