苍穹之边，浩瀚之挚，眰恦之美；悟心悟性，善始善终，惟善惟道！ —— 朝槿《朝槿兮年说》

Picture-Navigation

写在开头

Picture-Header

对于Java领域中的锁，其实从接触Java至今，我相信每一位Java Developer都会有这样的一个感觉？不论是Java对锁的实现还是应用，真的是一种“群英荟萃”，而且每一种锁都有点各有各的驴，各有各的本，各不相同。

在很多情况下，以及在各种锁的应用场景里，各式各样的定义，难免会让我们觉得无所适从，很难清楚该如何对这些锁做到得心应手？

在并发编程色世界中，一般情况下，我们只需了解其是如何使用锁之后就已经满足我们大部分的需求，但是作为一名对技术研究有执念和热情的人来说，深入探究和分析才是对技术的探秘之乐趣。

作为一名Java Developer来说，深入探究和分析和正确了解和掌握这些锁的机制和原理，需要我们带着一些实际问题，通过对其探究分析和加上实际应用分析，才能真正意义上理解和掌握。

一般来说，针对于不同场景提供的锁，都用于解决什么问题？不论是从实现方式上，还是从使用场景上，都可以应对这些锁的特点，我们又该如何认识和理解？

接下来，今天我们就一起来盘一盘，Java领域中那些并发锁，盘点一下相关的锁，从设计基本思想和设计实现，以及应用分析等方面来总体分析探讨一下。

关健术语

Picture-Keyword

本文用到的一些关键词语以及常用术语，主要如下：

进程(Process): 计算机中的程序关于某数据集合上的一次运行活动，是系统进行资源分配和调度的基本单位，是操作系统结构的基础。在早期面向进程设计的计算机结构中，进程是程序的基本执行实体；在当代面向线程设计的计算机结构中，进程是线程的容器。
线程(thread): 操作系统能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。在Unix System V及SunOS中也被称为轻量进程（Light-Weight Processes），但轻量进程更多指内核线程（Kernel Thread），而把用户线程（User Thread）称为线程。

基本概述

Picture-Content

在Java领域中，单纯从Java对其实现的方式上来看，我们大体上可以将其分为基于Java语法层面(关键词)实现的锁和基于JDK层面实现的锁。

基于这两个基本点，可以作为我们对于Java领域中的锁的一个基础认识，这对于我们认识和了解Java领域中的锁指导一个参考方向。

一般来说，锁是并发编程中最基础和最常用的一项技术，而且在Java的内部JDK中其使用也是非常地广泛。

接下来，我们便一起探究和认识一下Java领域中的各种各样的锁。

一.锁的基本理论

锁的基本理论主要是指从锁的基本定义和基本特点以及基本意义去分析的一般模型理论，是一套帮助我们认识和了解锁的简单的思维方法论。

Picture-Content

一般在了解一个事物之前，我们都会按照基本定义，基本特点以及基本意义去看待这个事物。在计算机的世界里，锁本身也和我们实际生活一样，也是一个比较普遍且应用场景繁多的一种事物。

比如，在操作系统中，也定义了各种各样的锁；在数据库系统中也出现了锁。甚至，在CPU处理器架构中都会看见锁的身影。

但是，这里就会有一个问题：既然都在使用锁，可是对于锁该去如何定义，似乎都很难给出一个准确的定义？换而言之，这也许就是我们对于锁只是知道有这个东西，但是一直有云里雾里的基本原因。

从本质上讲，计算机软件开发领域中的锁是一种协调多个进程或者多个线程对某一个资源的访问的控制机制，其核心是作用于资源，也作用于着这个定义中提到的进程和线程等。其中：

进程(Process): 操作系统进行资源分配和调度的基本单位，是计算机程序中的实体，其中，程序是指令、数据及其组织形式的描述。
线程(Thread) : 操作系统能够进行运算调度的最小单位，一条线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。

一般来说，线程主要分为位于系统内核空间的线程称为内核线程（Kernel Thread)和位于应用程序的用户空间的线程被称为用户线程（User Thread)两种，其中：

也就是我们一般说的Java线程等均属于用户线程,而内核线程主要是操作系统封装的函数库以及API等。

而且最关健的就是，我们平日里所提到Java线程和JVM都是位于用户空间之中，从Java层到操作系统系统的线程调度顺序来看，一般流程是：java.lang.Thread(Target Thread)->Java Thread->OSThread->pthread->Kernel Thread。

简单来说，在Java领域中，锁是用于控制多个线程访问共享资源的工具。一般，锁提供对共享资源的独立访问：一次只有一个线程可以获取锁，所有对共享资源的访问都需要先获取锁。但是，某些锁可以并发访问共享资源。

对于并发访问共享资源来说，主要是依据现在大多数操作系统的线程的调度方式是抢占式调度，因此加锁是为了维护数据的一致性和完整性，其实就是数据的安全性。

综上所述，我们便可以得到一个关于锁的基本概念模型，接下来我们便来一一盘点以下主要有哪些锁。

二.锁的基本分类

在Java领域中，我们可以将锁大致分为基于Java语法层面(关键词)实现的锁和基于JDK层面实现的锁。

单纯从Java对其实现的方式上来看，我们大体上可以将其分为基于Java语法层面(关键词)实现的锁和基于JDK层面实现的锁。其中：

Java内置锁：基于Java语法层面(关键词)实现的锁，主要是根据Java语义来实现，最典型的应用就是synchronized。
Java显式锁：基于JDK层面实现的锁，主要是根据基于Lock接口和ReadWriteLock接口，以及统一的AQS基础同步器等来实现，最典型的有ReentrantLock。

需要特别注意的是，在Java领域中，基于JDK层面的锁通过CAS操作解决了并发编程中的原子性问题，而基于Java语法层面实现的锁解决了并发编程中的原子性问题和可见性问题。

除此之外之外，在Java并发容器中曾用到过一种Segment数组结构来实现的分段锁。

而从具体到对应的Java线程资源来说，我们按照是否含有某一特性来定义锁，主要可以从如下几个方面来看：

从加锁对象角度方面上来看，线程要不要锁住同步资源？如果是需要加锁，锁住同步资源的情况下，一般称其为悲观锁；否则，如果是不需要加锁，且不用锁住同步资源的情况就属于为乐观锁。
从获取锁的处理方式上来看，假设锁住同步资源，其对该线程是否进入睡眠状态或者阻塞状态？如果会进入睡眠状态或者阻塞状态，一般称其为互斥锁，否则，不会进入睡眠状态或者阻塞状态属于一种非阻塞锁，即就是自旋锁。
从锁的变化状态方面来看，多个线程在竞争资源的流程细节上是否有差别？
首先，对于不会锁住资源，多个线程只有一个线程能修改资源成功，其他线程会依据实际情况进行重试，即就是不存在竞争的情况，一般属于无锁。
其次，对于同一个线程执行同步资源会自动获取锁资源，一般属于偏向锁。
然而，对于多线程竞争同步资源时，没有获取到锁资源的线程会自旋等待锁释放，一般属于轻量级锁。
最后，对于多线程竞争同步资源时，没有获取到锁资源的线程会阻塞等待唤醒，一般属于重量级锁。
从锁竞争时公平性上来看，多个线程在竞争资源时是否需要排队等待？如果是需要排队等待的情况，一般属于公平锁；否则，先插队，然后再尝试排队的情况属于非公平锁。
从获取锁的操作频率次数来看，一个线程中的多个流程是否可以获取同一把锁？如果是可以多次进行加锁操作的情况，一般属于可重入锁，否则，可以多次进行加锁操作的情况属于非可重入锁。
从获取锁的占有方式上来看，多个线程能不能共享一把锁？如果是可以共享锁资源的情况，一般属于共享锁；否则，独占锁资源的情况属于排他锁。

针对于上述描述的各种情况，接下来，我们便来一起详细看看，在Java领域中，这个锁的具体情况。

三.Java内置锁

在Java领域中，Java内置锁主要是指基于Java语法层面(关键词)实现的锁。

在Java领域中，我们把基于Java语法层面(关键词)实现的锁称为内置锁，比如synchronized 关键字。

对于synchronized 关键字的解释，最直接的就是Java语言中为开发人员提供的同步工具，可以看作是Java中的一种“语法糖”。主要宗旨在于解决多线程并发执行过程中数据同步的问题。

不像其他的编程语言(C++),在处理同步问题时都需要自己进行锁处理，主要特点就是简单，直接声明即可。

在 Java 程序中，利用 synchronized 关键字来对程序进行加锁，其实现同步的语义是互斥锁。既可以用来声明一个 synchronized 代码块，也可以直接标记静态方法或者实例方法。

其中，对于互斥的概念来说，在数学范畴来讲，是一个数学名词，表示和描述的是事件A与事件B在任何一次试验中都不会同时发生，则称事件A与事件B互斥。

因此，对于互斥锁可以理解为：对于某一个锁来说，任意时刻只能有一个线程获得该锁，对于其他线程想获取锁的时候就得等待或者被阻塞。

1.使用方式

在Java领域中，synchronized关键字互斥锁主要有作用于对象方法上面，作用于类静态方法上面，作用于对象方法里面，作用于类静态方法里面等4种方式。

在Java领域中，synchronized关键字从使用方式来看，主要可以分为：

作用于对象方法上面：
- 描述对象的方法，表示该对象的方法具有同步性。由于描述的对象的方法，作用范围是在对象(Object)，整个对象充当了锁。
- 需要注意的是，类可以实例化多个对象，这时每一个对象都是一个锁，每个锁的范围相当于是当前对象来说的。
作用于类静态方法上面：
- 描述类的静态方法，表示该方法具有同步性。由于描述的类静态的方法，作用范围是在类(Class)，整个类充当了锁。
- 需要注意的是，某一个类的本身也是一个对象，JVM使用这个对象作为模板去生成该类的对象时，每个锁的范围相当于是当前类来说的。
作用于对象方法里面：
- 描述方法内部的某块逻辑，表示该代码块具有同步性。
- 需要注意的是，一般需要我们指定对象，比如synchronized(this){xxx}是指当前对象的，也可以创建一个对象来作为锁。
作用于类静态方法里面：
- 描述静态方法内部的某块逻辑，表示该代码块具有同步性。
- 需要注意的是，一般需要我们指定锁对象，比如synchronized(this){xxx}是指当前类class作为锁对象的，也可以创建一个对象来作为锁。

一般当我们在编写代码的过程中，如果按照上述方式声明时，被synchronized关键字声明的代码会比普通代码在编译之后，使用javap -c xxx.class 查看字节码，就会发现多两个monitorenter和monitorexit指令。

2.基本思想

在Java领域中，synchronized关键字互斥锁主要基于一个阻塞队列和等待对列，类似于一种“等待-通知”的工作机制来实现。

一般情况下，“等待 - 通知”的工作机制的要求是线程首先获取互斥锁，其中：

当线程要求的条件不满足时，释放互斥锁，进入等待状态。
当要求的条件满足时，通知等待的线程，重新获取互斥锁。

在Java领域中， Java 语言内置的 synchronized 配合java.lang.Object类定义的 wait()、notify()、notifyAll() 这三个方法就能轻松实现等待 - 通知机制，其中：

wait：表示持有对象锁的线程A准备释放对象锁权限，释放cpu资源并进入等待。
notify：表示持有对象锁的线程A准备释放对象锁权限，通知jvm唤醒某个竞争该对象锁的线程X。线程A synchronized 代码作用域结束后，线程X直接获得对象锁权限，其他竞争线程继续等待(即使线程X同步完毕，释放对象锁，其他竞争线程仍然等待，直至有新的notify ,notifyAll被调用)。
表示持有对象锁的线程A准备释放对象锁权限，通知jvm唤醒所有竞争该对象锁的线程，线程A synchronized 代码作用域结束后，jvm通过算法将对象锁权限指派给某个线程X，所有被唤醒的线程不再等待。线程X synchronized代码作用域结束后，之前所有被唤醒的线程都有可能获得该对象锁权限，这个由JVM算法决定。

一个线程一旦调用了任意对象的wait()方法，就会变为非运行状态，直到另一个线程调用了同一个对象的notify()方法。

为了调用wait()或者notify()，线程必须先获得那个对象的锁。也就是说，线程必须在同步块里调用wait()或者notify()。

对于等待队列的工作机制来说，同一时刻，只允许一个线程进入 synchronized 保护的临界区。当有一个线程进入临界区后，其他线程就只能进入图中左边的等待队列里等待。这个等待队列和互斥锁是一对一的关系，每个互斥锁都有自己独立的等待队列。在并发程序中，其中：

当一个线程进入临界区后，由于某些条件不满足，需要进入等待状态，Java 对象的 wait() 方法就能够满足这种需求。
当调用 wait() 方法后，当前线程就会被阻塞，并且进入到右边的等待队列中，这个等待队列也是互斥锁的等待队列。
线程在进入等待队列的同时，会释放持有的互斥锁，线程释放锁后，其他线程就有机会获得锁，并进入临界区了。

对于通知队列的工作机制来说，那线程要求的条件满足时，该怎么通知这个等待的线程呢？很简单，就是 Java 对象的 notify() 和 notifyAll() 方法。当条件满足时调用 notify()，会通知等待队列（互斥锁的等待队列）中的线程，告诉它条件曾经满足过。为什么说是曾经满足过呢？其中：

因为 notify() 只能保证在通知时间点，条件是满足的。
而被通知线程的执行时间点和通知的时间点基本上不会重合，所以当线程执行的时候，很可能条件已经不满足了（保不齐有其他线程插队）。
除此之外，还有一个需要注意的点，被通知的线程要想重新执行，仍然需要获取到互斥锁（因为曾经获取的锁在调用 wait() 时已经释放了）。

上面我们一直强调 wait()、notify()、notifyAll() 方法操作的等待队列是互斥锁的等待队列，其中：

如果 synchronized 锁定的是 this，那么对应的一定是 this.wait()、this.notify()、this.notifyAll()；
如果 synchronized 锁定的是 target，那么对应的一定是 target.wait()、target.notify()、target.notifyAll() 。

而且 wait()、notify()、notifyAll() 这三个方法能够被调用的前提是已经获取了相应的互斥锁，所以我们会发现 wait()、notify()、notifyAll() 都是在 synchronized{}内部被调用的。

如果在 synchronized{}外部调用，或者锁定的 this，而用 target.wait() 调用的话，JVM 会抛出一个运行时异常：java.lang.IllegalMonitorStateException。

对于和notifyAll() 和notify()来实现通知机制，特别需要注意的是，两者之间的区别：

notify()方法：随机地通知等待队列中的一个线程。
notifyAll()方法：通知等待队列中的所有线程。

从感觉上来讲，应该是 notify() 更好一些，因为即便通知所有线程，也只有一个线程能够进入临界区。但是实际上使用 notify() 也很有风险，主要在于可能导致某些线程永远不会被通知到。

在具体使用过程中，所以除非经过深思熟虑，一般推荐尽量使用 notifyAll()。

3.基本实现

在Java领域中，synchronized关键字互斥锁主要基于Java HotSpot™ VM 虚拟机通过Monitor(监视器)来实现monitorenter和monitorexit指令的。

在Java HotSpot™ VM 虚拟机中，主要是通过Monitor(监视器)来实现monitorenter和monitorexit指令的，Monitor(监视器）一般包括一个阻塞队列和一个等待队列，其中：

阻塞队列 : 用来保存锁竞争失败的线程，它们处于阻塞状态。
等待队列：用来保持synchronized关键字块中的调用 wait()方法后放置的队列。

其中，需要注意的是，当调用 wait()方法后会释放锁并通知阻塞队列。

一般来说，当Java字节码(class)被托管到Java HotSpot™ VM 虚拟机后，Monitor(监视器)就被采用ObjectMonitor接管，其中：

每⼀个对象都有⼀个属于⾃⼰的monitor，其次如果线程未获取到singal (许可)，则线程阻塞。
monitor相当于⼀个对象的钥匙，只有拿到此对象的monitor，才能访问该对象的同步代码。相反未获得monitor的只能阻塞来等待持有monitor的线程释放monitor。

对于monitorenter指令来说，其中：

⼀个对象都会和⼀个监视器monitor关联。监视器被占⽤时会被锁住，其他线程⽆法来获取该monitor。当JVM执⾏某个线程的某个⽅法内部的monitorenter时，它会尝试去获取当前对象对应的monitor的所有权。
synchronized的锁对象会关联⼀个monitor，这个monitor不是我们主动创建的，是JVM的线程执⾏到这个同步代码块，发现锁对象没有monitor就会创建monitor，monitor内部有两个重要的成员变量owner：拥有这把锁的线程，recursions会记录线程拥有锁的次数，当⼀个线程拥有monitor后其他线程只能等待。

主要工作流程如下：

若monior的进⼊数为0，线程可以进⼊monitor，进入后将monitor的进数置为1。当前线程成为monitor的owner(所有者) 。
若线程已拥有monitor的所有权，允许它重⼊monitor，则进⼊monitor的进⼊数再加1。
若其他线程已经占有monitor的所有权，那么当前尝试获取monitor的所有权的线程会被阻塞。直到monitor的进⼊数变为0，才能重新尝试获取monitor的所有权。

对于monitorexit指令来说，其中：

能执⾏monitorexit指令的线程，⼀定是拥有当前对象的monitor的所有权的线程。
执⾏monitorexit时会将monitor的进⼊数减1。当monitor的进⼊数减为0时，当前线程退出monitor，不再拥有monitor的所有权，此时其他被这个monitor阻塞的线程可以尝试去获取这个monitor的所有权。

主要工作流程如下：

monitorexit，指令出现了两次，第1次为同步正常退出释放锁；第2次为发生异常退出释放锁。
monitorexit释放锁monitorexit插⼊在⽅法结束处和异常处，JVM保证每个monitorenter必须有对应的monitorexit。

综上所述，monitorenter和monitorexit两个指令的执行是JVM通过调用操作系统的互斥原语mutex来实现。被阻塞的线程会被挂起、等待重新调度，会导致"用户态和内核态"两个态之间来回切换，对性能有较大影响。

4.具体实现

在Java领域中，JVM中每个对象都会有一个监视器，监视器和对象一起创建、销毁。监视器相当于一个用来监视这些线程进入的特殊房间，其义务是保证（同一时间）只有一个线程可以访问被保护的临界区代码块。

本质上，监视器是一种同步工具，也可以说是一种同步机制，主要特点是：

同步：监视器所保护的临界区代码是互斥地执行的。一个监视器是一个运行许可，任一线程进入临界区代码都需要获得这个许可，离开时把许可归还。
协作：监视器提供Signal机制，允许正持有许可的线程暂时放弃许可进入阻塞等待状态，等待其他线程发送Signal去唤醒；其他拥有许可的线程可以发送Signal，唤醒正在阻塞等待的线程，让它可以重新获得许可并启动执行。

在Hotspot虚拟机中，监视器是由C++类ObjectMonitor实现的，ObjectMonitor类定义在ObjectMonitor.hpp文件中，ObjectMonitor的Owner（_owner）、WaitSet（_WaitSet）、Cxq（_cxq）、EntryList（_EntryList）这几个属性比较关键。

ObjectMonitor的WaitSet、Cxq、EntryList这三个队列存放抢夺重量级锁的线程，而ObjectMonitor的Owner所指向的线程即为获得锁的线程。其中：

Cxq：竞争队列（Contention Queue），所有请求锁的线程首先被放在这个竞争队列中
EntryList：Cxq中那些有资格成为候选资源的线程被移动到EntryList中。
WaitSet：某个拥有ObjectMonitor的线程在调用Object.wait()方法之后将被阻塞，然后该线程将被放置在WaitSet链表中。

Cxq并不是一个真正的队列，只是一个虚拟队列，原因在于Cxq是由Node及其next指针逻辑构成的，并不存在一个队列的数据结构。每次新加入Node会在Cxq的队头进行，通过CAS改变第一个节点的指针为新增节点，同时设置新增节点的next指向后续节点；从Cxq取得元素时，会从队尾获取。显然，Cxq结构是一个无锁结构。
在线程进入Cxq前，抢锁线程会先尝试通过CAS自旋获取锁，如果获取不到，就进入Cxq队列，这明显对于已经进入Cxq队列的线程是不公平的。所以，synchronized同步块所使用的重量级锁是不公平锁。

EntryList与Cxq在逻辑上都属于等待队列。Cxq会被线程并发访问，为了降低对Cxq队尾的争用，而建立EntryList。在Owner线程释放锁时，JVM会从Cxq中迁移线程到EntryList，并会指定EntryList中的某个线程（一般为Head）为OnDeck Thread（Ready Thread）。EntryList中的线程作为候选竞争线程而存在。

JVM不直接把锁传递给Owner Thread，而是把锁竞争的权利交给OnDeck Thread，OnDeck需要重新竞争锁。这样虽然牺牲了一些公平性，但是能极大地提升系统的吞吐量，在JVM中，也把这种选择行为称为“竞争切换”。
OnDeck Thread获取到锁资源后会变为Owner Thread。无法获得锁的OnDeck Thread则会依然留在EntryList中，考虑到公平性，OnDeck Thread在EntryList中的位置不发生变化（依然在队头）。
在OnDeck Thread成为Owner的过程中，还有一个不公平的事情，就是后来的新抢锁线程可能直接通过CAS自旋成为Owner而抢到锁。

如果Owner线程被Object.wait()方法阻塞，就转移到WaitSet队列中，直到某个时刻通过Object.notify()或者Object.notifyAll()唤醒，该线程就会重新进入EntryList中。

处于ContentionList、EntryList、WaitSet中的线程都处于阻塞状态，线程的阻塞或者唤醒都需要操作系统来帮忙，Linux内核下采用pthread_mutex_lock系统调用实现，进程需要从用户态切换到内核态。

5.基本分类

在Java领域中，synchronized关键字互斥锁主要中内置锁一共有4种状态：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这些状态随着竞争情况逐渐升级。

在Java领域中，一般Java对象（Object实例）结构包括三部分：对象头、对象体和对齐字节，其中：

对象头(Object Header) ：对象头包括三个字段,主要是作Mark Word（标记字段）、Klass Pointer（类型指针）以及Array Length（数组长度）等。
对象体(Object Data) ：包含对象的实例变量（成员变量），用于成员属性值，包括父类的成员属性值。这部分内存按4字节对齐。
对齐字节(Padding): 也叫作填充对齐，其作用是用来保证Java对象所占内存字节数为8的倍数HotSpot VM的内存管理要求对象起始地址必须是8字节的整数倍。

一般地，对象头本身是8的倍数，当对象的实例变量数据不是8的倍数时，便需要填充数据来保证8字节的对齐。

上面在悲观锁和乐观锁分类时候，提到synchronized是悲观锁，以Hotspot虚拟机为例，在操作同步资源之前需要给同步资源先加锁，这把锁就是存在Java对象头里，其中：

Mark Word（标记字段)：默认存储对象的HashCode，分代年龄和锁标志位信息。这些信息都是与对象自身定义无关的数据，所以Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据。它会根据对象的状态复用自己的存储空间，也就是说在运行期间Mark Word里存储的数据会随着锁标志位的变化而变化。
Klass Pointer（类型指针）：对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例。

而对于synchronized来说，synchronized通过Monitor来实现线程同步，Monitor是依赖于底层的操作系统的Mutex Lock（互斥锁）来实现的线程同步，主要是通过JVM中Monitor监视器来实现monitorenter和monitorexit指令的，而Monitor可以理解为一个同步工具或一种同步机制，通常被描述为一个对象。每一个Java对象就有一把看不见的锁，称为内部锁或者Monitor锁。

Monitor是线程私有的数据结构，每一个线程都有一个可用monitor record列表，同时还有一个全局的可用列表。每一个被锁住的对象都会和一个monitor关联，同时monitor中有一个Owner字段存放拥有该锁的线程的唯一标识，表示该锁被这个线程占用。

在JDK 1.6版本之前，所有的Java内置锁都是重量级锁。重量级锁会造成CPU在用户态和核心态之间频繁切换，所以代价高、效率低。

JDK 1.6版本为了减少获得锁和释放锁所带来的性能消耗，引入了偏向锁和轻量级锁的实现。

在JDK 1.6版本中内置锁一共有4种状态：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这些状态随着竞争情况逐渐升级。其中：

无锁状态：Java对象刚创建时还没有任何线程来竞争，说明该对象处于无锁状态（无线程竞争它），这时偏向锁标识位是0，锁状态是01。
偏向锁状态：指一段同步代码一直被同一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。如果内置锁处于偏向状态，当有一个线程来竞争锁时，先用偏向锁，表示内置锁偏爱这个线程，这个线程要执行该锁关联的同步代码时，不需要再做任何检查和切换。偏向锁在竞争不激烈的情况下效率非常高。
轻量级锁状态：当有两个线程开始竞争这个锁对象时，情况就发生变化了，不再是偏向（独占）锁了，锁会升级为轻量级锁，两个线程公平竞争，哪个线程先占有锁对象，锁对象的Mark Word就指向哪个线程的栈帧中的锁记录。
重量级锁状态：重量级锁会让其他申请的线程之间进入阻塞，性能降低。重量级锁也叫同步锁，这个锁对象Mark Word再次发生变化，会指向一个监视器对象，该监视器对象用集合的形式来登记和管理排队的线程。

因此，根据上述的锁状态来看，我们可以把Java内置锁分为无锁，偏向锁，轻量级锁和重量级锁等4种锁，其中：

无锁：表示Java对象实例刚创建，还没有锁参与竞争。即就是没有对资源进行锁定，所有的线程都能访问并修改同一个资源，但同时只有一个线程能修改成功。
偏向锁：偏向锁主要解决无竞争下的锁性能问题，所谓的偏向就是偏心，即锁会偏向于当前已经占有锁的线程。指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁，降低获取锁的代价。
轻量级锁：轻量级锁主要有两种：普通自旋锁和自适应自旋锁。当锁是偏向锁的时候，被另外的线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，从而提高性能。由于JVM轻量级锁使用CAS进行自旋抢锁，这些CAS操作都处于用户态下，进程不存在用户态和内核态之间的运行切换，JVM轻量级锁开销较小。
重量级锁： JVM重量级锁使用了Linux内核态下的互斥锁，升级为重量级锁时，等待锁的线程都会进入阻塞状态，其开销较大。

从锁升级的状态顺序来看，只能是: 无锁->偏向锁->轻量级锁->重量级锁 ,而且顺序不可逆，也就是不能降级。

综上所述，在Java内置锁中，偏向锁通过对比Mark Word解决加锁问题，避免执行CAS操作。而轻量级锁是通过用CAS操作和自旋来解决加锁问题，避免线程阻塞和唤醒而影响性能。重量级锁是将除了拥有锁的线程以外的线程都阻塞。

6.应用分析

在Java领域中，synchronized关键字互斥锁主要中内置锁使用简单，但是锁的粒度比较大，无法支持超时等。

从synchronized的执行过程，大致如下：

线程抢锁时，JVM首先检测内置锁对象Mark Word中的biased_lock（偏向锁标识）是否设置成1，lock（锁标志位）是否为01，如果都满足，确认内置锁对象为可偏向状态。
在内置锁对象确认为可偏向状态之后，JVM检查Mark Word中的线程ID是否为抢锁线程ID，如果是，就表示抢锁线程处于偏向锁状态，抢锁线程快速获得锁，开始执行临界区代码。
如果Mark Word中的线程ID并未指向抢锁线程，就通过CAS操作竞争锁。如果竞争成功，就将Mark Word中的线程ID设置为抢锁线程，偏向标志位设置为1，锁标志位设置为01，然后执行临界区代码，此时内置锁对象处于偏向锁状态。
如果CAS操作竞争失败，就说明发生了竞争，撤销偏向锁，进而升级为轻量级锁
JVM使用CAS将锁对象的Mark Word替换为抢锁线程的锁记录指针，如果成功，抢锁线程就获得锁。如果替换失败，就表示其他线程竞争锁，JVM尝试使用CAS自旋替换抢锁线程的锁记录指针，如果自旋成功（抢锁成功），那么锁对象依然处于轻量级锁状态。
如果JVM的CAS替换锁记录指针自旋失败，轻量级锁就膨胀为重量级锁，后面等待锁的线程也要进入阻塞状态。

总体来说，偏向锁是在没有发生锁争用的情况下使用的；一旦有了第二个线程争用锁，偏向锁就会升级为轻量级锁；如果锁争用很激烈，轻量级锁的CAS自旋到达阈值后，轻量级锁就会升级为重量级锁。

四.Java显式锁

在Java领域中，Java显式锁主要是指基于JDK层面实现的锁。

在Java领域中，基于JDK层面实现的锁都存在于java.util.concurrent.locks包下面，大致可以分为：

基于Lock接口实现的锁
基于ReadWriteLock接口实现的锁
基于AQS基础同步器实现的锁
基于自定义API操作实现的锁

一直以来，并发编程领域，有两大核心问题：一个是互斥，即同一时刻只允许一个线程访问共享资源；另一个是同步，即线程之间如何通信、协作等。

Java SDK 并发包通过 Lock 和 Condition 两个接口来实现管程，其中 Lock 用于解决互斥问题，Condition 用于解决同步问题。