从 JVM 锁到 Redis 分布式锁，对小白十分友好，java 最新技术栈百度网盘

极客good

关注

发布于: 刚刚

如果不考虑原子性、内存屏障等晦涩的名词，加锁之所以能保证线程安全，核心就是“互斥”。所谓互斥，就是字面意思上的互相排斥。这里的“互相”是指谁呢？就是多线程之间！

怎么实现多线程之间的互斥呢？

引入“中间人”即可。

注意，这是个非常简单且伟大的思想。在编程世界中，通过引入“中介”最终解决问题的案例不胜枚举，包括但不限于 Spring、MQ。在码农之间，甚至流传着一句话：没有什么问题是引入中间层解决不了的。

而 JVM 锁其实就是线程和线程彼此的“中间人”，多个线程在操作加锁数据前都必须征求“中间人”的同意：

锁在这里扮演的角色其实就是守门员，是唯一的访问入口，所有的线程都要经过它的拷问。在 JDK 中，锁的实现机制最常见的就是两种，分别是两个派系：

synchronized 关键字
AQS

个人觉得 synchronized 关键字要比 AQS 难理解，但 AQS 的源码比较抽象。这里简要介绍一下 Java 对象内存结构和 synchronized 关键字的实现原理。

Java 对象内存结构

==========

要了解 synchronized 关键字，首先要知道 Java 对象的内存结构。强调一遍，是 Java 对象的内存结构。

它的存在仿佛向我们抛出一个疑问：如果有机会解剖一个 Java 对象，我们能看到什么？

右上图画了两个对象，只看其中一个即可。我们可以观察到，Java 对象内存结构大致分为几块：

Mark Word（锁相关）
元数据指针（class pointer，指向当前实例所属的类）
实例数据（instance data，我们平常看到的仅仅是这一块）
对齐（padding，和内存对齐有关）

如果此前没有了解过 Java 对象的内存结构，你可能会感到吃惊：天呐，我还以为 Java 对象就只有属性和方法！

是的，我们最熟悉实例数据这一块，而且以为只有这一块。也正是这个观念的限制，导致一部分初学者很难理解 synchronized。比如初学者经常会疑惑：

为什么任何对象都可以作为锁？
Object 对象锁和类锁有什么区别？
synchronized 修饰的普通方法使用的锁是什么？
synchronized 修饰的静态方法使用的锁是什么？

这一切的一切，其实都可以在 Java 对象内存结构中的 Mark Word 找到答案：

很多同学可能是第一次看到这幅图，会感到有点懵，没关系，我也很头大，都一样的。

Mark Word 包含的信息还是蛮多的，但这里我们只需要简单地把它理解为记录锁信息的标记即可。上图展示的是 32 位虚拟机下的 Java 对象内存，如果你仔细数一数，会发现全部 bit 加起来刚好是 32 位。64 位虚拟机下的结构大同小异，就不特别介绍。

Mark Word 从有限的 32bit 中划分出 2bit，专门用作锁标志位，通俗地讲就是标记当前锁的状态。

正因为每个 Java 对象都有 Mark Word，而 Mark Word 能标记锁状态（把自己当做锁），所以 Java 中任意对象都可以作为 synchronized 的锁：

synchronized(person){

}

synchronized(student){

}

复制代码

所谓的 this 锁就是当前对象，而 Class 锁就是当前对象所属类的 Class 对象，本质也是 Java 对象。synchronized 修饰的普通方法底层使用当前对象作为锁，synchronized 修饰的静态方法底层使用 Class 对象作为锁。

但如果要保证多个线程互斥，最基本的条件是它们使用同一把锁：

对同一份数据加两把不同的锁是没有意义的，

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

复制代码

实际开发时应该注意避免下面的写法：

synchronized(Person.class){

// 操作 count

}

synchronized(person){

// 操作 count

}

复制代码

或者

public synchronized void method1(){

// 操作 count

}

public static synchronized void method1(){

// 操作 count

}

复制代码

synchronized 与锁升级

================

大致介绍完 Java 对象内存结构后，我们再来解决一个新疑问：

为什么需要标记锁的状态呢？是否意味着 synchronized 锁有多种状态呢？

在 JDK 早期版本中，synchronized 关键字的实现是直接基于重量级锁的。只要我们在代码中使用了 synchronized，JVM 就会向操作系统申请锁资源（不论当前是否真的是多线程环境），而向操作系统申请锁是比较耗费资源的，其中涉及到用户态和内核态的切换等，总之就是比较费事，且性能不高。

JDK 为了解决 JVM 锁性能低下的问题，引入了 ReentrantLock，它基于 CAS+AQS，类似自旋锁。自旋的意思就是，在发生锁竞争的时候，未争取到锁的线程会在门外采取自旋的方式等待锁的释放，谁抢到谁执行。

自旋锁的好处是，不需要兴师动众地切换到内核态申请操作系统的重量级锁，在 JVM 层面即可实现自旋等待。但世界上并没有百利而无一害的灵丹妙药，CAS 自旋虽然避免了状态切换等复杂操作，却要耗费部分 CPU 资源，尤其当可预计上锁的时间较长且并发较高的情况下，会造成几百上千个线程同时自旋，极大增加 CPU 的负担。