【躲不过的Java “锁事”】一文扫除对Java各种锁的困扰！

简介

锁是Java中快捷理解多线程的一条捷径，为我们开发多线程提供理论支持，想成为一个合格的工程师，Java中的锁是必定躲不过的一个知识点，并且内容繁多，本文点到为止，浅谈Java中的各种锁，带您理解Java中关于锁的一些常识。

详情

预备知识：初识锁的种类，和各种概念名词

锁的种类

• 从各种锁的设计，抽象出的概览思想可以分为 悲观锁 和 乐观锁
• 根据线程获取锁的抢占机制，和锁的公平性又可以分为公平锁 和 非公平锁。
• 从根据锁是否重复获取可以分为 可重入锁 和 不可重入锁
• 根据锁能否被多个线程持有，可以把锁分为独占锁(排他锁)和共享锁。
• 根据Synchronized锁升降级的状态可以分为 偏向锁 / 轻量级锁 / 重量级锁
• 从资源已被锁定，获取锁的阻塞装填可以分为 自旋锁
• 从对使用锁的粒度设计而言可以分为 分段锁

概念名词

• AQS (AbstractQueuedSynchronizer) :队列同步器

是并发容器J.U.C（java.util.concurrent）下locks包内的一个类，这个类用来构建锁和其他同步组件的基础框架。许多同步类实现都依赖于它，如常用的ReentrantLock / ReentrantReadWriterLock / CountDownLatch，这些类里面都维护了一套aqs的子类，利用子类实现的功能。该队列里面维护的是一堆线程节点。
核心思想是当前线程获取锁的时候如果失败了，就被加入到阻塞队列中（fifo双向队列）配合锁一起使用的。

• CAS (Compare And Swap)

是一种很有名的无锁算法。在不使用锁（没有线程被阻塞）的情况下实现多线程之间的变量同步。其中 java.util.concurrent 包下的 AtomicInteger 就是借助 CAS 来实现的。 但 CAS 也不是没有任何副作用，比如著名的 ABA 问题就是 CAS 引起的。

以上是一些锁的名词，这些分类并不是全是指锁的状态，有的指锁的特性，有的指锁的设计，下面的内容会对每个锁的名词进行一定的解释。

悲观锁 / 乐观锁

• 悲观锁

是一种悲观思想，它总认为最坏的情况可能会出现，它认为数据很可能会被其他人所修改，所以悲观锁在持有数据的时候总会把资源 或者 数据 锁住，这样其他线程想要请求这个资源的时候就会阻塞，直到等到悲观锁把资源释放为止。

传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁 悲观锁的实现往往依靠数据库本身的锁功能实现。

Java 中的 Synchronized 和 ReentrantLock 等独占锁(排他锁)也是一种悲观锁思想的实现，因为 Synchronzied 和 ReetrantLock 不管是否持有资源，它都会尝试去加锁，生怕自己心爱的宝贝被别人拿走。

• 乐观锁

乐观锁的思想与悲观锁的思想相反，它总认为资源和数据不会被别人所修改，所以读取不会上锁，但是乐观锁在进行写入操作的时候会判断当前数据是否被修改过乐观锁的实现方案一般来说有两种：版本号机制 和 CAS实现 。乐观锁多适用于多读的应用类型，这样可以提高吞吐量。

在Java中java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式 CAS 实现的。

版本号机制：
版本号机制是在数据表中加上一个 version 字段来实现的，表示数据被修改的次数，当执行写操作并且写入成功后，version = version + 1，当线程A要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

• CAS中的ABA 问题
  ABA 问题说的是，如果一个变量第一次读取的值是 A，准备好需要对 A 进行写操作的时候，发现值还是 A，那么这种情况下，能认为 A 的值没有被改变过吗？可以是由 A -> B -> A 的这种情况，但是 AtomicInteger 却不会这么认为，它只相信它看到的，它看到的是什么就是什么。

常见解决 ABA 问题的方案加版本号，来区分值是否有变动: 添加一个标识V(version)，对于每个V 增加一，表示修改次数的标记符，对于每一个V，如果应用修改了一次，这个计数器就加1，然后在这个变量需要update的时候，就同时检查变量的值和计数器的值。

---

公平锁 / 非公平锁

我们知道，在并发环境中，多个线程需要对同一资源进行访问，同一时刻只能有一个线程能够获取到锁并进行资源访问，那么剩下的这些线程怎么办呢？这就好比食堂排队打饭的模型，最先到达食堂的人拥有最先买饭的权利，那么剩下的人就需要在第一个人后面排队，这是理想的情况，即每个人都能够买上饭。那么现实情况是，在你排队的过程中，就有个别不老实的人想走捷径，插队打饭，如果插队的这个人后面没有人制止他这种行为，他就能够顺利买上饭，如果有人制止，他就也得去队伍后面排队。

对于正常排队的人来说，没有人插队，每个人都在等待排队打饭的机会，那么这种方式对每个人来说都是公平的，先来后到嘛。这种锁也叫做公平锁。

那么假如插队的这个人成功买上饭并且在买饭的过程不管有没有人制止他，他的这种行为对正常排队的人来说都是不公平的，这在锁的世界中也叫做非公平锁。

• 常见的公平/非公平锁

在ReentrantLock中很明显可以看到其中同步包括两种，分别是公平的FairSync和非公平的NonfairSync。公平锁的作用就是严格按照线程启动的顺序来执行的，不允许其他线程插队执行的；而非公平锁是允许插队的。

默认情况下ReentrantLock是通过非公平锁来进行同步的，包括synchronized关键字都是如此，因为这样性能会更好。因为从线程进入了RUNNABLE状态，可以执行开始，到实际线程执行是要比较久的时间的。而且，在一个锁释放之后，其他的线程会需要重新来获取锁。其中经历了持有锁的线程释放锁，其他线程从挂起恢复到RUNNABLE状态，其他线程请求锁，获得锁，线程执行，这一系列步骤。如果这个时候，存在一个线程直接请求锁，可能就避开挂起到恢复RUNNABLE状态的这段消耗，所以性能更优化。

/**
 * Creates an instance of {@code ReentrantLock}.
 * This is equivalent to using {@code ReentrantLock(false)}.
 */
public ReentrantLock() {
  sync = new NonfairSync();
}

默认状态，使用的ReentrantLock()就是非公平锁。再参考如下代码，我们知道ReentrantLock的获取锁的操作是通过装饰模式代理给sync的。

/**
  * Acquires the lock.
  *
  * 
Acquires the lock if it is not held by another thread and returns
  * immediately, setting the lock hold count to one.
  *
  * 
If the current thread already holds the lock then the hold
  * count is incremented by one and the method returns immediately.
  *
  * 
If the lock is held by another thread then the
  * current thread becomes disabled for thread scheduling
  * purposes and lies dormant until the lock has been acquired,
  * at which time the lock hold count is set to one.
  */
 public void lock() {
   sync.lock();
 }

下面参考一下FairSync和NonfairSync对lock方法的实现：

/**
  * Sync object for non-fair locks
  */
 static final class NonfairSync extends Sync {
   /**
    * Performs lock. Try immediate barge, backing up to normal
    * acquire on failure.
    */
   final void lock() {
     if (compareAndSetState(0, 1))
       setExclusiveOwnerThread(Thread.currentThread());
     else
       acquire(1);
   }
 }
 
 /**
  * Sync object for fair locks
  */
 static final class FairSync extends Sync {
   final void lock() {
     acquire(1);
   }
 }

当使用非公平锁的时候，会立刻尝试配置状态，成功了就会插队执行，失败了就会和公平锁的机制一样，调用acquire()方法，以排他的方式来获取锁，成功了立刻返回，否则将线程加入队列，知道成功调用为止。

---

可重入锁 / 不可重入锁

• 可重入锁：
  可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，再进入该线程的内层方法会自动获取锁（前提锁对象得是同一个对象或者class），不会因为之前已经获取过还没释放而阻塞。Java中ReentrantLock和synchronized都是可重入锁，可重入锁的一个优点是可一定程度避免死锁。下面用示例代码来进行分析：

在上面的代码中，类中的两个方法都是被内置锁synchronized修饰的，doSomething()方法中调用doOthers()方法。因为内置锁是可重入的，所以同一个线程在调用doOthers()时可以直接获得当前对象的锁，进入doOthers()进行操作。

如果是一个不可重入锁，那么当前线程在调用doOthers()之前需要将执行doSomething()时获取当前对象的锁释放掉，实际上该对象锁已被当前线程所持有，且无法释放。所以此时会出现死锁。

而为什么可重入锁就可以在嵌套调用时可以自动获得锁呢？我们通过图示和源码来分别解析一下。

还是打水的例子，有多个人在排队打水，此时管理员允许锁和同一个人的多个水桶绑定。这个人用多个水桶打水时，第一个水桶和锁绑定并打完水之后，第二个水桶也可以直接和锁绑定并开始打水，所有的水桶都打完水之后打水人才会将锁还给管理员。这个人的所有打水流程都能够成功执行，后续等待的人也能够打到水。这就是可重入锁。

但如果是非可重入锁的话，此时管理员只允许锁和同一个人的一个水桶绑定。第一个水桶和锁绑定打完水之后并不会释放锁，导致第二个水桶不能和锁绑定也无法打水。当前线程出现死锁，整个等待队列中的所有线程都无法被唤醒。

之前我们说过ReentrantLock和synchronized都是重入锁，那么我们通过重入锁ReentrantLock以及非可重入锁NonReentrantLock的源码来对比分析一下为什么非可重入锁在重复调用同步资源时会出现死锁。
首先ReentrantLock和NonReentrantLock都继承父类AQS，其父类AQS中维护了一个同步状态status来计数重入次数，status初始值为0。

当线程尝试获取锁时，可重入锁先尝试获取并更新status值，如果status == 0表示没有其他线程在执行同步代码，则把status置为1，当前线程开始执行。如果status != 0，则判断当前线程是否是获取到这个锁的线程，如果是的话执行status+1，且当前线程可以再次获取锁。而非可重入锁是直接去获取并尝试更新当前status的值，如果status != 0的话会导致其获取锁失败，当前线程阻塞。

释放锁时，可重入锁同样先获取当前status的值，在当前线程是持有锁的线程的前提下。如果status-1 == 0，则表示当前线程所有重复获取锁的操作都已经执行完毕，然后该线程才会真正释放锁。而非可重入锁则是在确定当前线程是持有锁的线程之后，直接将status置为0，将锁释放。

独占锁 (写锁) / 共享锁（读锁）/ 互斥锁

• 概念
  独占锁：指该锁一次只能被一个线程所持有。对ReentrantLock和Synchronized而言都是独占锁

共享锁：指该锁可被多个线程所持有。对ReentrantReadWriteLock其读锁是共享锁，其写锁是独占锁。

读锁的共享锁可保证并发读是非常高效的，读写，写读，写写的过程是互斥的。

• ReentrantReadWriteLock实现原理简单分析
  ReentrantReadWriteLock 的核心是由一个基于AQS的同步器 Sync 构成，然后由其扩展出 ReadLock （共享锁）， WriteLock （排它锁）所组成。
  并且从 ReentrantReadWriteLock 的构造函数中可以发现 ReadLock 与 WriteLock 使用的是同一个

• Sync的实现
  sync 是读写锁实现的核心， sync 是基于AQS实现的，在AQS中核心是state字段和双端队列，那么一个一个问题来分析。

Sync是如何同时表示读锁与写锁？
清单2：读写锁状态获取
static final int SHARED_SHIFT = 16;
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;
/** Returns the number of shared holds represented in count /
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
/* Returns the number of exclusive holds represented in count */
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

从代码中获取读写状态可以看出其是把 state（int32位） 字段分成高16位与低16位，其中高16位表示读锁个数，低16位表示写锁个数

一个线程获取到了写锁，并且重入了两次，低16位是3，线程又获取了读锁，并且重入了一次，高16位就是2

读锁的写锁的获取主要调用AQS的相关Acquire方法,其释放主要用了相关Release方法,其中关于AQS的升级降级锁个数的调整还用到了CAS;

偏向锁 / 轻量级锁 / 重量级锁 / 自旋锁

• 隐藏在内置锁下的基本问题

内置锁是JVM提供的最便捷的线程同步工具，在代码块或方法声明上添加synchronized关键字即可使用内置锁。使用内置锁能够简化并发模型；随着JVM的升级，几乎不需要修改代码，就可以直接享受JVM在内置锁上的优化成果。从简单的重量级锁，到逐渐膨胀的锁分配策略，使用了多种优化手段解决隐藏在内置锁下的基本问题。

• 重量级锁

内置锁在Java中被抽象为监视器锁（monitor）。在JDK 1.6之前，监视器锁可以认为直接对应底层操作系统中的互斥量（mutex）。这种同步方式的成本非常高，包括系统调用引起的内核态与用户态切换、线程阻塞造成的线程切换等。因此，后来称这种锁为“重量级锁”。

• 自旋锁

首先，内核态与用户态的切换上不容易优化。但通过自旋锁，可以减少线程阻塞造成的线程切换（包括挂起线程和恢复线程）。

如果锁的粒度小，那么锁的持有时间比较短（尽管具体的持有时间无法得知，但可以认为，通常有一部分锁能满足上述性质）。那么，对于竞争这些锁的而言，因为锁阻塞造成线程切换的时间与锁持有的时间相当，减少线程阻塞造成的线程切换，能得到较大的性能提升。具体如下：

• 当前线程竞争锁失败时，打算阻塞自己
• 不直接阻塞自己，而是自旋（空等待，比如一个空的有限for循环）一会
• 在自旋的同时重新竞争锁
• 如果自旋结束前获得了锁，那么锁获取成功；否则，自旋结束后阻塞自己

如果在自旋的时间内，锁就被旧owner释放了，那么当前线程就不需要阻塞自己（也不需要在未来锁释放时恢复），减少了一次线程切换。

“锁的持有时间比较短”这一条件可以放宽。实际上，只要锁竞争的时间比较短（比如线程1快释放锁的时候，线程2才会来竞争锁），就能够提高自旋获得锁的概率。这通常发生在锁持有时间长，但竞争不激烈的场景中。

缺点

1. 单核处理器上，不存在实际的并行，当前线程不阻塞自己的话，旧owner就不能执行，锁永远不会释放，此时不管自旋多久都是浪费；进而，如果线程多而处理器少，自旋也会造成不少无谓的浪费。
2. 自旋锁要占用CPU，如果是计算密集型任务，这一优化通常得不偿失，减少锁的使用是更好的选择。
3. 如果锁竞争的时间比较长，那么自旋通常不能获得锁，白白浪费了自旋占用的CPU时间。这通常发生在锁持有时间长，且竞争激烈的场景中，此时应主动禁用自旋锁。

• 自适应自旋锁

自适应意味着自旋的时间不再固定了，而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定：

1. 如果在同一个锁对象上，自旋等待刚刚成功获得过锁，并且持有锁的线程正在运行中，那么虚拟机就会认为这次自旋也很有可能再次成功，进而它将允许自旋等待持续相对更长的时间，比如100个循环。

2. 相反的，如果对于某个锁，自旋很少成功获得过，那在以后要获取这个锁时将可能减少自旋时间甚至省略自旋过程，以避免浪费处理器资源。

自适应自旋解决的是“锁竞争时间不确定”的问题。JVM很难感知到确切的锁竞争时间，而交给用户分析就违反了JVM的设计初衷。自适应自旋假定不同线程持有同一个锁对象的时间基本相当，竞争程度趋于稳定，因此，可以根据上一次自旋的时间与结果调整下一次自旋的时间。

缺点
然而，自适应自旋也没能彻底解决该问题，如果默认的自旋次数设置不合理（过高或过低），那么自适应的过程将很难收敛到合适的值。

• 轻量级锁

自旋锁的目标是降低线程切换的成本。如果锁竞争激烈，我们不得不依赖于重量级锁，让竞争失败的线程阻塞；如果完全没有实际的锁竞争，那么申请重量级锁都是浪费的。轻量级锁的目标是，减少无实际竞争情况下，使用重量级锁产生的性能消耗，包括系统调用引起的内核态与用户态切换、线程阻塞造成的线程切换等。

顾名思义，轻量级锁是相对于重量级锁而言的。使用轻量级锁时，不需要申请互斥量，仅仅将Mark Word中的部分字节CAS更新指向线程栈中的Lock Record，如果更新成功，则轻量级锁获取成功，记录锁状态为轻量级锁；否则，说明已经有线程获得了轻量级锁，目前发生了锁竞争（不适合继续使用轻量级锁），接下来膨胀为重量级锁。

Mark Word是对象头的一部分；每个线程都拥有自己的线程栈（虚拟机栈），记录线程和函数调用的基本信息。二者属于JVM的基础内容，此处不做介绍。

缺点：
同自旋锁相似：如果锁竞争激烈，那么轻量级将很快膨胀为重量级锁，那么维持轻量级锁的过程就成了浪费。

• 偏向锁
  在没有实际竞争的情况下，还能够针对部分场景继续优化。如果不仅仅没有实际竞争，自始至终，使用锁的线程都只有一个，那么，维护轻量级锁都是浪费的。偏向锁的目标是，减少无竞争且只有一个线程使用锁的情况下，使用轻量级锁产生的性能消耗。轻量级锁每次申请、释放锁都至少需要一次CAS，但偏向锁只有初始化时需要一次CAS。

“偏向”的意思是，偏向锁假定将来只有第一个申请锁的线程会使用锁（不会有任何线程再来申请锁），因此，只需要在Mark Word中CAS记录owner（本质上也是更新，但初始值为空），如果记录成功，则偏向锁获取成功，记录锁状态为偏向锁，以后当前线程等于owner就可以零成本的直接获得锁；否则，说明有其他线程竞争，膨胀为轻量级锁。

偏向锁无法使用自旋锁优化，因为一旦有其他线程申请锁，就破坏了偏向锁的假定。

缺点：
同样的，如果明显存在其他线程申请锁，那么偏向锁将很快膨胀为轻量级锁。不过这个副作用已经小的多。如果需要，使用参数-XX:-UseBiasedLocking禁止偏向锁优化（默认打开）。

总结：

• 偏向锁：无实际竞争，且将来只有第一个申请锁的线程会使用锁。
• 轻量级锁：无实际竞争，多个线程交替使用锁；允许短时间的锁竞争。
• 重量级锁：有实际竞争，且锁竞争时间长。

分段锁

分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。
我们以ConcurrentHashMap来说一下分段锁的含义以及设计思想，ConcurrentHashMap中的分段锁称为Segment，它即类似于HashMap（JDK7与JDK8中HashMap的实现）的结构，即内部拥有一个Entry数组，数组中的每个元素又是一个链表；同时又是一个ReentrantLock（Segment继承了ReentrantLock)。
当需要put元素的时候，并不是对整个hashmap进行加锁，而是先通过hashcode来知道他要放在那一个分段中，然后对这个分段进行加锁，所以当多线程put的时候，只要不是放在一个分段中，就实现了真正的并行的插入。
但是，在统计size的时候，可就是获取hashmap全局信息的时候，就需要获取所有的分段锁才能统计。
分段锁的设计目的是细化锁的粒度，当操作不需要更新整个数组的时候，就仅仅针对数组中的一项进行加锁操作。

相关面试题

1. Synchronized作用于静态方法和非静态方法的区别？

非静态方法：
给对象加锁(可以理解为给这个对象的内存上锁,注意 只是这块内存,其他同类对象都会有各自的内存锁),这时候在其他一个以上线程中执行该对象的这个同步方法(注意:是该对象)就会产生互斥
静态方法:
相当于在类上加锁(*.class位于代码区,静态方法位于静态区域,这个类产生的对象公用这个静态方法,所以这块内存，N个对象来竞争),这时候,只要是这个类产生的对象,在调用这个静态方法时都会产生互斥。即该类所有的对象都共享一把锁。

2.当一个线程进入一个对象的synchronized方法A之后，其它线程是否可进入此对象的synchronized方法B？

不能。其它线程只能访问该对象的非同步方法，同步方法则不能进入。因为非静态方法上的synchronized修饰符要求执行方法时要获得对象的锁，如果已经进入A方法说明对象锁已经被取走，那么试图进入B方法的线程就只能在等锁池（注意不是等待池哦）中等待对象的锁

3.线程同步的几种方式

synchronized修饰
1，volatile实现同步（只能保证可见性，不能保证原子性）
2，使用局部变量ThreadLocal
3，使用原子类（AtomicInteger、AtomicBoolean……）
4，使用Lock
5，使用容器类（BlockingQueue、ConcurrentHashMap）

4.synchronized和java.util.concurrent.locks.Lock的异同？

Lock 和 synchronized 有一点明显的区别 —— lock 必须在 finally 块中释放。否则，如果受保护的代码将抛出异常，锁就有可能永远得不到释放！这一点区别看起来可能没什么，但是实际上，它极为重要。忘记在 finally 块中释放锁，可能会在程序中留下一个定时炸弹，当有一天炸弹爆炸时，您要花费很大力气才有找到源头在哪。而使用同步，JVM 将确保锁会获得自动释放。

一个 Lock 对象和一个 synchronized 代码块之间的主要不同点是：
synchronized 代码块不能够保证进入访问等待的线程的先后顺序。 你不能够传递任何参数给一个 synchronized代码块的入口。因此，对于 synchronized 代码块的访问等待设置超时时间是不可能的事情。 synchronized块必须被完整地包含在单个方法里。而一个 Lock 对象可以把它的 lock() 和 unlock() 方法的调用放在不同的方法里。

5.乐观锁和悲观锁的理解及如何实现，有哪些实现方式？

乐观锁，每次操作时不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止
悲观锁是会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。
乐观锁可以使用volatile+CAS原语实现，带参数版本来避免ABA问题，在读取和替换的时候进行判定版本是否一致
悲观锁可以使用synchronize的以及Lock

6.Synchronized有哪些缺点？

1. 只有一个condition与锁相关联，这个condition是什么？就是synchronized对针对的对象锁。
2. synchronized无法中断一个正在等待获得锁的线程，也即多线程竞争一个锁时，其余未得到锁的线程只能不停的尝试获得锁，而不能中断。这种情况对于大量的竞争线程会造成性能的下降等后果。

7.我们面对ReentrantLock和synchronized改如何选择？

Synchronized相比Lock，为许多开发人员所熟悉，并且简洁紧凑，如果现有程序已经使用了内置锁，那么尽量保持代码风格统一，尽量不引入Lock，避免两种机制混用，容易令人困惑，也容易发生错误。在Synchronized无法满足需求的情况下，Lock可以作为一种高级工具，这些功能包括“可定时的、可轮询的与可中断的锁获取操作，公平队列，以及非块结构的锁”否则还是优先使用Synchronized。最后，未来更可能提升Synchronized而不是Lock的性能，因为Synchronized是JVM的内置属性，他能执行一些优化，例如对线程封闭的锁对象的锁消除优化，通过增加锁的粒度来消除内置锁的同步，而如果基于类库的锁来实现这些功能，则可能性不大

8.死锁产生的四个条件

1. 互斥条件：资源是独占的且排他使用，进程互斥使用资源，即任意时刻一个资源只能给一个进程使用，其他进程若申请一个资源，而该资源被另一进程占有时，则申请者等待直到资源被占有者释放。
2. 不可剥夺条件：进程所获得的资源在未使用完毕之前，不被其他进程强行剥夺，而只能由获得该资源的进程资源释放。
3. 请求和保持条件：进程每次申请它所需要的一部分资源，在申请新的资源的同时，继续占用已分配到的资源。
4. 循环等待条件：在发生死锁时必然存在一个进程等待队列{P1,P2,…,Pn},其中P1等待P2占有的资源，P2等待P3占有的资源，…，Pn等待P1占有的资源，形成一个进程等待环路，环路中每一个进程所占有的资源同时被另一个申请，也就是前一个进程占有后一个进程所深情地资源

9.能手写一个死锁吗？

下方为一个简单的死锁代码实现：（其实话题理解很简单，和贪吃蛇一样头咬着尾巴）

/**
 * 一个简单的死锁类
 * main方法中启动两个线程，分别调用methodA和methodB方法
 * methodA方法首先获取到a对象的锁，睡眠1秒钟
 * 此时methodB方法执行获取到b对象的锁，睡眠1秒
 * 此时methodA需要去获取b对象的锁才能继续执行，但是b锁没有被释放无法获取到
 * 此时methodB需要去获取a对象的锁才能继续执行，但是a锁没有被释放无法获取到
 * 从而两者相互等待，都需要得到对方锁定的资源才能继续执行，从而死锁。
 */
public class DeadLock {
    private static String a = "1";
 
    private static String b = "2";
 
    public void methodA() {
        synchronized (a) {
            System.out.println("我是A方法中获得到了A锁");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            synchronized (b) {
                System.out.println("我是A方法中获取到b锁");
            }
        }
 
    }
 
    public void methodB() {
        synchronized (b) {
            System.out.println("我是B方法中获得到了b锁");
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            synchronized (a) {
                System.out.println("我是B方法中获取到a锁");
            }
        }
 
    }
 
    public static void main(String[] args) {
      
        new Thread(() -> {
            d.methodA();
        }).start();
        new Thread(() -> {
            d.methodB();
        }).start();
 
 
    }
}

上述代码就会产生死锁：

我是A方法中获得到了A锁
我是B方法中获得到了b锁

10.手写一个单例模式，双检锁分析一下。

懒汉式单例模式

//第一种
public class LazySingleton {
	//静态私用成员，没有初始化
    private static LazySingleton intance = null;
    
    private LazySingleton() {}
     //静态，同步，公开访问点
    synchronized public static LazySingleton getInstance(){
        if(intance == null){
            intance = new LazySingleton();
        }
        return intance;
    }

	/**
     * 该懒汉式单例类在getInstance()方法前面增加了关键字synchronized进行线程锁，以处理多个线
     * 程同时访问的问题。但是，上述代码虽然解决了线程安全问题，但是每次调用getInstance()时
     * 都需要进行线程锁定判断，在多线程高并发访问环境中，将会导致系统性能大大降低。如何
     * 既解决线程安全问题又不影响系统性能呢？我们继续对懒汉式单例进行改进。事实上，我们
     * 无须对整个getInstance()方法进行锁定，只需对其中的代码“instance = new LazySingleton();”进行锁定即可。
     * 因此getInstance()方法可以进行如下改进：
     *
     */
    public static LazySingleton getInstance() {
        if (instance == null) {
            synchronized (LazySingleton.class) {
                instance = new LazySingleton();
            }
        }
        return instance;
    }
/**
     * 问题貌似得以解决，事实并非如此。如果使用以上代码来实现单例，还是会存在单例对象不
     * 唯一。原因如下：
     * 假如在某一瞬间线程A和线程B都在调用getInstance()方法，此时instance对象为null值，均能通
     * 过instance == null的判断。由于实现了synchronized加锁机制，线程A进入synchronized锁定的代
     * 码中执行实例创建代码，线程B处于排队等待状态，必须等待线程A执行完毕后才可以进入
     * synchronized锁定代码。但当A执行完毕时，线程B并不知道实例已经创建，将继续创建新的实
     * 例，导致产生多个单例对象，违背单例模式的设计思想，因此需要进行进一步改进，在
     * synchronized中再进行一次(instance == null)判断，这种方式称为双重检查锁定(Double-Check
     * Locking)。使用双重检查锁定实现的懒汉式单例类完整代码如下所示：
     *
     */

    class LazySingleton {
        private volatile static LazySingleton instance = null;
        private LazySingleton() { }
        public static LazySingleton getInstance() {
        //第一重判断
            if (instance == null) {
        //锁定代码块
                synchronized (LazySingleton.class) {
        //第二重判断
                    if (instance == null) {
                        instance = new LazySingleton(); //创建单例实例
                    }
                }
            }
            return instance;
        }
    }

 

使用双重检查锁定来实现懒汉式单例类，需要在静态成员变量instance之前增加修饰符volatile，被volatile修饰的成员变量可以确保多个线程都能够正确处理，且该代码只能在JDK 1.5及以上版本中才能正确执行。由于volatile关键字会屏蔽Java虚拟机所做的一些代码优化，可能会导致系统运行效率降低，因此即使使用双重检查锁定来实现单例模式也不是一种完美的实现方式。

饿汉式单例模式 (在类加载时就完成了初始化，所以类加载较慢，但获取对象的速度快)

public class EagerSingleton {
 
    private static EagerSingleton instance = new EagerSingleton();//静态私有成员，已初始化
    
    private EagerSingleton(){}
    //静态，不用同步（类加载时已初始化，不会有多线程的问题）
    public static EagerSingleton getInstance(){
        return instance;
    }
}

11. 为什么需要volatile？volatile有什么用？

• 首先要回答可见性，这个是毋庸质疑的，然后可能又会考到java内存模型。
• 防止指令重排序: 防止new Singleton时指令重排序导致其他线程获取到未初始化完的对象。instance = new Singleton()这句，这并非是一个原子操作，事实上在 JVM 中这句话大概做了下面 3 件事情。
  1.给 instance 分配内存
  2.调用 Singleton 的构造函数来初始化成员变量
  3.将instance对象指向分配的内存空间（执行完这步 instance 就为非 null 了）

参考资料 & 致谢

【1】基本功-不可不说的Java“锁”事
【2】Java锁的种类
【3】从synchronized 到CAS 和 AQS彻底弄懂Java各种并发锁
【4】AQS是什么
【5】Java中的公平锁和非公平锁实现详解
【6】独占锁(写锁)/共享锁(读锁)/互斥锁
【7】浅谈偏向锁、轻量级锁、重量级锁
【8】详细介绍Java锁当中的公平锁、乐观锁、分段锁等14种锁的分类
【9】Java 关于锁常见面试题
【10】死锁简单的一个实现样例
【11】[设计模式_Java版] .刘伟