CAS概述

一、CAS与原子类

1.1 CAS

CAS（一种不断尝试）即Compare and Swap，它体现的一种乐观锁的思想，比如多个线程要对一个共享的整形变量执行+1操作：

CompareAndSwap：尝试把结果赋值给前面的共享变量，赋值的同时将旧值与共享变量当前的值作比较【怕写入结果时有其他线程已经将共享变量的值修改】

获取共享变量时，为了保证该变量的可见性，需要使用volatile修饰。结合CAS和volatile可以实现无锁并发，使用于竞争不激烈、多核CPU的场景下。

● 因为没有使用synchronized，所以线程不会陷入阻塞（CAS需要不断重试进而利用CPU时间），这是效率提升的因素之一
● 但如果因为竞争激烈，可以想到重连必然频繁发生，反而效率会受影响

CAS底层依赖于一个Unsafe类来直接调用操作系统底层的CAS指令，下面是直接使用Unsafe对象进行线程安全保护的例子

1.2 乐观锁与悲观锁

● CAS是基于乐观锁的思想：最乐观的估计，不怕别的线程来修改共享变量，就算修改了也没关系，花费点时间再重试而已

● synchronized是基于悲观锁的思想：最悲观的估计，时刻得防着其他线程来修改共享变量，只要线程上了锁就别想修改，完全解开了锁其他线程才有机会

1.3 原子操作类

juc（java.util.concurrent）Java并发工具包中提供了原子操作类，可以提供线程安全的操作，例如：AtomicInteger（原子整数类===>保护整数操作自增、自减的一些线程安全操作）、AtomicBoolean等，它们底层就是采用CAS技术+volatile来实现的。

import java.util.concurrent.atomic.AtomicInteger;
public  class Test {// 创建原子整数对象（给一个初始值0）private static AtomicInteger i=new AtomicInteger(0);public static void main(String[] args) throws InterruptedException {Thread t1=new Thread(()->{for (int j = 0; j < 5000 ; j++) {i.getAndIncrement();    // 获取并且自增  i++//              i.incrementAndGet();    // 自增并且获取  ++i}});Thread t2 = new Thread(()-> {for (int j = 0; j < 5000; j++) {i.getAndDecrement();    // 获取并且自减 i--}});t1.start();t2.start();// 让主线程等待,一直等待其他线程不再活动为止    //t1.join();t2.join();System.out.println(i);}
}

结果并不会出现整数、负数的情况（利用无锁并发的方式来保证原子整数类中整数信息的线程安全）

二、 synchronized优化

Java HotSPot虚拟机中，每个对象都有对象头（包括class指针和Mark Word）。Mark Word平时储存这个对象的哈希值、分代年龄，当加锁时，这些信息就根据情况被替换为标记位、线程锁记录指针、重量级锁指针、线程ID等内容

2.1 轻量级锁

如果一个对象虽然有多线程访问，但多线程访问的时间是错开的(也就是没有竞争)，那么可以使用轻量级锁来优化。这就好比:

学生(线程A)用课本占座（轻量级锁好比用课本占座，座位好比CPU的使用权），上了半节课，出门了(CPU时间到)，回来一看, 发现课本没变,说明没有竞争,继续上他的课。

如果这期间有其它学生(线程B) 来了，会告知(线程A)有并发访问，线程A随即升级为重量级锁,进入重量级锁的流程。【锁膨胀：轻量级锁升级为重量级锁】

而重量级锁就不是用课本占座那么简单了，可以想象线程A走之前,把座位用一个铁栅栏围起来

假设有两个方法同步块，利用同一个对象加锁

  static Object obj=new Object();public static void method1(){synchronized (obj){// 同步块 Amethod2();}}private static void method2() {synchronized (obj){// 同步块B }}

2.2 轻量级锁-无竞争

每个线程的栈帧中都会包含一个锁记录的结构，内部可以存储锁定对象的Mark Word(8个字节)

栈帧中锁记录的结构的作用：对一个对象加锁后，需将原来旧的信息暂存到栈帧的锁记录结构中，将来解锁时，再将暂存的Mark Word旧的信息恢复回去

对以上代码的加锁、解锁流程：

2.3 轻量级锁-锁膨胀

如果在尝试加轻量级锁的过程中，CAS操作无法成功，这是一种情况就是有其他线程为此对象加上了轻量级锁（有竞争），这时需要进行锁膨胀，将轻量级锁升级为重量级锁。

 static Object obj = new Object();public static void method1 () {synchronized (obj) {// 同步块}}

2.4 重量级锁-自旋

重量级锁竞争的时候，还可以使用自选来进行优化，如果当前线程自旋成功（即这个时候持锁线程已经退出了同步块，释放了锁），这时当前线程就可以避免阻塞。

在Java 6之后自旋锁是自适应的，比如对象刚刚的一次自旋操作成功过，那么认为这次自旋成功的可能性会高，就多自旋几次；反之，就少自旋甚至不自旋，总之，比较智能。

● 自旋会占用CPU时间，单核CPU自旋就是浪费（单核CPU无闲置CPU）毫无意义，多核CPU自旋才会发挥优势

● 好比等红灯时汽车是不是熄火，不熄火相当于自旋（等待时间短了划算），熄火相当于阻塞（等待时间长了不划算）

● Java 7之后不能再控制是否开启自旋功能

①: 自旋重试成功的情况【当线程2也想加锁(获取monitor)时，发现不能加锁时并不会马上陷入阻塞】

②: 自旋重试失败的情况【线程2不可能无限制的自旋重试，若线程1执行的时间较长，在重试过程中同步代码块还未执行完，重试多次后会放弃重试，然后自己陷入阻塞】

2.5 偏向锁

假设有两个方法同步块，利用同一个对象加锁

锁重入：线程1对对象加锁，由于其调用方法2，方法2还是本线程对同一对象加锁，但每次进行锁重入时还是会用CAS再做一次修改Mark Word为线程1的锁记录地址这样的操作

如何优化以上存在的问题？===>JDK 6中引入偏向锁的概念做进一步优化

轻量级锁在没有竞争时(就自己这个线程) , 每次重入仍然需要执行CAS操作。Java 6中引入了偏向锁来做进一步优化:只有第一次使用CAS将线程ID设置到对象的Mark Word头，之后发现这个线程ID是自己的就表示没有竞争，不用重新CAS.

■ 撤销偏向需要将持锁线程升级为轻量级锁,这个过程中所有线程需要暂停(STW)

■ 访问对象的hashCode也会撤销偏向锁（无锁状态下，对象头中存储的为对象的hashCode；加上偏向锁后，对象头中存的为线程ID，hashCode被放到加锁线程中）

■ 如果对象虽然被多个线程访问,但没有竞争,这时偏向了线程TI的对象仍有机会重新偏向T2, (FL)中J重置对象的Thread ID

■ 撤销偏向和重偏向都是批量进行的，以类为单位

■ 如果撤销偏向到达某个阈值，整个类的所有对象都会变为不可偏向的

■ 可以主动使用-XX:-UseBiasedL ocking禁用偏向锁

可以参考此篇论文: https://www.oracle .com technetwork/java biasedlocking -oopsla2006-wp- 149958.pdf

2.6 synchronized-其他优化

① 减少上锁时间 ：同步代码块中尽量短

② 减少锁的粒度 ：将一个锁拆分为多个锁提高并发度

例如：
■ ConcurrentHashMap

■ LongAdder（进行计数的原子操作类）分为base和cells 两部分。没有并发争用的时候或者是cells数组正在初始化的时候，会使用CAS来累加值到base,有并发争用，会初始化cells数组，数组有多少个cell,就允许有多少线程并行修改，最后将数组中每个cell累加，再加上base就是最终的值

■ LinkedBlockingQueue 入队和出队使用不同的锁，相对于I inkedBlockingArray只有一个锁效率要高

③ 锁粗化 ：
多次循环进入同步块不如同步块内多次循环
另外JVM可能会做如下优化，把多次append的加锁操作粗化为一次（因为都是对同一个对象加锁，没必要重入多次）

// StringBuffer类是线程安全的【里面的append()方法会有synchronized来进行同步保护】 new StringBuffer().append("a").append("b").append("c");   

④ 锁消除 ：当对象没有机会被外界用到时，就会将对象上的锁消除掉

JVM会进行代码的逃逸分析，例如某个加锁对象是方法内局部变量，不会被其他线程访问到，这时候就会被即时编译器忽略掉所有同步操作。

⑤ 读写分离 ：

CopyOnWriteArrayList：(读)读取原始数组的内容；
CopyOnWriteSet：(写)复制一份，在一个新数组上进行；
因此读操作不同同步，只需要对写操作进行同步即可

参考：
https://wiki.openjdk. java.net/display/HotSpot/Synchronization

http://luojinping.com/2015/07/09/javai)iít1c/

https://www.infoq.cn/article/java-se- 16-synchronized

https://www.jianshu.com/p/9932047a89be

https://www.cnblogs.com/sheeva/p/6366782.html

https://stackoverflow.com/questions/463 12817/does-java-ever-rebias-an-individual-lock