死磕Java并发？首先需要学习的并发机制底层实现的三个原理

淡淡的烟草味﹌ 2023-07-21 08:34 26阅读 0赞

## 开篇 ##

> 说到并发编程，相信很多人和我一样，对于“并发编程” 这个名词，一下就想到了多线程程序。紧接着又会想到涉及到锁的相关知识、线程池等一些知识片段。 但是对于这些知识的底层原理或者说JDK提供给我们的并发包下面的工具类，都是没怎么接触过的。

这就导致一些问题，比如JDK随着版本的升级已经提供了很多应付高并发场景的工具类，而我们还只是会用synchnorized加锁，hashtable这种同步容器等。 之所以我们不敢用新的工具类，比如说 Lock 和 ConCurrentHashMap 这些并发包下提供的性能更好更灵活的工具类，主要原因在于我们不清楚他们的实现原理怕用不好，导致业务生产问题。一口大锅就盖下来。。。

痛定思痛，这次一定要系统的学习Java并发编程，不仅是为了能够落地到工作项目中，得到领导欣赏和同事钦佩的目光，也为了以后出去面试不出现和面试官之间的尴尬，你懂得。。。

今天开始学习的第一天分享。 作为码农，我们一定要多写多练多分享，写错了也没关系嘛，毕竟你也没吃他家饭。 被别的同学指出错误，一起探讨，也是自己快速进步的不二法门。

好了，不啰嗦了。。开始学习吧！！！

--------------------

## Java并发编程的基底层实现 ##

作为开篇，首先学习下，Java整个并发编程的的本质，也就是它的底层实现原理。 后面所有的并发容器也好、锁也好、线程池等都是基于此实现的。 万变不离其宗嘛，先学会了基础实现，后面的在慢慢啃，也有助于我们学习过程中发散思维，举一反三。

在学习Java多线程时，我们肯定都用过 **synchnorized** 和 **volatile** 。没错这两个东西在我们Java并发编程中占据着半壁江山。

有这样一句话，一切并发问题的根源都是由 可见性、原子性、有序性导致的。这里volatile 就是为了解决在多处理器开发中解决共享变量的 **可见性** 问题的。

### 探究volatile的前世今生 ###

Java语言规范中对 volatile的定义如下：

> Java编程语言允许线程访问共享变量，为了确保共享变量能被准确和一致地更新，线程应该确保通过排他锁单独获得这个变量。Java语言提供了volatile，在某些情况下比锁要更加方便。如果一个字段被声明成volatile，Java线程内存模型确保所有线程看到这个变量的值是一致的。

这句话该怎么理解呢？ 别急，为了更好的理解这个概念，我们需要先来学习下与之相关的 CPU 概念。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw_size_16_color_FFFFFF_t_70][]

volatile是如何来保证可见性的呢？ 当对volatile变量进行写操作时，jvm在多核处理器下会做两件事：

1.  将当前处理器缓存行的数据写回到系统内存
2.  这个写回内存的操作会使在其他CPU里缓存了该内存地址的数据无效

为了弥补越来越快的CPU 与 内存 之间的速度差距，CPU引入了多级缓存（L1，L2，L3或其他）。也就是说处理器是不直接与内存交互的，而是先将系统内存中的数据读到 CPU缓存后再进行操作，但是操作何时写到内存时不确定的。 这个时候就展现出 volatile 的强大了，JVM 实现了 当对 volatile 变量进行写操作时，**JVM会向处理器发送一条Lock前缀的指令，将这个变量所在的CPU缓存行数据写到内存**。

经过上面的步骤，虽然每次对 volatile 的写操作会立即写到内存，但是好像还缺了点什么？ 喜欢思考的你发现了？

是的，就算上面的步骤已经学会到主存，但是其他处理的缓存行还是旧的呀，依然会出并发的bug。 所以在多处理器下，为了保证各个处理器的缓存是一致的，就实现了**缓存的一致性性协议**。每个处理器通过嗅探在总线上传播的数据来检查自己的缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改时，就会将当前处理器的缓存的缓存行设置为无效。

这样就实现了 volatile 修饰的变量，在写操作时保证多处理器下的数据可见性。

### synchnorized的原理与应用 ###

synchnorized 是jdk1.5之前提供的唯一锁机制了。作为元老，你可能会称之为重量级锁，性能很差等等。其实在jdk1.6 对 synchnorized 做了各种优化之后，某些场景下已经不差了，也就是说性能不能在成为广受诟病的槽点了。 **jdk1.6 为了减少获取锁和释放锁带来的性能消耗而引入了偏向锁、轻量级锁以及锁的存储结构和升级过程。**

先来看下利用synchronized实现同步的基础：Java中的每一个对象都可以作为锁。具体表现为以下3种形式。

*  ·对于普通同步方法，锁是当前实例对象
 *  对于静态同步方法，锁是当前类的Class对象
 *  ·对于同步方法块，锁是Synchonized括号里配置的对象

这里对用法就不多做介绍了，总结一句话：就是要访问同步代码块，首先获取锁，退出或抛出异常必须释放锁，获取和释放都是JVM帮我们做的，下面一起来看下实现。

从JVM规范中可以看到Synchonized在JVM里的实现原理，JVM基于进入和退出Monitor对象来实现方法同步和代码块同步。

monitorenter指令是在编译后插入到同步代码块的开始位置，而monitorexit是插入到方法结束处和异常处，JVM要保证每个monitorenter必须有对应的monitorexit与之配对。任何对象都有一个monitor与之关联，当且一个monitor被持有后，它将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor的所有权，即尝试获得对象的锁。

Java对象头

synchronized用的锁是存在Java对象头里的, 在64位虚拟机下，Mark Word是64bit大小的，其存储结构如下所示：

![20200403024724562.png][]

锁的升级与对比

> Java SE 1.6为了减少获得锁和释放锁带来的性能消耗，引入了“偏向锁”和“轻量级锁”，在Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。

偏向锁

> HotSpot的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：如果没有设置，则使用CAS竞争锁；如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程。

*  偏向锁撤销

> 偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。偏向锁的撤销，需要等待全局安全点（在这个时间点上没有正在执行的字节码）。它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将对象头设置成无锁状态；如果线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。下图线程1演示了偏向锁初始化的流程，线程2演示了偏向锁撤销的流程。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw_size_16_color_FFFFFF_t_70 1][]

ps：偏向锁在Java1.6 后 里是默认启用的，但是它在应用程序启动几秒钟之后才激活，如有必要可以使用JVM参数来关闭延迟：-XX:BiasedLockingStartupDelay=0。如果你确定应用程序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁：**-XX:-UseBiasedLocking=false**，那么程序默认会进入轻量级锁状态。

轻量级锁

*  轻量级锁加锁

接下来很重要，敲黑板哦，加锁的过程很奇妙：  
线程在执行同步代码块之前，JVM会先在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头中的Mark Work 复制到锁记录中。 接下来线程会尝试使用CAS操作将对象头中的Mark Word替换为指向锁记录的指针。 如果成功则获取锁，失败则表示被占用，自旋重试。

*  轻量级锁解锁

轻量级锁解锁时，会使用原子性的CAS操作将栈帧中的 Mark Word替换回到对象头，如果成功则表示没有竞争。失败则表示存在竞争，锁膨胀为重量级锁。

因为自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。

经过上面的学习，我们知道了JVM底层几种锁的实现，那么锁能解决同步问题，必然会引入新的问题，那就是性能问题。 **下面总结了几种锁的优缺点**：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw_size_16_color_FFFFFF_t_70 2][]

### 原子操作 ###

原子操作，听到这个概念你肯定会想到我们常说的原子性。是的，就是说一个操作的执行是不可打断的。现代处理器保证了在多核处理器中内存操作的原子性。

处理器保证从系统内存中读取或者写入一个字节是原子的，意思是当一个处理器读取一个字节时，其他处理器不能访问这个字节的内存地址，处理器使用基于对缓存加锁或总线加锁的方式来实现多处理器之间的原子操作。

**1. 使用总线锁保证原子性**

如果多个处理器同时对共享变量进行读改写操作（i++就是经典的读改写操作），那么共享变量就会被多个处理器同时进行操作，这样读改写操作就不是原子的，操作完之后共享变量的值会和期望的不一致。举个例子，如果i=1，我们进行两次i++操作，我们期望的结果是3，但是有可能结果是2。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw_size_16_color_FFFFFF_t_70 3][]

原因参考上图，当多个处理器同时从各自的缓存里读取到i，进行加一操作，然后分别写入到内存。

所以想要保证原子性，就必须当一个处理器在读写共享变量时，另一个处理器不能操作缓存了该共享变量内存地址的缓存。

> **处理器使用总线锁就是来解决这个问题的。所谓总线锁就是使用处理器提供的一个LOCK＃信号，当一个处理器在总线上输出此信号时，其他处理器的请求将被阻塞住，那么该处理器可以独占共享内存。**

通过对总线锁的学习，你肯定会问，使用总线锁后，同一时刻只有一个处理器可以访问共享内存，岂不是很浪费资源，其他处理器都得歇着，而我们仅仅只需要保证某一个共享变量的原子性，这是杀鸡用了牛刀呀！！！

别急，我们能想到的事情，现在处理器肯定都已经解决了。。。 接着往下看吧

**2. 使用缓存锁保证原子性**

这种方案，我们只需要同一时刻对某个内存地址的操作原子性即可。

> “缓存锁定”是指内存区域如果被缓存在处理器的缓存行中，并且在Lock操作期间被锁定，那么当它执行锁操作回写到内存时，处理器不在总线上声言LOCK＃信号，而是修改内部的内存地址，并允许它的缓存一致性机制来保证操作的原子性，因为缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据，当其他处理器回写已被锁定的缓存行的数据时，会使缓存行无效。

Java如何实现原子操作

在Java中可以通过锁和循环CAS的方式来实现原子操作。

使用循环CAS实现原子操作

JVM中的CAS操作正是利用了处理器提供的CMPXCHG指令实现的。自旋CAS实现的基本  
思路就是循环进行CAS操作直到成功为止。

**CAS实现原子操作的三大问题**：

1.  ABA问题
2.  循环时间长开销大
3.  只能保证一个共享变量的原子操作

使用锁机制实现原子操作

锁机制保证了只有获得锁的线程才能够操作锁定的内存区域。JVM内部实现了很多种锁机制，有偏向锁、轻量级锁和互斥锁。有意思的是除了偏向锁，JVM实现锁的方式都用了循环CAS，即当一个线程想进入同步块的时候使用循环CAS的方式来获取锁，当它退出同步块的时候使用循环CAS释放锁。

## 总结 ##

我们一起学习volatile、synchronized和原子操作的实现原理。Java中的大部分容器和框架都依赖于volatile和原子操作的实现原理，了解这些原理对我们进行并发编程会更有帮助

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw_size_16_color_FFFFFF_t_70]: /images/20230528/14462e45bd154cef861e41af9dc92203.png
[20200403024724562.png]: /images/20230528/f85aa704a90b45309d5b5c6c5580fe3f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw_size_16_color_FFFFFF_t_70 1]: /images/20230528/80b94c5a5d7c473fb8a12488e626d0e4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw_size_16_color_FFFFFF_t_70 2]: /images/20230528/4d2d1a050ac642d18f5ea4a7adc89957.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3RhdXJ1c183Yw_size_16_color_FFFFFF_t_70 3]: /images/20230528/e226e907dbf84ec284fa77609ba4f0cd.png