Java线程安全_jaav 线程安全-CSDN博客

本文链接：https://blog.csdn.net/u010390677/article/details/88083471

问题的起源

首先，Java并发的问题要从JMM（Java Memory Model）讲起，先上一张JMM的结构图：

在Java内存模型中，分为主内存和线程工作内存，线程使用共享数据时，都是先从主内存中拷贝到工作内存，使用完成之后再写入主内存，可以理解为线程之间通讯是通过共享内存的方式实现的。
在多线程环境下，不同线程对同一份数据操作，就可能会产生不同线程中数据状态不一致的情况，这就是线程安全问题的定义或者说原因。
要实现线程安全，需要保证数据操作的两个特性：

原子性：对数据的操作不会受其他线程打断，意味着一个线程操作数据过程中不会插入其他线程对数据的操作
可见性：当线程修改了数据的状态时，能够立即被其他线程知晓，即数据修改后会立即写入主内存，后续其他线程读取时就能得知数据的变化
以上两个特性结合起来，其实就相当于同一时刻只能有一个线程去进行数据操作并将结果写入主存，这样就保证了线程安全。
接下来结合Java中线程安全的实现来看。

Volatile:可见性的保证

volatile有两点特性，第一是保证变量对所有线程的可见性，对于普通变量，一个线程对其修改后并不保证会立即写入主存，只有当写入主存之后才会对其他线程可见，而volatile关键字能够保证线程修改完变量立即写回主存，而且每个线程在使用变量前都必须先从主存刷新数据，这样就保证了修改的可见性。
第二点时禁止指令的重排序，Java编译器会对无结果依赖的代码指令进行重排序，下面这段伪代码可以说明指令重排序导致的并发问题：

//线程A执行
void init(){
  list = new ArrayList<>();
  ...  
  init = true;
}

//线程B执行
void run(){
  if(init) //dosomething
}

init = true与其他代码无结果关联，所以可能被重排序到前面，导致线程B执行时认为初始化完成但是list并没有赋值，如果用volatile关键字就能避免这种指令重排序。
volatile虽然保证了可见性，但并没有保证操作的原子性，还是会出现A、B线程同时读取到共享数据，然后各自修改导致结果覆盖的问题，所以无法保证线程安全。
volatile实际适用场景主要可以结合CAS操作，提高并发的性能，就如同Java concurrent类库中的用法，因为volatile的性能是很轻量的，能够避免CAS操作因为数据的可见性问题而导致失败。

Synchronized

Synchronized主要是通过对象锁的方式来实现线程安全（这边的锁是指虚拟机实现的锁，和Java Lock类库不是一个概念），修饰静态方法获取的是Class对象的锁，修饰方法是获取当前对象this的锁，修饰括号内容是获取括号内对象的锁。
对象锁分为偏向锁、轻量级锁、重量级锁，锁信息记录在对象头中（Mark Word，详情参考表中结构），对应锁标志位为轻量级锁：00，重量级锁：10，GC标志：11，偏向锁：01。

线程获取对象锁都是通过CAS操作修改对象头中的指向所记录的指针和锁状态，偏向锁、轻量级锁、重量级锁的分类主要在于加锁、解锁时的流程不同，性能开支不同罢了。

其实可以看到，对象锁的获取都是通过CAS修改对象头来实现的，那为什么还要分这么多种类呢？其实他们的加锁解锁过程还是有区别的，使用场景也不一样：

偏向锁

锁不会主动释放，只有当出现竞争时，才会去检查是否需要释放或者重新偏向锁，主要应用场景适用于基本只有一个线程访问同步代码块，可以无限重复获取偏向锁，大家可以看到其实在竞争偏向锁时需要在暂停当前持有锁的线程的（当然是要在安全点暂停），所以在高并发高竞争的情况下可以考虑关闭偏向锁。

轻量级锁&重量级锁

轻量级锁在竞争锁失败时，会通过自旋的方式尝试获取锁，而重量级锁竞争失败后会直接阻塞线程。所以，轻量级锁适用于那些同步代码块执行速度很快的场景，而重量级锁则对应同步代码块执行时间长的场景。

Concurrent

Java类库中有专门的concurrent包实现线程安全，核心类就是AQS（AbstractQueuedSynchronizer），一个抽象队列同步器，相当于一个模板，类库中ReentantLock等都是通过它来实现的。
AQS的核心原理：
维护一个volatile state作为锁标志计数，同时维护一个Node链表作为等待节点队列，锁的请求释放流程如下：