JUC第四讲：Java中的锁/CAS原理与案例分析

本文是JUC第四讲：Java中的锁主要用于保障多并发线程情况下数据的一致性。在多线程编程中为了保障数据的一致性，我们通常需要在使用对象或者方法之前加锁，这时如果有其他线程也需要使用该对象或者该方法，则首先要获得锁，如果某个线程发现锁正在被其他线程使用，就会进入阻塞队列等待锁的释放，直到其他线程执行完成并释放锁，该线程才有机会再次获取锁进行操作。这样就保障了在同一时刻只有一个线程持有该对象的锁并修改对象，从而保障数据的安全

1、Java中的锁

1.1、JVM 做了哪些锁优化？

• 锁从乐观和悲观的角度可分为乐观锁和悲观锁，

  • 乐观锁

    • 乐观锁采用乐观的思想处理数据，在每次读取数据时都认为别人不会修改该数据，所以不会上锁，但在更新时会判断在此期间别人有没有更新该数据，通常采用在写时先读出当前版本号然后加锁的方法。具体过程为：比较当前版本号与上一次的版本号，如果版本号一致，则更新，如果版本号不一致，则重复进行读、比较、写操作。Java中的乐观锁大部分是通过CAS（Compare And Swap，比较和交换）操作实现的，CAS是一种原子更新操作，在对数据操作之前首先会比较当前值跟传入的值是否一样，如果一样则更新，否则不执行更新操作，直接返回失败状态。

  • 悲观锁

    • 悲观锁：假定并发环境是悲观的，如果发生并发冲突，就会破坏一致性，所以要通过独占锁彻底禁止冲突发生
    • 乐观锁：（锁的粒度小）假定并发环境是乐观的，即，虽然会有并发冲突，但冲突可发现且不会造成损害，所以，可以不加任何保护，等发现并发冲突后再决定放弃操作还是重试。

• 从获取资源的公平性角度可分为公平锁和非公平锁

• 从是否共享资源的角度可分为共享锁和独占锁

• 从锁的状态的角度可分为偏向锁、轻量级锁和重量级锁。同时，在JVM中还巧妙设计了自旋锁以更快地使用CPU资源。下面将详细介绍这些锁

  • 偏向锁 --》轻量级锁 --》自旋锁、自适应自旋、锁消除、锁粗化。
  • 自旋锁 – JVM
    • 自旋锁认为：如果持有锁的线程能在很短的时间内释放锁资源，那么那些等待竞争锁的线程就不需要做内核态和用户态之间的切换进入阻塞、挂起状态，只需等一等（也叫作自旋），在等待持有锁的线程释放锁后即可立即获取锁，这样就避免了用户线程在内核状态的切换上导致的锁时间消耗。线程在自旋时会占用CPU，在线程长时间自旋获取不到锁时，将会产CPU的浪费，甚至有时线程永远无法获取锁而导致CPU资源被永久占用，所以需要设定一个自旋等待的最大时间。在线程执行的时间超过自旋等待的最大时间后，线程会退出自旋模式并释放其持有的锁

1.2、为什么要引入偏向锁和轻量级锁？为什么重量级锁开销大？

• 重量级锁底层依赖于系统的同步函数来实现，在 linux 中使用 pthread_mutex_t（互斥锁）来实现。

• 这些底层的同步函数操作会涉及到：操作系统用户态和内核态的切换、进程的上下文切换，而这些操作都是比较耗时的，因此重量级锁操作的开销比较大。

• 而在很多情况下，可能获取锁时只有一个线程，或者是多个线程交替获取锁，在这种情况下，使用重量级锁就不划算了，因此引入了偏向锁和轻量级锁来降低没有并发竞争时的锁开销。

1.3、偏向锁有撤销、膨胀，性能损耗这么大为什么要用呢？

• 偏向锁的好处是在只有一个线程获取锁的情况下，只需要通过一次 CAS 操作修改 markword ，之后每次进行简单的判断即可，避免了轻量级锁每次获取释放锁时的 CAS 操作。

  • markword 见3.7节
  • CAS详解见第4节

• 如果确定同步代码块会被多个线程访问或者竞争较大，可以通过 -XX:-UseBiasedLocking 参数关闭偏向锁。

1.4、偏向锁、轻量级锁、重量级锁分别对应了什么使用场景？

• 1）偏向锁

  • 适用于只有一个线程获取锁。当第二个线程尝试获取锁时，即使此时第一个线程已经释放了锁，此时还是会升级为轻量级锁。
  • 但是有一种特例，如果出现偏向锁的重偏向，则此时第二个线程可以尝试获取偏向锁。
  • Action：什么是重偏向？

• 2）轻量级锁

  • 适用于多个线程交替获取锁。跟偏向锁的区别在于可以有多个线程来获取锁，但是必须没有竞争，如果有则会升级会重量级锁。有同学可能会说，不是有自旋，请继续往下看。

• 3）重量级锁

  • 适用于多个线程同时获取锁。
  • Action：只有重量级锁才会有自旋操作

1.5、自旋发生在哪个阶段？

自旋发生在重量级锁阶段。

网上99.99%的说法，自旋都是发生在轻量级锁阶段，但是实际看了源码（JDK8）之后，并不是这样的。

• 轻量级锁阶段并没有自旋操作，在轻量级锁阶段，只要发生竞争，就是直接膨胀成重量级锁。

• 而在重量级锁阶段，如果获取锁失败，则会尝试自旋去获取锁。

1.6、为什么要设计自旋操作？

因为重量级锁的挂起开销太大。

• 一般来说，同步代码块内的代码应该很快就执行结束，这时候竞争锁的线程自旋一段时间是很容易拿到锁的，这样就可以节省了重量级锁挂起的开销。

1.7、自适应自旋是如何体现自适应的？

自适应自旋锁有自旋次数限制，范围在：1000~5000。

• 如果当次自旋获取锁成功，则会奖励自旋次数100次，如果当次自旋获取锁失败，则会惩罚扣掉次数200次。
• 所以如果自旋一直成功，则JVM认为自旋的成功率很高，值得多自旋几次，因此增加了自旋的尝试次数。
• 相反的，如果自旋一直失败，则JVM认为自旋只是在浪费时间，则尽量减少自旋。

2、Volatile关键字如何保证内存可见性 阿里面试第21题

2.1、Volatile关键字

Java提供了一种稍弱的同步机制，即volatile变量，用来确保将变量的更新操作通知到其他线程。

2.2、Volatile作用

• 1、保证此变量对所有线程的可见性（即当一条线程修改了这个值，新值对于其他所有线程来说是立即得知的） 原理是：每次访问变量时都会进行一次刷新，因此每次访问都是主存中最新的版本
• 2、禁止指令重排序优化（volatile修饰的变量相当于生成内存屏障，重排列时不能把后面的指令排到屏障之前）

2.3、使用场景

当且仅当满足以下所有条件时，才应该使用volatile变量

• 1、对变量的写入操作不依赖变量的当前值，或者你能确保只有单个线程更新变量的值；
• 2、该变量没有包含在具有其他变量的不变式中。

使用建议：

• 1、在两个或者更多线程需要访问的成员变量上使用 volatile。当要访问的变量已在 synchronized 代码块中，或者为常量时，没必要使用 volatile；
• 2、由于使用 volatile 屏蔽掉了 JVM中必要的代码优化，所以效率上比较低，因此一定在必要时才使用此关键字。

缺点：

• 1、无法实现i++原子操作（解决方案：CAS）使用场景：单线程
  • 解决方案见 第4节CAS
• 2、不具备“互斥性”：多个线程能同时读写主存，不能保证变量的“原子性”：（i++不能作为一个整体，分为3个步骤读-改-写），可以使用CAS算法保证数据原子性

2.4、Volatile/Synchronized两者区别（锁的目标：关注互斥性和可见性）

• 1、volatile 不会进行加锁操作
  • volatile 变量是一种稍弱的同步机制，在访问 volatile变量时不会执行加锁操作，因此也就不会使执行线程阻塞，因此 volatile变量是一种比synchronized 关键字更轻量级的同步机制。
• 2、volatile 变量作用类似于同步变量读写操作
  • 从内存可见性来说，写入 volatile变量相当于退出同步代码块，而读取 volatile 变量相当于进入同步代码块；
• 3、volatile不如 Synchronized安全
• 4、volatile仅能实现变量的修改可见性，并不能保证原子性；synchronized则可以保证变量的修改可见性和原子性，例如： count++ ；

3、Synchronized(底层是由JVM层面实现)/锁的升级降级？ 核心

3.1、Synchronized背景案例

• Synchronized 的使用小例子?

public class SynchronizedTest {
 	// 保证内存可见性
    public static volatile int race = 0;
    
    private static CountDownLatch countDownLatch = new CountDownLatch(2);
    public static void main(String[] args) throws InterruptedException {
        // 循环开启2个线程来计数
        for (int i = 0; i < 2; i++) {
            new Thread(() -> {
                // 每个线程累加1万次
                for (int j = 0; j < 10000; j++) {
                    race++;
                }
                countDownLatch.countDown();
            }).start();
        }
        // 等待，直到所有线程处理结束才放行
        countDownLatch.await();
        // 期望输出 2万（2*1万）
        System.out.println(race);
    }
}

• 熟悉的2个线程计数的例子，每个线程自增1万次，预期的结果是2万，但是实际运行结果总是一个小于等于2万的数字，为什么会这样了？

  • race++在我们看来可能只是1个操作，但是在底层其实是由多个操作组成的，所以在并发下会有如下的场景：
    

• 为了得到正确的结果，此时我们可以将 race++ 使用 synchronized 来修饰，如下：

• synchronized (SynchronizedTest.class) {
    	race++;
  }
  

• 加了 synchronized 后，只有抢占到锁才能对 race 进行操作，此时的流程会变成如下：
  

3.2、什么是synchronized

• synchronized是Java的关键字，是Java的内置特性，在JVM层面实现了对临界资源的同步互斥访问
• synchronized特点：
  • synchronized则可以使用在变量、方法（静态方法，同步方法）、和类级别的修饰代码块时，减少了锁范围，耗时的代码放外面，可以异步调用
• synchronized 各种加锁场景？
  • 1、作用于非静态方法，锁住的是对象实例（this），每一个对象实例有一个锁

    • public synchronized void method() {}
      

  • 2、作用于静态方法，锁住的是类的 Class 对象，Class 对象全局只有一份，因此静态方法锁相当于类的一个全局锁，会锁所有调用该方法的线程。

    • public static synchronized void method() {}
      

  • 3、作用于 Lock.class，锁住的是 Lock 的 Class 对象，也是全局只有一个

    • synchronized (Lock.class) {}
      

  • 4、作用于 this，锁住的是对象实例，每一个对象实例有一个锁

    • synchronized (this) {}
      

  • 5、作用于静态成员变量，锁住的是该静态成员变量对象，由于是静态变量，因此全局只有一个

    • public static Object monitor = new Object(); 
      synchronized (monitor) {}
      

  • 有些同学可能会搞混，但是其实很容易记，记住以下两点：
    • 1）必须有“对象”来充当“锁”的角色。
    • 2）对于同一个类来说，通常只有两种对象来充当锁：实例对象、Class 对象（一个类全局只有一份）。
      • Class 对象：静态相关的都是属于 Class 对象，还有一种直接指定 Lock.class。
      • 实例对象：非静态相关的都是属于实例对象。

3.3、为什么调用 Object 的 wait/notify/notifyAll 方法，需要加 synchronized 锁？

• “sleep 和 wait 的区别”，答案中非常重要的一项是：“wait会释放对象锁，sleep不会”，既然要释放锁，那必然要先获取锁。
• 因为这3个方法都会操作锁对象，所以需要先获取锁对象，而加 synchronized 锁可以让我们获取到锁对象
• 来看一个例子：

• public class SynchronizedTest {
    	private static final Object lock = new Object();
    	public static void testWait() throws InterruptedException {
        	lock.wait();
    	}
    	public static void testNotify() throws InterruptedException {
        	lock.notify();
    	}
  }
  

• 在这个例子中，wait 会释放 lock 锁对象，notify/notifyAll 会唤醒其他正在等待获取 lock 锁对象的线程来抢占 lock 锁对象。
• 既然你想要操作 lock 锁对象，那必然你就得先获取 lock 锁对象。就像你想把苹果让给其他同学，那你必须先拿到苹果。
• 再来看一个反例：

• public class SynchronizedTest {
  	private static final Object lock = new Object();
  	public static synchronized void getLock() throws InterruptedException {
          lock.wait();
  	}
  }
  

  • 该方法运行后会抛出 IllegalMonitorStateException，为什么了，我们明明加了 synchronized 来获取锁对象了？
  • 因为在 getLock 静态方法中加 synchronized 方法获取到的是 SynchronizedTest.class 的锁对象，而我们的 wait() 方法是要释放 lock 的锁对象。
  • 这就相当于你想让给其他同学一个苹果（lock），但是你只有一个梨子（SynchronizedTest.class）

3.4、synchronize 底层维护了几个列表存放被阻塞的线程？

这题是紧接着上一题的，很明显面试官想看看我是不是真的对 synchronize 底层原理有所了解。

• synchronized 底层对应的 JVM 模型为 objectMonitor，使用了3个双向链表来存放被阻塞的线程：_cxq（Contention queue）、_EntryList（EntryList）、_WaitSet（WaitSet）。

• 当线程获取锁失败进入阻塞后，首先会被加入到 _cxq 链表，_cxq 链表的节点会在某个时刻被进一步转移到 _EntryList 链表。

具体转移的时刻？见题目30。

• 当持有锁的线程释放锁后，_EntryList 链表头结点的线程会被唤醒，该线程称为 successor（假定继承者），然后该线程会尝试抢占锁。
• 当我们调用 wait() 时，线程会被放入 _WaitSet，直到调用了 notify()/notifyAll() 后，线程才被重新放入 _cxq 或 _EntryList，默认放入 _cxq 链表头部。

objectMonitor 的整体流程如下图：

3.5、为什么释放锁时被唤醒的线程会称为“假定继承者”？被唤醒的线程一定能获取到锁吗？

因为被唤醒的线程并不是就一定获取到锁了，该线程仍然需要去竞争锁，而且可能会失败，所以该线程并不是就一定会成为锁的“继承者”，而只是有机会成为，所以我们称它为假定的。

• 这也是 synchronized 为什么是非公平锁的一个原因。

3.6、Synchronized 锁能降级吗？

答案是可以的。

• 具体的触发时机：在全局安全点（safepoint）中，执行清理任务的时候会触发尝试降级锁。

• 当锁降级时，主要进行了以下操作：

  • 1）恢复锁对象的 markword 对象头；
  • 2）重置 ObjectMonitor，然后将该 ObjectMonitor 放入全局空闲列表，等待后续使用。

3.7、Synchronized 为什么是非公平锁？非公平体现在哪些地方？

Synchronized 的非公平其实在源码中应该有不少地方，因为设计者就没按公平锁来设计，核心有以下几个点：

• 1）当持有锁的线程释放锁时，该线程会执行以下两个重要操作：

  • 先将锁的持有者 owner 属性赋值为 null；
  • 唤醒等待链表中的一个线程（假定继承者);
  • 在1和2之间，如果有其他线程刚好在尝试获取锁（例如自旋），则可以马上获取到锁。

• 2）当线程尝试获取锁失败，进入阻塞时，放入链表的顺序，和最终被唤醒的顺序是不一致的，也就是说你先进入链表，不代表你就会先被唤醒。

3.8、既然加了 synchronized 锁，那当某个线程调用了 wait 的时候明明还在 synchronized 块里，其他线程怎么进入到 synchronized 里去执行 notify 的？

• 如下例子：调用 lock.wait() 时，线程就阻塞在这边了，此时代码执行应该还在 synchronized 块里，其他线程为什么就能进入 synchronized 块去执行 notify() ？

public class SynchronizedTest {
 
    private static final Object lock = new Object();
 
    public static void testWait() throws InterruptedException {
        synchronized (lock) {
            // 阻塞住，被唤醒之前不会输出aa，也就是还没离开synchronized
            lock.wait();
            System.out.println("aa");
        }
    }
 
    public static void testNotify() throws InterruptedException {
        synchronized (lock) {
            lock.notify();
            System.out.println("bb");
        }
    }
}

• 只看代码确实会给人题目中的这种错觉，这也是 Object 的 wait() 和 notify() 方法很多人用不好的原因，包括我也是用的不太好。

• 这个题需要从底层去看，当线程进入 synchronized 时，需要获取 lock 锁，但是在调用 lock.wait() 的时候，此时虽然线程还在 synchronized 块里，但是其实已经释放掉了 lock 锁。

• 所以，其他线程此时可以获取 lock 锁进入到 synchronized 块，从而去执行 lock.notify()。

3.9、如果有多个线程都进入 wait 状态，那某个线程调用 notify 唤醒线程时是否按照进入 wait 的顺序去唤醒？

• 答案是否定的。上面在介绍 synchronized 为什么是非公平锁时也介绍了不会按照顺序去唤醒。

  • 调用 wait 时，节点进入_WaitSet 链表的尾部。
  • 调用 notify 时，根据不同的策略，节点可能被移动到 cxq 头部、cxq 尾部、EntryList 头部、EntryList 尾部等多种情况。

• 所以，唤醒的顺序并不一定是进入 wait 时的顺序。

3.10、notifyAll 是怎么实现全唤起的？

• nofity 是获取 WaitSet 的头结点，执行唤起操作。
• nofityAll 的流程，可以简单的理解为就是循环遍历 WaitSet 的所有节点，对每个节点执行 notify 操作。

3.3、Volatile/Synchronized两者区别：（锁的目标：关注互斥性和可见性）

• 1、volatile仅能修饰变量；synchronized则可以使用在变量、方法、和类级别的
• 2、volatile仅能实现变量的修改可见性，并不能保证原子性；synchronized则可以保证变量的修改可见性和原子性
• 3、volatile非阻塞：确保新值立即同步到主存，其他线程每次使用前立即从主内存刷新；synchronized同步阻塞：释放锁之前会将对变量的修改刷新到主存当中
• 4、volatile标记的变量不会被编译器优化； synchronized标记的变量可以被编译器优化。

3.4、ReentrantLock实现原理？（可重入锁,底层是由AQS实现）

• 在Java5.0之前，协调共享对象的访问时可以使用的机制只有 synchronized 和 volatile。Java5.0后增加了一些新的机制，是当内置锁不适用时，作为一种可选择的高级功能。
• ReentrantLock 实现了Lock接口，通过这个接口可以实现同步访问,提供了比 Synchronized 关键字更灵活、更广泛、粒度更细的锁操作。

特点：

• 1、无锁的同步机制（非公平锁）
• 2、加锁和解锁都需要显示写出，实现了Lock接口，注意一定要在后面 unlock
• 3、可实现轮询锁、定时锁、可中断锁特性
• 4、提供一个condition类，对锁进行更精确的控制
• 5、默认使用非公平锁，可插队跳过对线程队列的处理

ReentrantLock 的内部类Sync继承了AQS，分为公平锁FairSync和非公平锁NonfairSync

• 1、公平锁：线程获取锁的顺序和调用lock的顺序一样，FIFO；浪费唤醒锁的时间；是否是AQS队列中的头结点
• 2、非公平锁：线程获取锁的顺序和调用lock的顺序无关，先执行lock方法的锁不一定先获得锁

优点：

• 1、显示锁可中断，防止死锁，内置锁不可中断，会产生死锁
• 2、可以实现非公平锁提高程序性能
• 3、实现其他特性的锁
• 4、对锁更精细的控制

3.5、Synchronized/ReentrantLock的区别 20181222

• 1、实现层面
  • synchronized（JVM层面的锁）; Lock（JDK层面的锁）
• 2、响应中断
  • 使用synchronized时，等待的线程会一直等待下去，不能够响应中断；Lock可以让等待锁的线程响应中断
• 3、立即返回
  • 可以让线程尝试获取锁，并在无法获取锁的时候立即返回或者等待一段时间，而synchronized却无法办到；
• 4、读写锁
  • Lock可以提高多个线程进行读操作的效率
• 5、可实现公平锁
  • sychronized天生就是非公平锁** （怎么实现？）|Lock可以实现公平锁(fairness)
• 6、显式获取和释放
  • Synchronized在发生异常时，会自动释放线程占有的锁，因此不会导致死锁现象发生；
  • 而Lock在发生异常时，如果没有主动通过unLock()去释放锁，则很可能造成死锁现象，因此使用Lock时需要在finally块中释放锁；
• 7、性能上：随着近些年 synchronized 的不断优化，ReentrantLock 和 synchronized 在性能上已经没有很明显的差距了，所以性能不应该成为我们选择两者的主要原因。官方推荐尽量使用 synchronized，除非 synchronized 无法满足需求时，则可以使用 Lock

3.6、synchronized 锁升级流程？

核心流程如下图所示

• synchronized 加锁流程图
  

3.5、synchronized实现原理？（由一对monitorenter/monitorexit指令实现了同步的语义）

synchronized 的底层实现主要区分：方法和代码块，如下图例子。

public class SynchronizedDemo {
    private static final Object lock = new Object();
    public static void main(String[] args) {
        // 锁作用于代码块
        synchronized (lock) {
            System.out.println("hello word");
        }
    }
 
    // 锁作用于方法
    public synchronized void test() {
        System.out.println("test");
    }
}

将该代码进行编译后，查看其字节码，核心代码如下：

{
  public com.joonwhee.SynchronizedDemo();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=1, locals=1, args_size=1
         0: aload_0
         1: invokespecial #1                  // Method java/lang/Object."":()V
         4: return
      LineNumberTable:
        line 9: 0
 
  public static void main(java.lang.String[]);
    descriptor: ([Ljava/lang/String;)V
    flags: ACC_PUBLIC, ACC_STATIC
    Code:
      stack=2, locals=3, args_size=1
         0: getstatic     #2                  // Field lock:Ljava/lang/Object;
         3: dup
         4: astore_1
         5: monitorenter   // 进入同步块  
         6: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
         9: ldc           #4                  // String hello word
        11: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
        14: aload_1
        15: monitorexit   // 退出同步块  
        16: goto          24
        19: astore_2
        20: aload_1
        21: monitorexit  // 退出同步块  
        22: aload_2
        23: athrow
        24: return
      Exception table:
         from    to  target type
             6    16    19   any
            19    22    19   any
 
 
  public synchronized void test();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED  // ACC_SYNCHRONIZED 标记
    Code:
      stack=2, locals=1, args_size=1
         0: getstatic     #3                  // Field java/lang/System.out:Ljava/io/PrintStream;
         3: ldc           #6                  // String test
         5: invokevirtual #5                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
         8: return
      LineNumberTable:
        line 20: 0
        line 21: 8
}

• synchronized 修饰代码块时，编译后会生成 monitorenter 和 monitorexit 指令，分别对应进入同步块和退出同步块。可以看到有两个 monitorexit，这是因为编译时 JVM 为代码块添加了隐式的 try-finally，在 finally 中进行了锁释放，这也是为什么 synchronized 不需要手动释放锁的原因。

• synchronized 修饰方法时，编译后会生成 ACC_SYNCHRONIZED 标记，当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了则会先尝试获得锁。

• 两种实现其实本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。

Synchronized的语义底层是通过一个monitor（监视器锁）对象来完成的，当monitor被占用时处于锁定状态

• 线程执行monitorenter指令时尝试获取monitor的所有权：

  • 1、如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者。
  • 2、如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数+1.
  • 3、如果其他线程已经占用monitor，该线程进入阻塞状态，直到monitor的进入数为0，再尝试获取monitor的所有权

• 线程执行monitorexit指令完成锁的释放

  • monitor的进入数-1，如果-1后进入数为 0，线程退出monitor;其他被monitor阻塞的线程尝试获取monitor

• 优化：

  • 0、java6之前，Monitor的实现完全依靠操作系统内部的互斥锁，因为需要进行用户态到内核态的切换，所以同步操作时一个无差别的重量级操作；
  • 1、代码优化：同步代码块、减少锁粒度、读锁并发
  • 2、JVM对此进行了改进，提供三种不同的Monitor实现： 偏置锁、轻量级锁（CAS操作）、重量级锁（自适应自旋、锁粗化、锁消除）
  • 3、后续版本的synchronized进行了较多改进，在低竞争场景中表现可能优于ReentrantLock

• 锁的升级降级：

  • 当JVM检测到不同的竞争状况时，会自动切换到适合的锁实现，这种切换就是锁的升级、降级：当没有竞争出现时，默认会使用偏斜锁。
  • JVM会利用CAS操作（compare and swap），在对象头上的Mark Word部分设置线程ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁。这样做的假设是基于在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏斜锁可以降低无竞争开销。
  • 如果有另外的线程试图锁定某个已经被偏斜过的对象，JVM就需要撤销（revoke）偏斜锁，并切换到轻量级锁实现。轻量级锁依赖CAS操作Mark Word来试图获取锁，如果重试成功，就使用普通的轻量级锁；否则，进一步升级为重量级锁。
  • 降级：锁降级确实是会发生的，当JVM进入安全点（SafePoint）的时候，会检查是否有闲置的Monitor，然后试图进行降级

3.7、介绍下 Mark Word？

在介绍 Mark Word 之前，需要先了解对象的内存布局。 HotSpot 中，对象在堆内存中的存储布局可以分为三部分：对象头（Header）、实例数据（Instance Data）、对齐填充（Padding）。

1）对象头（Header）

• 主要包含两类信息：Mark Word 和 类型指针。
• Mark Word 记录了对象的运行时数据，例如：HashCode、GC分代年龄、偏向标记、锁标记、偏向的线程ID、偏向纪元（epoch）等，32 位的 markword 如下图所示。

• 类型指针，指向它的类型元数据的指针，Java 虚拟机通过这个指针来确定该对象是哪个类的实例。如果对象是数组，则需要有一个用于记录数组长度的数据。

2）实例数据（Instance Data）

• 对象存储的真正有效信息，即我们在代码里定义的各种类型的字段内容。

3）对齐填充（Padding）

• Hotspot 要求对象的大小必须是8字节的整数倍，因此，如果实例数据不是8字节的整数倍时，需要通过该字段进行填充。

3.8、介绍下 Lock Record？

锁记录，这个大家应该都听过，用于轻量级锁时暂存对象的 markword。
Lock Record 在源码中为 BasicObjectLock，源码如下：

class BasicObjectLock VALUE_OBJ_CLASS_SPEC {
 private:
  BasicLock _lock;
  oop       _obj;
};
class BasicLock VALUE_OBJ_CLASS_SPEC {
 private:
  volatile markOop _displaced_header; 
};

其实就两个属性：

1）_displaced_header：用于轻量级锁中暂存锁对象的 markword，也称为 displaced mark word。

2）_obj：指向锁对象。

Lock Record 除了用于暂存 markword 之外，还有一个重要的功能是用于实现锁重入的计数器，当每次锁重入时，会用一个 Lock Record 来记录，但是此时 _displaced_header 为 null。

这样在解锁的时候，每解锁1次，就移除1个 Lock Record。移除时，判断 _displaced_header 是否为 null。如果是，则代表是锁重入，则不会执行真正的解锁；否则，代表这是最后一个 Lock Record，此时会真正执行解锁操作。

3.9、什么匿名偏向？

所谓的匿名偏向是指该锁从未被获取过，也就是第一次偏向，此时的特点是锁对象 markword 的线程 ID 为0。

当第一个线程获取偏向锁后，线程ID会从0修改为该线程的 ID，之后该线程 ID 就不会为0了，因为释放偏向锁不会修改线程 ID。

这也是为什么说偏向锁适用于：只有一个线程获取锁的场景。

3.10、偏向锁模式下 hashCode 存放在哪里？

偏向锁状态下是没有地方存放 hashCode 的。

因此，当一个对象已经计算过 hashCode 之后，就再也无法进入偏向锁状态了。

如果一个对象当前正处于偏向锁状态，收到需要计算其 hashCode 的请求时（Object::hashCode()或者System::identityHashCode（Object）方法的调用），它的偏向锁状态就会立即被撤销。

3.11、偏向锁流程？

首先，在开启偏向锁的时候，对象创建后，其偏向锁标记位为1。如果没开启偏向锁，对象创建后，其偏向锁标记位为0。

加锁流程：

1）从当前线程的栈帧中寻找一个空闲的 Lock Record，将 obj 属性指向当前锁对象。

2）获取偏向锁时，会先进行各种判断，如加锁流程图所示，最终只有两种场景能尝试获取锁：匿名偏向、批量重偏向。

3）使用 CAS 尝试将自己的线程 ID 填充到锁对象 markword 里，修改成功则获取到锁。

4）如果不是步骤2的两种场景，或者 CAS 修改失败，则会撤销偏向锁，并升级为轻量级锁。

5）如果线程成功获取偏向锁，之后每次进入该同步块时，只需要简单的判断锁对象 markword 里的线程ID是否自己，如果是则直接进入，几乎没有额外开销。

解锁流程：

• 偏向锁的解锁很简单，就是将 obj 属性赋值为 null，这边很重要的点是不会将锁对象 markword 的线程ID还原回0。

• 偏向锁流程中，markword 的状态变化如下图所示：
  

3.12、批量重偏向、批量撤销？启发式算法？

上面我们提到了批量重偏向，与批量重偏向同时被引入的还有批量撤销，官方统称两者为 “启发式算法”。

为什么引入启发式算法？

• 从上面的介绍我们知道，当只有一个线程获取锁时，偏向锁只需在第一次进入同步块时执行一次 CAS 操作，之后每次进入只需要简单的判断即可，此时的开销基本可以忽略。因此在只有一个线程获取锁的场景中，偏向锁的性能提升是非常可观的。

• 但是如果有其他线程尝试获得锁时，此时需要将偏向锁撤销为无锁状态或者升级为轻量级锁。偏向锁的撤销是有一定成本的，如果我们的使用场景存在多线程竞争导致大量偏向锁撤销，那偏向锁反而会导致性能下降。

JVM 开发人员通过分析得出以下两个观点：

• 观点1：对于某些对象，偏向锁显然是无益的。例如涉及两个或更多线程的生产者-消费者队列。这样的对象必然有锁竞争，而且在程序执行过程中可能会分配许多这样的对象。

  • 该观点描述的是锁竞争比较多的场景，对这种场景，一种简单粗暴的方法是直接禁用偏向锁，但是这种方式并不是最优的。

  • 因为在整个服务中，可能只有一小部分是这种场景，因为这一小部分场景而直接放弃偏向锁的优化，显然是不划算的。最理想的情况下是能够识别这样的对象，并只为它们禁用偏向锁。

  • 批量撤销就是对该场景的优化。

• 观点2：在某些情况下，将一组对象重新偏向另一个线程是有好处的。特别是当一个线程分配了许多对象并对每个对象执行了初始同步操作，但另一个线程对它们执行了后续工作。

  • 我们知道偏向锁的设计初衷是用于只有一个线程获取锁的场景。该观点中后半部分其实是符合这场场景的，但是由于前半部分而导致不能享受偏向锁带来的好处，因此 JVM 开发人员要做的就是识别出这场场景，并进行优化。

  • 对于这种场景，官方引入了批量重偏向来进行优化。

• 批量重偏向

  • JVM 选择以 class 为粒度，为每一个 class 维护了一个偏向锁撤销计数器。每当该 class 的对象发生偏向锁撤销的时候，计数器值+1。

  • 当计数器的值超过批量重偏向的阈值（默认20）的时候，JVM 认为此时命中了上述的场景2，就会对整个 class 进行批量重偏向。

  • 每个 class 都会有 markword，当处于偏向锁状态时，markword 会有 epoch 属性，当创建该 class 的实例对象时，实例对象的 epoch 值会赋值为 class 的 epoch 值，也就是说正常情况下，实例对象的 epoch 和 class 的 epoch 是相等的。

  • 而当发生批量重偏向时，epoch 就派上用场了。

  • 当发生批量重偏向时，首先会将 class 的 epoch 值+1，接着遍历所有当前存活的线程的栈，找到该 class 所有正处于偏向锁状态的锁实例对象，将其 epoch 值修改为新值。

  • 而那些当前没有被任何线程持有的锁实例对象，其 epoch 值则没有得到更新，此时会比 class 的 epoch 值小1。在下一次其他线程准备获取该锁对象的时候，不会因为该锁对象的线程ID不为0（也就是曾经被其他线程获取过），而直接升级为轻量级锁，而是使用 CAS 来尝试获取偏向锁，从而达到批量重偏向的优化效果。

  • PS：对应了加锁流程图中的 “锁对象的epoch等于class的epoch？” 的选择框。

• 批量撤销

  • 批量撤销是批量重偏向的后续流程，同样是以 class 为粒度，同样使用偏向撤销计数器。

  • 当批量重偏向后，每次进行偏向撤销时，会计算本次撤销时间和上一次撤销时间的间隔，如果两次撤销时间的间隔超过指定时间（25秒），则此时 JVM 会认为批量重偏向是有效果的，因为此时偏向撤销的频率很低，所以会将偏向撤销计数器重置为0。

  • 而当批量重偏向后，偏向计数器的值继续快速增加，当计数器的值超过批量撤销的阈值（默认40）时，JVM 认为该 class 的实例对象存在明显的锁竞争，不适合使用偏向锁，则会触发批量撤销操作。

  • 批量撤销：

    • 将 class 的 markword 修改为不可偏向无锁状态，也就是偏向标记位为0，锁标记位为01。接着遍历所有当前存活的线程的栈，找到该 class 所有正处于偏向锁状态的锁实例对象，执行偏向锁的撤销操作。

    • 这样当线程后续尝试获取该 class 的锁实例对象时，会发现锁对象的 class 的 markword 不是偏向锁状态，知道该 class 已经被禁用偏向锁，从而直接进入轻量级锁流程。

    • PS：对应了加锁流程图中的 “锁对象的class是否为偏向模式？” 的选择框。

3.13、轻量级锁流程？

加锁流程：

• 如果关闭偏向锁，或者偏向锁升级，则会进入轻量级锁加锁流程。

• 1）从当前线程的栈帧中寻找一个空闲的 Lock Record，obj 属性指向锁对象。

• 2）将锁对象的 markword 修改为无锁状态，填充到 Lock Rrcord 的 displaced_header 属性。

• 3）使用 CAS 将对象头的 markword 修改为指向 Lock Record 的指针

• 此时的线程栈和锁对象的关系如下图所示，可以看到2次锁重入的 displaced_header 填充的是 null
  

解锁流程：

• 1）将 obj 属性赋值为 null。
• 2）使用 CAS 将 displaced_header 属性暂存的 displaced mark word 还原回锁对象的 markword。

3.14、重量级锁流程？

加锁流程：

• 当轻量级锁出现竞争时，会膨胀成重量级锁。

• 1）分配一个 ObjectMonitor，并填充相关属性。

• 2）将锁对象的 markword 修改为：该 ObjctMonitor 地址 + 重量级锁标记位（10）

• 3）尝试获取锁，如果失败了则尝试自旋获取锁

• 4）如果多次尝试后还是失败，则将该线程封装成 ObjectWaiter，插入到 cxq 链表中，当前线程进入阻塞状态

• 5）当其他锁释放时，会唤醒链表中的节点，被唤醒的节点会再次尝试获取锁，获取成功后，将自己从 cxq（EntryList）链表中移除

• 此时的线程栈、锁对象、ObjectMonitor 之间的关系如下图所示：
  
  ObjectMonitor 的核心属性如下：

ObjectMonitor() {
    _header       = NULL; // 锁对象的原始对象头
    _count        = 0;    // 抢占该锁的线程数，_count大约等于 _WaitSet线程数 + _EntryList线程数
    _waiters      = 0,    // 调用wait方法后的等待线程数
    _recursions   = 0;    // 锁的重入数
    _object       = NULL; // 指向锁对象指针
    _owner        = NULL; // 当前持有锁的线程
    _WaitSet      = NULL; // 存放调用wait()方法的线程
    _WaitSetLock  = 0 ;   // 操作_WaitSet链表的锁
    _Responsible  = NULL ;
    _succ         = NULL ;  // 假定继承人
    _cxq          = NULL ;  // 等待获取锁的线程链表，竞争锁失败后会被先放到cxq链表，之后再进入_EntryList链接
    FreeNext      = NULL ;  // 指向下一个空闲的ObjectMonitor
    _EntryList    = NULL ;  // 等待获取锁的线程链表，该链表的头结点是获取锁的第一候选者
    _SpinFreq     = 0 ;
    _SpinClock    = 0 ;
    OwnerIsThread = 0 ; // 标记_owner是指向占用当前锁的线程的指针还是BasicLock，1为线程，0为BasicLock，发生在轻锁升级重锁的时候
    _previous_owner_tid = 0;  // 监视器上一个所有者的线程id
}

解锁流程：

• 1）将重入计数器-1，ObjectMonitor 里的 _recursions 属性。
• 2）先释放锁，将锁的持有者 owner 属性赋值为 null，此时其他线程已经可以获取到锁，例如自旋的线程。
• 3）从 EntryList 或 cxq 链表中唤醒下一个线程节点。

3.15、_cxq 链表和 _EntryList 链表的排队策略？

上文说道，“_cxq 链表的节点会在某个时刻被进一步转移到 _EntryList 链表”，那到底是什么时刻了？

• 通常来说，可以认为是在持有锁的线程释放锁时，该线程需要去唤醒链表中的下一个线程节点，此时如果检查到 _EntryList 为空，并且 _cxq 不为空时，会将 _cxq 链表的节点转移到 _EntryList 中。

• 不过也不全是这样，_cxq 链表和 _EntryList 链表的排队策略的排队策略（QMode）和执行顺序如下：

  • 1）当 QMode = 2 时，此时 _cxq 比 EntryList 优先级更高，如果此时 _cxq 不为空，则会首先唤醒 _cxq 链表的头结点。除了 QMode = 2 之外，其他模式都是唤醒 _EntryList 的头结点。
  • 2）当 QMode = 3 时，无论 _EntryList 是否为空，都会直接将 _cxq 链表中的节点转移到 _EntryList 链表的末尾。
  • 3）当 QMode = 4 时，无论 _EntryList 是否为空，都会直接将 _cxq 链表中的节点转移到 _EntryList 链表的头部。
  • 4）执行到这边，如果 _EntryList 不为空，则直接唤醒 _EntryList 的头结点并返回，如果此时 _EntryList 为空，则继续执行。
  • 5）执行到这边，代表此时 _EntryList 为空。
  • 6）当 QMode = 1 时，将 _cxq 链表的节点转移到 _EntryList 中，并且调换顺序，也就是原来在_cxq 头部，会变到 _EntryList 尾部。
  • 7）剩余情况，将 _cxq 链表的节点转移到 _EntryList 中，并且节点顺序一致。
  • 8）如果此时 _EntryList 不为空，则唤醒 _EntryList 的头结点。

4、CAS乐观锁（非阻塞算法）

CAS（Compare-and-Swap），即比较并替换，是一种实现并发算法时常用到的技术，Java并发包中的很多类都使用了CAS技术。CAS也是现在面试经常问的问题，本文将深入的介绍CAS的原理

4.1、CAS问题背景案例

介绍CAS之前，我们先来看一个例子。

import java.util.concurrent.CountDownLatch;
 
public class VolatileTest {
    // volatile 保障内存可见性
    public static volatile int race = 0;
    private static final int THREADS_COUNT = 20;
    private static CountDownLatch countDownLatch = new CountDownLatch(THREADS_COUNT);
 	// 非原子性
    public static void increase() {
        race++;
    }
 
    public static void main(String[] args) throws InterruptedException {
        Thread[] threads = new Thread[THREADS_COUNT];
        for (int i = 0; i < THREADS_COUNT; i++) {
            threads[i] = new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int i = 0; i < 10000; i++) {
                        increase();
                    }
                    countDownLatch.countDown();
                }
            });
            threads[i].start();
        }
        countDownLatch.await();
        System.out.println(race);
    }
}

• CAS是整个并发包的基础 Atimic原子类/ReentrantLock/AQS底层都是CAS
• 上面这个例子在volatile关键字详解文中用过，我们知道，运行完这段代码之后，并不会获得期望的结果，而且会发现每次运行程序，输出的结果都不一样，都是一个小于200000的数字。
  • JUC第五讲：volatile关键字详解
• 通过分析字节码我们知道，这是因为volatile只能保证可见性，无法保证原子性，而自增操作并不是一个原子操作（如下图所示），在并发的情况下，putstatic指令可能把较小的race值同步回主内存之中，导致我们每次都无法获得想要的结果。那么，应该怎么解决这个问题了？
• 

解决方法：

• 首先我们想到的是用synchronized来修饰increase方法。

• public static synchronized void increase() {
  		// 非原子操作，取值，加一，写值
  		race++
  }
  

  • 使用synchronized修饰后，increase方法变成了一个原子操作，因此是肯定能得到正确的结果。但是，我们知道，每次自增都进行加锁，性能可能会稍微差了点，有更好的方案吗？
• 答案当然是有的，这个时候我们可以使用Java并发包原子操作类（Atomic开头），例如以下代码。

  public static AtomicInteger race = new AtomicInteger(0);
  public static synchronized void increase() {
   	// 原子操作
   	race.getAndIncrement();
  }
  

• 我们将例子中的代码稍做修改：race改成使用AtomicInteger定义，“race++”改成使用“race.getAndIncrement()”，AtomicInteger.getAndIncrement() 是原子操作，因此我们可以确保每次都可以获得正确的结果，并且在性能上有不错的提升。

通过方法调用，我们可以发现，getAndIncrement方法调用getAndAddInt方法，最后调用的是compareAndSwapInt方法，即本文的主角CAS，接下来我们开始介绍CAS。

public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

public final int getAndAddInt(Object o, long offset, int delta) {
    int v;
    do {
    	// 拿到内存位置的最新值
        v = this.getIntVolatile(o, offset);
    } while(!this.compareAndSwapInt(o, offset, v, v + delta)); // CAS修改成功才跳出循环
    return var5;
}

• getAndAddInt 方法解析：拿到内存位置的最新值v，使用CAS尝试修将内存位置的值修改为目标值v+delta，如果修改失败，则获取该内存位置的新值v，然后继续尝试，直至修改成功

4.2、CAS原理分析

• CAS：是一种硬件对并发的支持，用于管理对共享数据的访问。相当于是无锁的非阻塞实现。多数处理器都都实现了一个CAS指令，实现“Compare And Swap”的语义，
  • CAS包含3个操作数：内存值V，旧的预估值A，即将被更新的目标值B，当且仅当内存值V等于旧的预估值A，将内存地址V的值修改为B；否则，不做任何操作。
  • CAS原理：通过unsafe类的compareAndSwap(JNI, Java Native Interface)方法实现的，
    • 该方法包括四个参数：第一个参数是要修改的对象，第二个参数是对象中要修改变量的偏移量，第三个参数是修改之前的值，第四个参数是预想修改后的值
    • 源码如下所示：
      
    • 可以看到调用了“Atomic::cmpxchg”方法，“Atomic::cmpxchg”方法在linux_x86和windows_x86的实现如下。
    • Linux_x86的实现
    • 
    • windows_x86的实现：
    • 
    • Atomic::cmpxchg方法解析：
      • 1、mp是“os::is_MP()”的返回结果，“os::is_MP()”是一个内联函数，用来判断当前系统是否为多处理器。
      • 2、如果当前系统是多处理器，该函数返回1。否则，返回0。
      • 3、LOCK_IF_MP(mp)会根据mp的值来决定是否为cmpxchg指令添加lock前缀。
      • 4、如果通过mp判断当前系统是多处理器（即mp值为1），则为cmpxchg指令添加lock前缀。否则，不加lock前缀。
        • 这是一种优化手段，认为单处理器的环境没有必要添加lock前缀，只有在多核情况下才会添加lock前缀，因为lock会导致性能下降。cmpxchg是汇编指令，作用是比较并交换操作数。
    • intel手册对lock前缀的说明如下：
      • 1、确保对内存的读-改-写操作原子执行。
        • 1、在Pentium及Pentium之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其他处理器暂时无法通过总线访问内存。很显然，这会带来昂贵的开销。
        • 2、从Pentium 4，Intel Xeon及P6处理器开始，intel在原有总线锁的基础上做了一个很有意义的优化：如果要访问的内存区域（area of memory）在lock前缀指令执行期间已经在处理器内部的缓存中被锁定（即包含该内存区域的缓存行当前处于独占或以修改状态），并且该内存区域被完全包含在单个缓存行（cache line）中，那么处理器将直接执行该指令。由于在指令执行期间该缓存行会一直被锁定，其它处理器无法读/写该指令要访问的内存区域，因此能保证指令执行的原子性。这个操作过程叫做缓存锁定（cache locking），缓存锁定将大大降低lock前缀指令的执行开销，但是当多处理器之间的竞争程度很高或者指令访问的内存地址未对齐时，仍然会锁住总线。
      • 2、禁止该指令与之前和之后的读和写指令重排序。
      • 3、把写缓冲区中的所有数据刷新到内存中。
    • 上面的第1点保证了CAS操作是一个原子操作，第2点和第3点所具有的内存屏障效果，保证了CAS同时具有volatile读和volatile写的内存语义。

4.3、CAS乐观锁的缺点

• CAS乐观锁的缺点三大问题：
• ABA问题
• 循环时间长开销大
• 只能保证一个共享变量的原子操作

4.3.1、什么是ABA问题？ABA问题怎么解决？

• CAS 的使用流程通常如下：

  • 1）首先从地址 V 读取值 A；
  • 2）根据 A 计算目标值 B；
  • 3）通过 CAS 以原子的方式将地址 V 中的值从 A 修改为 B。

• 但是在第1步中读取的值是A，并且在第3步修改成功了，我们就能说它的值在第1步和第3步之间没有被其他线程改变过了吗？

• CAS操作的“ABA”问题

  • 如果在这段期间它的值曾经被改成了B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的“ABA”问题

• 如何解决ABA问题

  • 使用版本号(在变量前面追加上版本号，每次变量更新的时候把版本号加一，那么A－B－A 就会变成1A-2B－3A)
  • Java并发包为了解决这个问题，提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。因此，在使用CAS前要考虑清楚“ABA”问题是否会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更高效

4.3.2、循环时间长开销很大

• CAS 通常是配合无限循环一起使用的，我们可以看到 getAndAddInt 方法执行时，如果 CAS 失败，会一直进行尝试。
• 不适用于竞争激烈的情形中：并发越高，失败的次数会越多，CAS如果长时间不成功，会极大的增加CPU的开销。因此CAS不适合竞争十分频繁的场景

4.3.3、只能保证一个变量的原子操作

• 只能保证一个共享变量的原子操作：对多个共享变量操作时，循环CAS就无法保证操作的原子性
• 通过以下两种办法来解决：
  • 1、多个变量放在一个对象里来进行CAS操作，通过 AtomicReference 来保证原子性；
  • 2、使用互斥锁来保证原子性；

4.3、CAS在业务场景的使用

• 1、CAS自旋volatile变量，是一种很经典的用法（AQS）
• 2、在数据库产品中，为保证索引的一致性，一个常见的选择是，保证只有一个线程能够排他性地修改一个索引分区，如何在数据库抽象层面实现呢？
  • 可以考虑为索引分区对象添加一个逻辑上的锁，例如，以当前独占的线程ID作为锁的数值，然后通过原子操作设置lock数值，来实现加锁和释放锁

  public class AtomicBTreePartition {
        	private volatile long lock;
   		public void acquireLock(){}
  		public void releaseeLock(){}
  }
  

• 那么在Java代码中，我们怎么实现锁操作呢？
• 目前Java提供了两种公共API，可以实现这种CAS操作，比如使用java.util.concurrent.atomic.AtomicLongFieldUpdater，它是基于反射机制创建，我们需要保证类型和字段名称正确

  private static fnal AtomicLongFieldUpdater<AtomicBTreePartition> lockFieldUpdater = AtomicLongFieldUpdater.newUpdater(AtomicBTreePartition.class, "lock");
  private void acquireLock(){
    	long t = Thread.currentThread().getId();
    	while (!lockFieldUpdater.compareAndSet(this, 0L, t)){
        	// 等待一会儿，数据库操作可能比较慢
        	…
    	}
  }
  

5、AQS原理详解 20190106

• 数据结构：state、阻塞队列、双链表、线程封装成Node
  • state实现独占；双向链表、Node.Sharead实现共享

非公平锁（可以控制公平性）

• ReentrantLock fairLock = new ReentrantLock(true);//当公平性为真时，会倾向于将锁赋予等待时间最久的线程。公平性是减少线程“饥饿”情况发生的一个办法
• 建议：只有当你的程序确实有公平性需求时，才有必要指定它
• 特性锁
• 可重入：直到state(表示同步状态)为0，其他锁才可以用（线程自己是可以重复获取此锁的（state会累加））
• 对锁获取粒度的一个概念：当一个线程视图获取一个它已经获取的锁时，这个获取动作就自动成功。
• 轮询：用tryLock(long timeout, TimeUnit unit)和tryLock() 这两个方法实现
• 定时：指的是在指定时间内没有获取到锁，就取消阻塞并返回获取锁失败
• 可中断：lockInterruptibly，防止死锁

注意事项：
1、在finally中释放锁，目的是保证在获取锁之后，最终能够被释放；
2、不要将获取锁的过程卸载try块中，因为如果在获取锁时发生了异常，异常抛出的同时，也会导致锁无故被释放
3、reentrantLock提供了一个newCondition方法，以便用户在同一把锁的情况下，可以根据不同的情况执行等待或唤醒动作

• 锁的更细粒度的使用：
  • ReentrantReadWriteLock/StampedLock //适用于当数据量较大，并发读多、并发写少的时候