轻量级锁
重量级锁依赖于底层的操作系统的Mutex Lock来实现的，但是由于使用Mutex Lock需要将当前线程挂起并从用户态切换到内核态来执行，这种切换的代价是非常昂贵的，而在大部分时候可能并没有多线程竞争，只是多个线程交替执行，（例如：这段时间是线程A执行同步块，另外一段时间是线程B来执行同步块，仅仅是多线程交替执行，并不是同时执行，也没有竞争），如果采用重量级锁效率比较低。以及在重量级锁中，没有获得锁的线程会阻塞，获得锁之后线程会被唤醒，阻塞和唤醒的操作是比较耗时间的，如果同步块的代码执行比较快，等待锁的线程可以进行先进行自旋操作（就是不释放CPU，执行一些空指令或者是几次for循环），等待获取锁，这样效率比较高。所以轻量级锁天然瞄准不存在锁竞争的场景，如果存在锁竞争但不激烈，仍然可以用自旋锁优化，自旋失败后再升级为重量级锁。
轻量级锁的加锁过程
JVM会为每个线程在当前线程的栈帧中创建用于存储锁记录的空间，我们称为Displaced Mark Word。如果一个线程获得锁的时候发现是轻量级锁，会把锁的Mark Word复制到自己的Displaced Mark Word里面。
然后线程尝试用CAS操作将自己线程栈中拷贝的锁记录的地址写入到锁对象的Mark Word中。如果成功，当前线程获得锁，如果失败，表示Mark Word已经被替换成了其他线程的锁记录，说明在与其它线程竞争锁，当前线程就尝试使用自旋来获取锁。
自旋：不断尝试去获取锁，一般用循环来实现。
自旋是需要消耗CPU的，如果一直获取不到锁的话，那该线程就一直处在自旋状态，白白浪费CPU资源。
JDK采用了适应性自旋，简单来说就是线程如果自旋成功了，则下次自旋时触发重量级锁的阀值会更高，如果自旋失败了，则自旋的次数就会减少。
自旋也不是一直进行下去的，如果自旋到一定程度（和JVM、操作系统相关），依然没有获取到锁，称为自旋失败，那么这个线程会阻塞。同时这个锁就会升级成重量级锁。
轻量级锁的释放流程
在释放锁时，当前线程会使用CAS操作将Displaced Mark Word的内容复制回锁的Mark Word里面。如果没有发生竞争，那么这个复制的操作会成功。如果有其他线程因为自旋多次导致轻量级锁升级成了重量级锁，那么CAS操作会失败，此时会释放锁并唤醒被阻塞的线程。轻量级锁的加锁解锁流程图：
重量级锁
每个对象都有一个监视器monitor对象，重量级锁就是由对象监视器monitor来实现的，当多个线程同时请求某个重量级锁时，重量级锁会设置几种状态用来区分请求的线程：
Contention List 竞争队列：所有请求锁的线程将被首先放置到该竞争队列，我也不知道为什么网上的文章都叫它队列，其实这个队列是先进后出的，更像是栈，就是当Entry List为空时，Owner线程会直接从Contention List的队列尾部（后加入的线程中）取一个线程，让它成为OnDeck线程去竞争锁。(主要是刚来获取重量级锁的线程是会进行自旋操作来获取锁，获取不到才会进入Contention List，所以OnDeck线程主要与刚进来还在自旋，还没有进入到Contention List的线程竞争)
Entry List 候选队列：Contention List中那些有资格成为候选人的线程被移到Entry List，主要是为了减少对Contention List的并发访问，因为既会添加新线程到队尾，也会从队尾取线程。
Wait Set 等待队列：那些调用wait()方法被阻塞的线程被放置到Wait Set。
OnDeck：任何时刻最多Entry List中只能有一个线程被选中，去竞争锁，该线程称为OnDeck线程。
Owner：获得锁的线程称为Owner。
!Owner：释放锁的线程。
重量级锁执行流程：
流程图如下：
步骤1是线程在进入Contention List时阻塞等待之前，程会先尝试自旋使用CAS操作获取锁，如果获取不到就进入Contention List队列的尾部(所以不是公平锁)。
步骤2是Owner线程在解锁时，如果Entry List为空，那么会先将Contention List中队列尾部的部分线程移动到Entry List。(所以Contention List相当于是后进先出，所以也是不公平的)
步骤3是Owner线程在解锁时，如果Entry List不为空，从Entry List中取一个线程，让它成为OnDeck线程，Owner线程并不直接把锁传递给OnDeck线程，而是把锁竞争的权利交给OnDeck，OnDeck需要重新竞争锁，JVM中这种选择行为称为 “竞争切换”。（主要是与还没有进入到Contention List，还在自旋获取重量级锁的线程竞争）
步骤4就是OnDeck线程获取到锁，成为Owner线程进行执行。
等待和通知步骤(这是调用了wait()和notify()方法才有的步骤)：
在同步块中，获得了锁的线程调用锁对象的Object.wait()方法，就是Owner线程调用锁对象的wait()方法进行等待，会移动到Wait Set中，并且会释放CPU资源，也同时释放锁，
就是当其他线程调用锁对象的Object.notify()方法，之前调用wait方法等待的这个线程才会从Wait Set移动到Entry List，等待获取锁。
3.为什么说是轻量级，重量级锁是不公平的？
偏向锁由于不涉及到多个线程竞争，所以谈不上公平不公平，轻量级锁获取锁的方式是多个线程进行自旋操作，然后使用用CAS操作将锁的Mark Word中存储的Lock Word替换为指向自己线程栈中拷贝的锁记录的指针，所以谁能获得锁就看运气，不看先后顺序。重量级锁不公平主要在于刚进入到重量级的锁的线程不会直接进入Contention List队列，而是自旋去获取锁，所以后进来的线程也有一定的几率先获得到锁，所以是不公平的。
4.重量级锁为什么需要自旋操作？
因为那些处于ContetionList、EntryList、WaitSet中的线程均处于阻塞状态，阻塞操作由操作系统完成（在Linxu下通过pthreadmutexlock函数）。线程被阻塞后便进入内核（Linux）调度状态，这个会导致系统在用户态与内核态之间来回切换，严重影响锁的性能。如果同步块中代码比较少，执行比较快的话，后进来的线程先自旋获取锁，先执行，而不进入阻塞状态，减少额外的开销，可以提高系统吞吐量。
5.什么时候会发生锁升级，锁降级？
偏向锁升级为轻量级锁：就是有不同的线程竞争锁时。具体来看就是当一个线程发现当前锁状态是偏向锁，然后锁对象存储的Thread id是其他线程的id，并且去Thread id对应的线程栈查询到的lock record的obj字段不为null（代表当前持有偏向锁的线程还在执行同步块）。那么该偏向锁就会升级成轻量级锁。
轻量级锁升级为重量级锁：就是在轻量级锁中，没有获取到锁的线程进行自旋，自旋到一定次数还没有获取到锁就会进行锁升级，因为自旋也是占用CPU的，长时间自旋也是很耗性能的。
锁降级因为如果没有多线程竞争，还是使用重量级锁会造成额外的开销，所以当JVM进入SafePoint安全点（可以简单的认为安全点就是所有用户线程都停止的，只有JVM垃圾回收线程可以执行）的时候，会检查是否有闲置的Monitor，然后试图进行降级。
6.偏向锁，轻量锁，重量锁的适用场景，优缺点是什么？
偏向锁：加锁解锁不需要进行CAS操作，适合一个线程多次访问同步块的场景。
轻量级锁：加锁和解锁使用CAS操作，没有像重量级锁那样底层操作系统的互斥量来加锁解锁，不涉及到用户态和内核态的切换和线程阻塞唤醒造成的线程上下文切换。没有获得锁的线程会自旋空耗CPU，造成一些开销。适合多线程竞争比较少，但是会有多线程交替执行的场景。
重量级锁：使用到了底层操作系统的互斥量来加锁解锁，但是会涉及到用户态和内核态的切换和线程阻塞和唤醒造成的线程上下文切换，但是不会自旋空耗CPU。
参考文章：
AbstractQueuedSynchronizer(缩写为AQS)是什么？
AQS就是AbstractQueuedSynchronizer，抽象队列同步器，是一个可以用于实现基于先进先出等待队列的锁和同步器的框架。实现锁 ReentrantLock，CountDownLatch,Semaphore，ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。
ReentrantLock其实就是有一个变量sync，Sync父类是AbstractQueuedSynchronizer
public class ReentrantLock implements Lock, java.io.Serializable { private final Sync sync; }点击复制代码复制出错复制成功
ReentrantLock的非公平锁与公平锁的区别在于非公平锁在CAS更新state失败后会调用tryAcquire()来判断是否需要进入同步队列，会再次判断state的值是否为0，为0会去CAS更新state值，更新成功就直接获得锁，否则就进入等待队列。(进等待队列之前会抢锁)
而公平锁首先判断state是否为0，为0并且等待队列为空，才会去使用CAS操作抢占锁，抢占成功就获得锁，没成功并且当前线程不是获得锁的线程，都会被加入到等待队列。
参考资料：
深入理解ReentrantLock的实现原理
synchronized锁与ReentrantLock锁的区别？
相同点：
1.可重入性
两个锁都是可重入的，持有锁的线程再次申请锁时，会对锁的计数器+1。
不同点：
1.实现原理
synchronized是一个Java 关键字，是由JVM实现的，底层代码应该是C++代码。而ReentrantLock是JDK实现的，是Java提供的一个类库，代码是Java代码，源码实现更加方便阅读。
2.性能
在以前，synchronized锁的实现只有重量级锁一种模式，性能会比较差，后面引入了偏向锁和轻量级锁后就优化了很多。根据测试结果，在线程竞争不激烈的情况下，ReentrantLock与synchronized锁持平，竞争比较激烈的情况下，ReentrantLock会效率更高一些。
3.功能
synchronized只能修饰方法，或者用于代码块，而ReentrantLock的加锁和解锁是调用lock和unlock方法，更加灵活。
其次是synchronized的等待队列只有一个(调用wait()方法的线程会进入等待队列)，而ReentrantLock可以有多个条件等待队列。可以分组唤醒需要唤醒的线程们，而不是像synchronized要么用notify方法随机唤醒一个线程要么用notifyAll方法唤醒全部线程。ReentrantLock 提供了一种能够中断等待锁的线程的机制，就是线程通过调用lock.lockInterruptibly()方法来加锁时，一旦线程被中断，就会停止等待。
ReentrantLock可以使用tryLock(long timeout, TimeUnit unit)方法来尝试申请锁，设置一个超时时间，超过超时时间，就会直接返回false，而不是一直等待锁。
ReentrantLock可以响应中断，而synchronized锁不行
4.公平性
synchronized锁是非公平锁，ReentrantLock有公平锁和非公平锁两种模式。
https://www.codercto.com/a/22884.html
