synchronized的优化

我们知道synchronized同一时刻只能有一个线程获得对象的monitor监听器，这有时候就会导致我们的效率大大降低，所以引出了锁的优化，锁的优化也就是锁的几种状态，在这之前有两个概念需要知道:CAS操作和java对象头。

CAS操作

什么是CAS操作？

我们平时所说的获取锁其实是一种悲观锁的操作，假设在访问临界区代码的时候都会有冲突，这就意味着只有一个线程获取到锁，而别的线程都会被阻塞。而CAS操作是一种乐观锁，它假设不会有 冲突，那么自然就不会有阻塞的线程，那么一旦有了冲突有了冲突，又是怎么处理的呢?无锁操作是使用CAS(compare and swap)又叫做比较交换来鉴别线程是否出现冲突，出现冲突就重试当前操作直到没有冲突为止。

CAS的操作过程

CAS比较交换的过程可以通俗的理解为CAS(V,O,N)，包含三个值分别为：V 内存地址存放的实际值；O 预期的值（旧值）；N 更新的新值。当V和O相同时，也就是说旧值和内存中实际的值相同表明该值没有被其他线程更改过，即该旧值O就是目前来说最新的值了，自然而然可以将新值N赋值给V。反之，V和O不相同，表明该值已经被其他线程改过了则该旧值O不是最新版本的值了，所以不能将新值N赋给V，返回V即可。当多个线程使用CAS操作一个变量时，只有一个线程会成功，并成功更新，其余会失败。失败的线程会重新尝试，当然也可以选择挂起线程。

未优化前和synchronized和CAS的主要区别：

在存在线程竞争的情况下会出现线程阻塞和唤醒锁带来的性能问题，因为这是一种互斥同步（阻塞同步）。而CAS并不是武断的将线程挂起，当CAS操作失败后会进行一定的尝试，而非进行耗时的挂起唤醒的操作，因此也叫做非阻塞同步。

对象头

对象锁怎么理解？无非就是对对象有一个标识，而这个标识就存放在对象头里面，java对象头的Mark Word里面默认存放的是java对象的Hashcode，在32位JVM Mark Word默认存储结构为：

在jdk1.6中，锁一共有四种状态，按照级别依次是：无锁状态、偏向锁、轻量级锁、重量级锁，并且锁只能升级不能降级，也就是说，如果你把偏向锁升级为轻量级锁，那么便不能再降级为偏向锁，锁的这种只能升级不能降级的策略大大提高了对象获取锁和释放锁的效率

对象头的Mark Word改为：

偏向锁

偏向锁是锁的四种状态中最乐观的一种锁，从始至终只有一个线程请求某一把锁.
举个例子：

就比如说你在私家庄园里装了个红绿灯，并且庄园里只有你在开车。偏向锁的做法便是在红绿灯处识别来车的车牌号。如果匹配到你的车牌号，那么直接亮绿灯。

偏向锁的获取

当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：如果没有设置，则使用CAS竞争锁；如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

偏向锁的撤销

偏向锁使用了一种等到竞争出现才会释放锁的机制，当多个线程同时竞争时，持有偏向锁的线程才会释放锁。

如图：

下图线程1展示了偏向锁获取的过程，线程2展示了偏向锁撤销的过程：

关闭偏向锁

偏向锁在JDK6之后是默认启用的，但是它在应用程序启动几秒钟之后才激活，如有必要可以使用JVM参数来关闭延迟：-XX:BiasedLockingStartupDelay=0。如果你确定应用程序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁：-XX:-UseBiasedLocking=false，那么程序默认会进入轻量级锁状态。

轻量级锁

多个线程在不同的时间段请求同一把锁，也就是说没有锁竞争。针对这种情况，JVM采用了
轻量级锁，来避免线程的阻塞以及唤醒

加锁

线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。

解锁

轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。下图是两个线程同时争夺锁，导致锁膨胀的流程图。

因为自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

重量级锁

重量级锁是JVM中最为基础的锁实现。在这种状态下，JVM虚拟机会阻塞加锁失败的线程，并且在目标锁被释放的时候，唤醒这些线程。Java线程的阻塞以及唤醒，都是依靠操作系统来完成的。举例来说，对于符合posix接口的操作系统(如macOS和绝大部分的Linux)，上述操作通过pthread的互斥锁(mutex)来实现的。此外，这些操作将涉及系统调用，需要从操作系统的用户态切换至内核态，其开销非常之大。为了尽量避免昂贵的线程阻塞、唤醒操作，JVM会在线程进入阻塞状态之前，以及被唤醒之后竞争不到锁的情况下，进入自旋状态，在处理器上空跑并且轮询锁是否被释放。如果此时锁恰好被释放了，那么当前线程便无须进入阻塞状态，而是直接获得这把锁。

总结

Java虚拟机中synchronized关键字的实现，按照代价由高到低可以分为重量级锁、轻量锁和偏向锁三种。

1. 重量级锁会阻塞、唤醒请求加锁的线程。它针对的是多个线程同时竞争同一把锁的情况。JVM采用了自适应自旋，来避免线程在面对非常小的synchronized代码块时，仍会被阻塞、唤醒的情况。
2. 轻量级锁采用CAS操作，将锁对象的标记字段替换为一个指针，指向当前线程栈上的一块空间，存储着锁对象原本的标记字段。它针对的是多个线程在不同时间段申请同一把锁的情况。
3. 偏向锁只会在第一次请求时采用CAS操作，在锁对象的标记字段中记录下当前线程的地址。在之后的运行过程中，持有该偏向锁的线程的加锁操作将直接返回。它针对的是锁仅会被同一线程持有的情况。