RocketMQ是我们“家喻户晓”的消息中间件，本身是阿里开源、java语言实现的，它的官方文档对我们国人非常友好。除了基础的使用，对RocketMQ的源码以及实现原理的掌握是我们迈向高级开发必不可少的内容，此文是对RocketMQ深入了解的开篇之作，搭建一套自己的RocketMQ源码环境。



# RocketMQ

## 源码下载
到 [官方下载地址](https://rocketmq.apache.org/download/) 上找到需要下载的版本，此处我下载的是V5.1的版本，选择Source下载

![image.png](/static/img/e4248baa8c7d7c847b9f8796f199934c.image.webp)

这一步非常简单，将下载的压缩包解压到需要存放项目的目录上。

## Idea导入源码

从解压的目录中选择到源码包 rocketmq-all-5.1.0 -> 选中pom.xml -> open导入

![image.png](/static/img/52e4db8ee5babd225db0f04a39a70701.image.webp)

然后等待项目构建完成即可

![image.png](/static/img/396e8983c39fc2cd604ea06bd52eaed8.image.webp)

## NameServer的启动
由于是Java语言的实现，MQ的启动依赖JDK，需要JDK8以上的版本，查看当前系统JDK版本 `java -version`

![image.png](/static/img/f1f17388614dd516f912e23e870560a4.image.webp)

启动 namesrv 服务，找到 NameServerStartup 类，运行 main 方法

![image.png](/static/img/92e42e1f640515db7cd1ff0ca37d24e6.image.webp)

如果提示以下问题，不要慌，踩到坑就给他填上
![image.png](/static/img/920cc59a43351e7a14f050a2ad83f8c5.image.webp)

以上问题出现的原因是JDK版本太高了，JDK自带工具包没有匹配上的原因，切换为JDK8就解决了

![image.png](/static/img/5e8a385de54f8e0370a43bd6305186af.image.webp)

再次启动 NameServerStartup 类的 main 方法，提示了 `Please set the ROCKETMQ_HOME variable in your environment to match the location of the RocketMQ installation`

![image.png](/static/img/78c8ce3b17dde7ba47e19f77057a4f0f.image.webp)

这是因为需要在环境变量中查找 ROCKETMQ_HOME 为命名的 RocketMQ 的配置目录，在启动配置上指定对应的目录 `ROCKETMQ_HOME=./distribution` 即可

![image.png](/static/img/54cd083a1b7240aeeceeea0f8e0c5515.image.webp)

再次启动，提示 `The Name Server boot success. serializeType=JSON, address 0.0.0.0:9876` 即为启动成功

![image.png](/static/img/37a9c06f56b38777713df1182f35ed4b.image.webp)

## Broker的启动
启动 Broker 服务，先找到 broker 项目目录 BrokerStartup 类，运行 main 方法

![image.png](/static/img/a00dc50ebd816b60787b36802618b07b.image.webp)

同样的提示环境变量问题 `Please set the ROCKETMQ_HOME variable in your environment to match the location of the RocketMQ installation`

配置上与server一致，不同的是，Broker需要指定配置文件，在 Program arguments 中添加 `-c ./distribution/conf/broker.conf` 配置

![image.png](/static/img/8078204ba6f74b46435013132c9c286c.image.webp)

找到 `broker.conf` 配置文件，指定IP和添加server服务端地址
`brokerIP1=127.0.0.1 
namesrvAddr=127.0.0.1:9876`

![image.png](/static/img/e28f83dc4caea2cfd9ed167e27f85b28.image.webp)

再次启动 Broker，提示 `The broker[broker-a, 127.0.0.1:10911] boot success. serializeType=JSON and name server is 127.0.0.1:9876` 即为启动成功

![image.png](/static/img/8cf54ce6aa74f2f682cf2f18a490a6b1.image.webp)

你以为这就结束了吗？no no no，服务虽然启动了，也可以正常连接使用，但是我们还缺少了一个至关重要的组件，那就是 dashboard

## dashboard的启动
dashboard 的源码并不在上面下载的RocketMQ的源码当中，需要单独下载，下载地址 [dashboard](https://github.com/apache/rocketmq-dashboard/tree/rocketmq-dashboard-1.0.0)

![image.png](/static/img/7b02ca24d40ad1114bd3403b83655ca4.image.webp)

解压源码，Idea导入，编译使用JDK1.8，否则会出现一些Netty异常，此处不过多讲解，本身是SpringBoot项目，修改 application.properties 配置文件，指向本地启动的 NameServer 地址
```properties
rocketmq.config.namesrvAddr=localhost:9876
```
找到 App 类，运行 main 方法，启动成功，访问 http://localhost:8080/ 即可

![image.png](/static/img/7448e638f347c523f0370bade8224a31.image.webp)

查看控制台是否连接成功

![image.png](/static/img/6c789592785a21df8eb0d483da0dc36f.image.webp)

## 总结

总结一下，本文主要整理了RocketMQ源码部署的方式，可以更直观的观察消息发送与消费的执行流程。下一篇我会基于当前源码启动的服务，对功能特性进行总结，方便在开发中快捷开发。

RocketMQ 源码环境的构建

在[《JUC入门的知识体系梳理》](/post/5)中聊过volatile保证了变量的可见性与有序性，但是不保证变量的原子性，所以在并发下，volatile并不能保证变量的安全性，那怎么保证线程中变量的安全性呢？今天我们来聊下ThreadLocal，从源码的角度分析，看一看它是如何保证线程之间的变量安全的。



# ThreadLocal

## 什么是ThreadLocal

ThreadLocal意为线程本地变量，用于解决多线程并发时访问共享变量的问题

在JDK1.2中引入了ThreadLocal类，来修饰共享变量，使每个线程都单独拥有一份共享变量，这样就可以做到线程之间对于共享变量的隔离问题

**此时回想一下JMM内存模型，再想一下volatile的实现原理，是不是存在一定的相似性呢？**

> volatile 它的实现原理是将变量的值刷新到主内存中，每次读取都从主内存中读取，而不是从线程的工作内存中读取。而ThreadLocal是将主内存的变量copy一份到线程的工作内存中，每次操作的都是线程内工作内存中的变量，天然的隔离性，不需要加锁，也不需要刷新到主内存中，保证了变量的安全性，那么它究竟是如何实现的呢？待会源码分析中揭晓。

## ThreadLocal的使用

ThreadLocal的使用非常简单，只需要创建一个ThreadLocal对象，调用set()、get()、remove()方法即可。

```java
ThreadLocal<String> threadLocal = new ThreadLocal<>();
threadLocal.set("hello");
threadLocal.get();
threadLocal.remove();
```

ThreadLocal创建对象的方式有2种:

- 第一种是直接new一个ThreadLocal对象
```java
ThreadLocal<String> threadLocal = new ThreadLocal<>();
```

- 第二种是使用ThreadLocal的静态方法withInitial()，传入一个Supplier接口的实现类，在没有调用set()方法的情况下，ThreadLocal的初始值就是Supplier #get()方法返回的值
```java
ThreadLocal<String> threadLocal = ThreadLocal.withInitial(() -> "init");
```

ThreadLocal在我们平时的开发中使用的场景并不是太多，大多常用在组件开发上，许多源码中也包含了ThreadLocal，比如Mybatis中的SqlSession，Spring中的TransactionSynchronizationManager等等。

**举个实际使用的栗子：**
```java
public class Demo {
 /**
 * ThreadLocal 线程变量，每个线程都有一个副本，互不干扰
 */
 public final static ThreadLocal<String> THREAD_LOCAL = new ThreadLocal<>();

 /**
 * 设置值
 * @param value 值
 */
 public static void set(String value) {
 THREAD_LOCAL.set(value);
 }

 /**
 * 测试new Thread()与main线程的ThreadLocal变量值
 */
 public static void main(String[] args) {
 String main = "Hello World!";
 new Thread(() -> {
 THREAD_LOCAL.set(main);
 System.out.println(Thread.currentThread().getName() + ":" + THREAD_LOCAL.get());
 THREAD_LOCAL.remove();
 }).start();
 System.out.println("main:" + THREAD_LOCAL.get());
 }
}

// 结果
main:null
Thread-0:Hello World!
```



## ThreadLocal的源码分析

ThreadLocal 是一个泛型类，泛型的类型即为存储的数据类型，从它的三个方法get()、set()、remove()开始分析

```java
public class ThreadLocal<T> {
 ...
 ThreadLocal.ThreadLocalMap threadLocals = null;
 
 public T get() {
 // 获取当前线程 - 联想到个线程都单独拥有一份共享变量，是不是通过当前线程来处理的呢？继续往下分析
 Thread t = Thread.currentThread();
 // 通过getMap()方法可以看出从当前线程中获取的ThreadLocalMap，此时猜测肯定这个对象存储了当前线程的共享变量
 ThreadLocalMap map = getMap(t);
 // map不为null，说明当前线程的ThreadLocalMap不为null
 if (map != null) {
 // 通过ThreadLocalMap的getEntry()方法获取当前ThreadLocal的Entry
 ThreadLocalMap.Entry e = map.getEntry(this);
 if (e != null) {
 // Entry 存储了变量的值，此处返回
 @SuppressWarnings("unchecked") 
 T result = (T)e.value;
 return result;
 }
 }
 // 设置初始化的值，猜测与ThreadLocal.withInitial()方法有关
 return setInitialValue();
 }

 ThreadLocalMap getMap(Thread t) {
 return t.threadLocals;
 }
 
 public void set(T value) {
 // 获取当前线程
 Thread t = Thread.currentThread();
 // 获取当前线程的ThreadLocalMap
 ThreadLocalMap map = getMap(t);
 // 如果ThreadLocalMap不为null，说明当前线程的ThreadLocalMap不为null
 if (map != null)
 // 将当前ThreadLocal作为key，value作为value存储到ThreadLocalMap中
 map.set(this, value);
 else
 // 如果ThreadLocalMap为null，说明当前线程的ThreadLocalMap为null，继续往下分析
 createMap(t, value);
 }
 
 void createMap(Thread t, T firstValue) {
 // 创建一个ThreadLocalMap，绑定到当前线程
 t.threadLocals = new ThreadLocalMap(this, firstValue);
 }
 ...
}
```

从上面的get/set源码中可以看出，当前的Thread中有一个ThreadLocalMap类型的成员变量threadLocals，在set的时候，如果有数据，用当前线程的ThreadLocalMap存储，如果没有数据，会指向一个新的new ThreadLocalMap()对象。

猜测此当前线程中的ThreadLocalMap变量就是实现线程隔离的关键，set的时候，实际的变量数据是添加到了当前的线程类中的ThreadLocalMap中存储，以下是Thread中的源码
```java
public class Thread implements Runnable {
 ...
 ThreadLocal.ThreadLocalMap threadLocals = null;
 ...
}
```

咦，在Thread源码中发现ThreadLocalMap居然是ThreadLocal的内部类，从之前的分析上，看名知意，这应该是个Map结构，那么ThreadLocalMap中存储结构是怎样呢？继续看源码
```java
static class ThreadLocalMap {
 ...
 // Entry 继承了弱引用 WeakReference，key 即为 ThreadLocal，value 为存储的数据
 static class Entry extends WeakReference<ThreadLocal<?>> {
 /** The value associated with this ThreadLocal. */
 Object value;
 
 // key 即为 ThreadLocal，value 为存储的数据
 Entry(ThreadLocal<?> k, Object v) {
 // 指定k变量也就是ThreadLocal为弱引用
 super(k);
 value = v;
 }
 ...
 }
 
 // Entry数组，用于存储数据
 private Entry[] table;
 
 private Entry getEntry(ThreadLocal<?> key) {
 // 计算key的hash值
 int i = key.threadLocalHashCode & (table.length - 1);
 // 通过hash计算的值定位取出数组中的Entry
 Entry e = table[i];
 if (e != null && e.get() == key)
 return e;
 else
 return getEntryAfterMiss(key, i, e);
 }
 ...
}
```

以上源码可以观察到ThreadLocalMap类中存储的是一个Entry数组，Entry是ThreadLocal的内部类，Entry继承了弱引用 `WeakReference`，key即为 `ThreadLocal`，value为线程存储的数据

:::tip{title="为什么一个线程可以绑定多个ThreadLocal呢？"}
Thread中存在一个ThreadLocalMap属性，ThreadLocalMap 本身就是基于 Entry[] 实现存储数据的，其中 ThreadLocal 作为key，ThreadLocal的值作为value，这种数据结构就是一个线程可以绑定多个ThreadLocal的原因

回想到set方法，直接是将值set到了当前Thread中的ThreadLocalMap中，线程与线程之间的变量都存储在自己当前线程中，保证了并发下变量的安全性，这也是隔离性实现的原理
:::

那么什么是引用呢？接下来我们聊下什么是引用，然后再来继续分析源码

## “强软弱虚”引用

看过JVM虚拟机的小伙伴都了解，在垃圾回收机制中，判断对象是否被回收的标准就是是判断对象是否引用链可达，而判断标准主要分为4种引用，分别是 **强、软、弱、虚**


### 什么是一个引用

`Object o = new Object()` 这就是一个引用了，一个变量指向new出来的对象，这就叫以个引用。当我们new出来一个象，在java语言里是不需要手动回收的，C和C++是需要的，在这种情况下，java的垃圾回收机制会自动的帮你回收这个对象。

再开始之前我们需要重写了一个方法叫 `finalize()`，在垃圾回收的过程中，各种引用它不同的表现，垃圾回收的时候，它是会调用finalize()，通过重写这个方法之后我们能观察到，它什么时候被垃圾回收了，什么时候被调用了。

```java
public class M {
 @Override
 protected void finalize() throws Throwable {
 System.out.println("finalize");
 }
}
```

:::warning{title="平常的工作中需要重写 finalize() 吗"}
这个方法为了让我们去观察结果用的，并不是说以后在什么情况下需要重写这个方法。可以在以后面试时遇到相关问题，可以进行阐述，让面试官了解到你造火箭的能力。
:::


### 强引用（Strongly Reference）

是最传统的“引用”的定义，是指在程序代码之中普遍存在的引用赋值，即类似“Object obj=new Object()”这种引用关系。无论任何情况下，**只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象**

### 软引用（Soft Reference）
 
软引用是用来描述一些还有用，但非必须的对象。**只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收，如果这次回收还没有足够的内存，才会抛出内存溢出异常**。 在JDK 1.2版之后提供了SoftReference类来实现软引用。
 
### 弱引用（Weak Reference）

弱引用也是用来描述那些非必须对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。**当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象**。 在JDK 1.2版之后提供了WeakReference类来实现弱引用

### 虚引用（Phantom Reference）

虚引用也称为“幽灵引用”或者“幻影引用”，它是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。**为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知**。在JDK1.2版之后提供了PhantomReference类来实现虚引用


## 弱引用的问题


强软弱虚引用我们已经了解清楚了，那**此时回想一下，弱引用的特点是什么？结合我们的 ThreadLocal 源码，如果此时 ThreadLocalMap中的 key -> 也就是ThreadLocal对象被回收了，会怎么样？**


![image.png](https://blog.liushigong.cn/static/img/4b8fb3e45dc92b497e54e329a6b70c6b.image.webp)

此处就会引发了一个致命问题，如果ThreadLocal被回收了，那么ThreadLocalMap中的Entry的key就为null，那么value就无法获取了，但此时Entry对象还是存在的，这样就导致了内存泄漏

所以ThreadLocalMap中的Entry需要被回收，那么ThreadLocalMap中的Entry是如何被回收的呢？继续看源码

```java
// ThreadLocal #remove()
public void remove() {
 ThreadLocalMap m = getMap(Thread.currentThread());
 if (m != null)
 m.remove(this);
}

// ThreadLocalMap #remove()
private void remove(ThreadLocal<?> key) {
 Entry[] tab = table;
 int len = tab.length;
 int i = key.threadLocalHashCode & (len-1);
 for (Entry e = tab[i];
 e != null;
 e = tab[i = nextIndex(i, len)]) {
 if (e.get() == key) {
 // 调用 Reference #clear() 方法，清除弱引用
 e.clear();
 // 清除数组中的Entry
 expungeStaleEntry(i);
 return;
 }
 }
}

// ThreadLocalMap #expungeStaleEntry()
private int expungeStaleEntry(int staleSlot) {
 Entry[] tab = table;
 int len = tab.length;
 
 // 将Entry中的value值设置为null，将Entry对象设为null，方便GC回收
 // expunge entry at staleSlot
 tab[staleSlot].value = null;
 tab[staleSlot] = null;
 size--;
 
 // Rehash until we encounter null
 Entry e;
 int i;
 for (i = nextIndex(staleSlot, len);
 (e = tab[i]) != null;
 i = nextIndex(i, len)) {
 ThreadLocal<?> k = e.get();
 if (k == null) {
 e.value = null;
 tab[i] = null;
 size--;
 } else {
 int h = k.threadLocalHashCode & (len - 1);
 if (h != i) {
 tab[i] = null;
 
 // Unlike Knuth 6.4 Algorithm R, we must scan until
 // null because multiple entries could have been stale.
 while (tab[h] != null)
 h = nextIndex(h, len);
 tab[h] = e;
 }
 }
 }
 return i;
}


```

此时分析remove方法，从源码中可以看出，remove方法是通过当前线程获取ThreadLocalMap，然后调用ThreadLocalMap的remove方法

ThreadLocalMap #remove方法是通过key的hash值定位到数组中的Entry，调用 Reference #clear 清除引用

然后调用expungeStaleEntry方法，将Entry中的value值设置为null，将Entry对象设为null，方便GC回收

此时就完美解决了ThreadLocal内存泄漏的问题，这也是为什么我们在使用了ThreadLocal之后，必须调用remove方法的原因，**属于强制性的操作，可千万别埋坑啊。**

对于其他源码中的方法，就不一一分析了，有兴趣的小伙伴可以自行研究，比如hash计算的方法等，这里只是分析了ThreadLocal实现原理，以及存在的内存泄漏问题、解决方案的核心源码。

## 总结

总结一下，开篇聊了 ThreadLocal 是什么以及使用，通过源码分析了它是怎么做到线程的隔离，本质就是每个Thread中都有一份 ThreadLocal.ThreadLocalMap 的属性，key为ThreadLocal，value是变量值，通过ThreadLocal #get() 方法，拿 ThreadLocal 当前的this对象从Thread中获取值。

接着从源码观察到 ThreadLocal 的内部类 ThreadLocalMap 中，它的实现子类Entry继承了弱引用WeakReference，根据弱引用的特点，分析其存在的内存泄漏的风险。又通过源码中remove方法了解到它是怎么解决内存泄漏的问题得。

在我们平时 ThreadLocal 的使用中，做到了知其然，知其所以然，才能更好的使用它。

并发编程 - ThreadLocal 详解与源码分析

JUC 基础知识汇总，了解并发编程的全貌



# JUC 基础知识总结

## 线程

### 线程状态
NEW：
> Thread对象被创建出来了，但是还没有执行start方法。

```java
public static void main(String[] args) throws InterruptedException {
 Thread t1 = new Thread(() -> {
 
 });
 System.out.println(t1.getState());
}
```

RUNNABLE：
> Thread对象调用了start方法，就为RUNNABLE状态（CPU调度/没有调度）

```java
public static void main(String[] args) throws InterruptedException {
 Thread t1 = new Thread(() -> {
 while(true){

 }
 });
 t1.start();
 Thread.sleep(500);
 System.out.println(t1.getState());
}
```

BLOCKED：
> synchronized没有拿到同步锁，被阻塞的情况

```java
public static void main(String[] args) throws InterruptedException {
 Object obj = new Object();
 Thread t1 = new Thread(() -> {
 // t1线程拿不到锁资源，导致变为BLOCKED状态
 synchronized (obj){

 }
 });
 // main线程拿到obj的锁资源
 synchronized (obj) {
 t1.start();
 Thread.sleep(500);
 System.out.println(t1.getState());
 }
}
```

WAITING：
> 调用wait方法就会处于WAITING状态，需要被手动唤醒

```java
public static void main(String[] args) throws InterruptedException {
 Object obj = new Object();
 Thread t1 = new Thread(() -> {
 synchronized (obj){
 try {
 obj.wait();
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 }
 });
 t1.start();
 Thread.sleep(500);
 System.out.println(t1.getState());
}
```

TIME_WAITING：
> 调用sleep方法或者join方法，会被自动唤醒，无需手动唤醒

```java
public static void main(String[] args) throws InterruptedException {
 Thread t1 = new Thread(() -> {
 try {
 Thread.sleep(1000);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 });
 t1.start();
 Thread.sleep(500);
 System.out.println(t1.getState());
}
```

BLOCKED、WAITING、TIME_WAITING：都可以理解为是阻塞、等待状态，因为处在这三种状态下，CPU不会调度当前线程

TERMINATED：
> run方法执行完毕，线程生命周期到头了

```java
public static void main(String[] args) throws InterruptedException {
 Thread t1 = new Thread(() -> {
 try {
 Thread.sleep(500);
 } catch (InterruptedException e) {
 e.printStackTrace();
 }
 });
 t1.start();
 Thread.sleep(1000);
 System.out.println(t1.getState());
}
```

### 线程方法

获取当前线程
```java
Thread thread = Thread.currentThread();
```

获取栈帧
```java
StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();

Map<Thread, StackTraceElement[]> allStackTraces = Thread.getAllStackTraces();
```

获取线程名称
```java
Thread.currentThread().getName();
```

设置线程调度优先级
> java中给线程设置的优先级别有10个级别，从1~10任取一个整数。
```java
Thread.currentThread().setPriority(1);
```

线程的让步
> 可以通过Thread的静态方法yield，让当前线程从运行状态转变为就绪状态。
```java
Thread.yield();
```

线程的等待和唤醒
> 可以让获取synchronized锁资源的线程通过wait方法进去到锁的等待池，并且会释放锁资源
> 
> 可以让获取synchronized锁资源的线程，通过notify或者notifyAll方法，将等待池中的线程唤醒，添加到锁池中
> 
> notify随机的唤醒等待池中的一个线程到锁池
> 
> notifyAll将等待池中的全部线程都唤醒，并且添加到锁池

在调用wait方法和notify以及norifyAll方法时，必须在synchronized修饰的代码块或者方法内部才可以，因为要操作基于某个对象的锁的信息维护。

```java
synchronized (MiTest.class) { 
 MiTest.class.wait();
 MiTest.class.notifyAll(); 
}
```

线程的结束方式
> interrupt方式

```java
public static void main(String[] args) throws InterruptedException {
 // 线程默认情况下， interrupt标记位：false
 System.out.println(Thread.currentThread().isInterrupted());
 // 执行interrupt之后，再次查看打断信息
 Thread.currentThread().interrupt();
 // interrupt标记位：ture
 System.out.println(Thread.currentThread().isInterrupted());
 // 返回当前线程，并归位为false interrupt标记位：ture
 System.out.println(Thread.interrupted());
 // 已经归位了
 System.out.println(Thread.interrupted());

 // =====================================================
 Thread t1 = new Thread(() -> {
 while(!Thread.currentThread().isInterrupted()){
 // 处理业务
 }
 System.out.println("t1结束");
 });
 t1.start();
 Thread.sleep(500);
 t1.interrupt();
}

```


## JMM
JMM (Java Memory Model) 即为Java内存模型

Java内存模型规定了所有的变量都存储在主内存中，每条线程都有自己的工作内存，线程的工作内存中保存了被该线程使用的变量的主内存副本，线程对该变量的所有读写操作都必须在工作内存中进行而不能直接读写主内存中的数据，不同的线程之间也无法访问对方工作内存中的变量，线程间变量值的传递都需要通过主内存来完成

### 特性：
原子性、可见性、有序性

### 内存间的交互

 1. lock：锁定
 > 作用于主内存的变量，它把一个变量标识为一条线程独占的状态

 2. unlock：解锁
 > 作用域主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。

 3. read：读取
 > 作用域主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用

 4. load：载入
 > 作用于工作内存的变量，它把read操作从主内存中得到的变量值放入到工作内存的变量副本中

 5. usr：使用
 > 作用于工作内存的变量，它把工作内存中的一个变量的值传给存储引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时会执行这个操作

 6. assign：赋值
 > 作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令执行这个操作

 7. store：存储
 > 作用于工作内存的变量，它把工作内存中的一个变量的值传送到主内存中，以便write操作使用

 8. write：写入
 > 作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中 



## volatile
是Java提供的一种轻量级的同步机制，用来确保将变量的更新操作通知到其他线程

### 特性：
可见性
> 通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值的方式实现可见性的

有序性
> 禁止指令重排序优化
> 通过内存屏障指令保证处理器不会乱序

### 问题：
### volatile 是怎么保证可见性的？

volatile 是通过 **MESI 缓存一致性协议** 来保证可见性的

首先 cpu 会根据共享变量是否带有 volatile 字段，来决定是否使用MESI协议保证缓存一致性。
如果有volatile，汇编层面会对变量加上Lock前缀，当一个线程修改变量的值后，会马上经过store、write等原子操作修改主内存的值（如果不加Lock前缀不会马上同步），为什么监听到修改会马上同步呢？就是为了触发cpu的嗅探机制，及时失效其他线程变量副本。

##### MESI 缓存一致性协议
> 
* M 修改 (Modified) 当一个线程要修改便令
* E 独享、互斥 (Exclusive) 当一个线程拿到了共享变量，此时为独享状态！
* S 共享 (Shared) 当多个线程都拿到了共享变量，此时为共享状态！
* I 无效 (Invalid) 线程丢弃了自己工作内存中的变量，为无效状态！

##### cpu总线嗅探机制
cpu总线嗅探机制监听到这个变量被修改，就会把其他线程的变量副本由共享S置为无效I，当其他线程在使用变量副本时，发现其已经无效，就回去主内存中拿一个最新的值。

##### Lock前缀的作用
使CPU缓存数据立即写会主内存（Volatile修饰的变量会带lock前缀）
触发总线嗅探机制和缓存一致性协议MESI来失效其他线程的变量

### volatile 是怎么保证有序性的？

> 被 volatile 修饰的变量存在一个 lock 前缀的指令，lock 前缀指令实际上相当于一个内存屏障
>
* 确保指令重排序时不会将其后面的代码排到内存屏障之前
* 确保指令重排序时不会将其前面的代码排到内存屏障之后
* 确保在执行到内存屏障修饰的指令时前面的代码全部执行完成
* 强制将线程工作内存中的值的修改刷新至主内存中
* 如果是写操作，则会导致其他线程工作内存中的缓存数据失效


## 本地线程 ThreadLocal

ThreadLocal意为线程本地变量，用于解决多线程并发时访问共享变量的问题。

在多线程的场景下，当有多个线程对共享变量进行修改的时候，就会出现线程安全问题，即数据不一致问题。常用的解决方法是对访问共享变量的代码加锁（synchronized或者Lock）。但是这种方式对性能的耗费比较大。

在JDK1.2中引入了ThreadLocal类，来修饰共享变量，使每个线程都单独拥有一份共享变量，这样就可以做到线程之间对于共享变量的隔离问题。

### 实现原理
- ThreadLocal 有一个内部类 ThreadLocalMap 
- ThreadLocalMap 是一个自定义的哈希映射，仅适用于维护线程本地值。
- ThreadLocalMap 的内部类 Entry 继承了弱引用 WeakReference
- 每个 Thread 中都存储着一个成员变量 ThreadLocal.ThreadLocalMap
- ThreadLocalMap 本身就是基于 Entry[] 实现的，因为一个线程可以绑定多个ThreadLocal，其中 ThreadLocal 作为key，存储的值为value。
- ThreadLocalMap 的key是一个弱引用，弱引用的特点是，即便有弱引用，在GC时，也必须被回收。这里是为了在ThreadLocal对象失去引用后，如果key的引用是强引用，会导致ThreadLocal对象无法被回收
```java
public class ThreadLocal<T> {
 ...
 
 static class ThreadLocalMap {
 static class Entry extends WeakReference<ThreadLocal<?>> {
 /** The value associated with this ThreadLocal. */
 Object value;

 Entry(ThreadLocal<?> k, Object v) {
 super(k);
 value = v;
 }
 }
 
 /**
 * The initial capacity -- MUST be a power of two.
 */
 private static final int INITIAL_CAPACITY = 16;

 /**
 * The table, resized as necessary.
 * table.length MUST always be a power of two.
 */
 private Entry[] table;
}
```

### ThreadLocal内存泄漏问题
在使用的过程中，如果key的引用丢失，也就是 ThreadLocal 的引用丢失后，key会因为弱引用被GC回收，在当前线程内部的 ThreadLocalMap 中，就没有key在指向的value，value无法被获取，更无法被回收，导致value的值一直占用内存，造成内存泄漏。

:::warning{title="解决"}
只需要在使用完毕ThreadLocal对象之后，及时的调用remove方法，移除Entry即可
:::

# 原子变量类

### 什么是CAS
CAS （Compare-and-Swap）就是比较并交换（本质是 `乐观锁` ）

CAS指令需要三个操作数，分别是变量的内存地址，用V表示，旧值用A表示，新值用B表示。CAS指令在执行时，当且当V符合A时，处理器才会用B更新V的值，否则就不更新。不管是否更新了V值，都会返回V的旧值，这个处理过程是一个原子操作，执行期间不会被其他线程中断

### 什么是ABA问题
如果变量V初次读取的变量值是A值，在这段期间它的值曾经被改为B值，后来又被改为A值，那么CAS操作会误认为它从来没有被改变过，这个问题被称为 `ABA` 问题

### 怎么解决ABA问题
解决办法是在每一个线程对变量进行赋值操作时加上版本号信息。
原子类中提供了 AtomicStampedReference 类
通过控制变量值的版本来保证CAS的正确性，可解决CAS的 `ABA` 问题

### 自旋时间过长问题
可以指定CAS自旋次数，如果超过次数，直接挂失败/挂起线程。（自旋锁、自适应自旋锁）
可以在CAS失败之后，把这个操作暂存起来，后面等待获取结果，将暂存的操作全部执行，再返回最后的结果


### 原子类
原子类基于CAS算法实现线程安全，无需加锁，性能高效。

原子操作类可分为五种类型：
基本数据类型原子类、数组类型原子类、引用类型原子类、对象的属性修改类型、高性能原子类

#### 基本数据类型原子类
> AtomicInteger、AtomicLong、AtomicBoolean

#### 数组类型原子类
> AtomicIntegerArray、AtomicLongArray、AtomicReferenceArray

#### 引用类型原子类
> AtomicReference、、AtomicReferenceArray、AtomicStampedReference

#### 基本数据类型原子类
> AtomicIntegerFieldUpdater、AtomicLongFieldUpdater、AtomicReferenceFieldUpdate

注意：对象的属性修改类型都是抽象类，所以在使用之前必须使用静态方法newUpdater创建一个新的更新器，然后参数传入需要更新的类和属性，属性名。同时待修改的属性必须用public volatile关键字修饰。

#### 高性能原子类
> DoubleAccumulator、DoubleAdder、LongAccumulator、LongAdder、Striped64

以LongAdder为例，引入的目的是解决高并发环境下AtomicLong的自旋瓶颈问题。
思想概述：采用分段的思想，将value值分散到一个数组中，不同线程会命中到数组的不同槽中，各个线程只对自己槽中的那个值进行CAS操作，最后再把这些段的值相加得到最终的值


# AbstractQueuedSynchronizer

## 队列同步器的原理分析

### 概述
队列同步器AbstractQueuedSynchronizer（以下简称同步器），是用来构建锁或者其他同步组件的基础框架，它使用了一个volatile int成员变量表示同步状态，通过内置的FIFO队列来完成资源获取线程的排队工作，它是大部分同步需求的基础。

同步器的设计是基于模板方法模式的，也就是说，使用者需要继承同步器并重写指定的 方法，随后将同步器组合在自定义同步组件的实现中，并调用同步器提供的模板方法，而这些 模板方法将会调用使用者重写的方法。

重写同步器指定的方法时，需要使用同步器提供的如下3个方法来访问或修改同步状态。 
>* getState()：获取当前同步状态。
>* setState(int newState)：设置当前同步状态。 
>* compareAndSetState(int expect,int update)：使用CAS设置当前状态，该方法能够保证状态 设置的原子性。

![同步状态方法](https://img-blog.csdnimg.cn/f05d1f8fd4844a02832094703b853cea.png)

同步状态可以表示任意状态，例如：

 ReentrantLock 中用它来标识所有者线程已经重复获取该锁的次数
 Semaphore 用它来表示剩余的许可数量
 FutureTask 用它来表示任务的状态（尚未开始、正在运行、已完成以及已注销）

在同步器类中还可以自行管理一些额外的状态变量：

 ReentrantLock 保存了锁当前所有者的信息，能区分某个获取操作是重入的还是竞争的
 

同步器可重写的方法：
|方法名称 | 描述|
|--|--|
|protected boolean tryAcquire(int arg) | 独占式获取同步状态，实现该方法需要查询当前状态并判断同步状态是否符合预期，然后再进行CAS设置同步状态 |
|protected boolean tryRelease(int arg) | 独占式释放同步状态，等待获取同步状态的线程将有机会获取同步状态 |
|protected int tryAcquireShared(int arg) | 共享式获取同步状态，返回大于等于0的值，表示获取成功，反之，获取失败 |
|protected boolean tryReleaseShared(int arg) | 共享式释放同步状态 |
|protected boolean isHeldExclusively() | 当前同步器是否在独占模式下被线程占用，一般该方法标识是否被当前线程所独占 |

同步器提供的模板方法基本上分为3类：独占式获取与释放同步状态、共享式获取与释放同步状态和查询同步队列中的等待线程情况。自定义同步组件将使用同步器提供的模板方法来实现自己的同步语义。

### 个人理解
ReentrantLock、 ReentrantReadWriteLock和CountDownLatch等锁实际上是内部定义的类实现的，同步器是实现锁的关键，它简化了锁的实现方式，屏蔽了同步状态管理、线程的排队、等待与唤醒等底层操作。锁的实现又分为互斥锁与共享锁,分别对应同步器的独占式与共享式操作同步状态。

![AQS的实现](https://img-blog.csdnimg.cn/954a5039aaaa44139aa3b26f82e7a964.png)

## 队列同步器的实现分析

### 同步队列

同步器依赖内部的同步队列（一个FIFO双向队列）来完成同步状态的管理，当前线程获取 同步状态失败时，同步器会将当前线程以及等待状态等信息构造成为一个节点（Node）并将其 加入同步队列，同时会阻塞当前线程，当同步状态释放时，会把首节点中的线程唤醒，使其再 次尝试获取同步状态。

同步队列中的节点（Node）用来保存获取同步状态失败的线程引用、等待状态以及前驱和后继节点，节点的属性类型与名称以及描述。
![双向队列](https://img-blog.csdnimg.cn/6ab32d9bd02b454588391c8bef7c1d7a.png)




# ReentrantLock

### ReentrantLock 的实现原理
ReentrantLock底层是基于AQS实现的，通过AQS维护的 volatile 的 state 变量来实现锁操作的。
ReentrantLock实现了Lock接口，并提供了与synchronized相同的互斥性和内存可见性。
与synchronized一样，ReentrantLock也提供了可重入的加锁语义。

JUC 基础知识总结

JUC入门的知识体系梳理

衡量一个服务性能的高低好坏，每秒事务处理数（Transactions Per Second， TPS）是重要的指标之一，它代表着一秒内服务端平均能响应的请求总数，而TPS值与程序的并发能力又有非常密切的关系。对于计算量相同的任务，程序线程并发协调得越有条不紊，效率自然就会越高；反之，线程之间频繁争用数据，互相阻塞甚至死锁，将会大大降低程序的并发能力。



# JVM内存模型与锁优化

## Java内存模型

### 概述
Java内存模型规定了所有的变量都存储在主内存（Main Memory）中。每条线程都有自己的工作内存（Working Memory），线程的工作内存中保存了被该线程使用的变量的主内存副本，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成。线程与线程之间的变量数据是不可见的。

### 内存间交互操作
关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存这一类的实现细节，Java内存模型中定义了以下8种操作来完成。Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的。

>* lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。 >* >* unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量 才可以被其他线程锁定。 
>* read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以 便随后的load动作使用。 
>* load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的 变量副本中。
>* use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚 拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
>* assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收的值赋给工作内存的变量， 每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
>* store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随 后的write操作使用。
>* write（写入）：作用于主内存的变量，它把store操作从工作内存中得到的变量的值放入主内存的 变量中。

这8种内存访问操作以及上述规则限定，再加上稍后会介绍的专门针对volatile的一些特殊规定，就已经能准确地描述出Java程序中哪些内存访问操作在并发下才是安全的。

这种定义相当严谨，但也是极为烦琐，实践起来更是无比麻烦。可能部分读者阅读到这里已经对多线程开发产生恐惧感了，后来Java设计团队大概也意识到了这个问题，将Java内存模型的操作简化为read、write、lock和unlock四种。

### volatile
**关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制**

**当一个变量被定义成volatile之后，它将具备两项特性：** 

第一项是保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。而普通变量并不能做到这一点，普通变量的值在线程间传递时均需要通过主内存来完成。比如，线程A修改一个普通变量的值，然后向主内存进行回写，另外一条线程B在线程A回写完成了之后再对主内存进行读取操作，新变量值才会对线程B可见。
 
 **可见性的原理：被volatile修饰的变量在工作内存中使用前都会先刷新。**
 
由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁 （使用synchronized、java.util.concurrent中的锁或原子类）来保证原子性：

>* 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值。
>* 变量不需要与其他的状态变量共同参与不变约束。

使用volatile变量的第二个语义是禁止指令重排序优化，普通的变量仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。

有volatile修饰的变量，赋值后多执行了一个“lock addl$0x0，(%esp)”操作，这个操作的作用相当于一个内存屏障 （Memory Barrier或Memory Fence，指重排序时不能把后面的指令重排序到内存屏障之前的位置）。

解决了volatile的语义问题，再来看看在众多保障并发安全的工具中选用volatile的意义——**它能让我们的代码比使用其他的同步工具更快吗？**

 在某些情况下，volatile的同步机制的性能确实要优于锁（使用synchronized关键字或java.util.concurrent包里面的锁），但是由于虚拟机对锁实行的许多消除和优化，使得我们很难确切地说volatile就会比synchronized快上多少。
 
 如果让volatile自己与自己比较，那可以确定一个原则：volatile变量读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢上一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过即便如此，大多数场景下volatile的总开销仍然要比锁来得更低。
 
总结：我们在volatile与锁中选择的唯一判断依据仅仅是volatile的语义能否满足使用场景的需求。

### 内存模型的特性

#### 原子性（Atomicity）

如果应用场景需要一个更大范围的原子性保证（经常会遇到），Java内存模型还提供了lock和unlock操作来满足这种需求，尽管虚拟机未把lock和unlock操作直接开放给用户使用，但是却提供了更高层次的字节码指令monitorenter和monitorexit来隐式地使用这两个操作。这两个字节码指令反映到Java代码中就是同步块——synchronized关键字，因此在synchronized块之间的操作也具备原子性。

#### 可见性（Visibility）

Java内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是volatile变量都是如此。

普通变量与volatile变量的区别是，volatile的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新。因此我们可以说volatile保证了多线程操作时变量的可见性，而普通变量则不能保证这一点。

除了volatile之外，Java还有两个关键字能实现可见性，它们是synchronized和final。

#### 有序性（Ordering）

Java内存模型的有序性在前面讲解volatile时也比较详细地讨论过了，Java程序中天然的有序性可以总结为一句话：

 如果在本线程内观察，所有的操作都是有序的；
 如果在一个线程中观察另一个线程，所有的操作都是无序的。

前半句是指“线程内似表现为串行的语义”（Within-Thread As-If-Serial Semantics），后半句是指“指令重排序”现象和“工作内存与主内存同步延迟”现象。

Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性，volatile关键字本身就包含了禁止指令重排序的语义，而synchronized则是由“一个变量在同一个时刻只允许一条线程对 其进行lock操作”这条规则获得的，这个规则决定了持有同一个锁的两个同步块只能串行地进入。


## 线程状态
Java语言定义了6种线程状态，在任意一个时间点中，一个线程只能有且只有其中的一种状态，并且可以通过特定的方法在不同状态之间转换。这6种状态分别是：

### 新建（New）：
创建后尚未启动的线程处于这种状态。

### 运行（Runnable）：
包括操作系统线程状态中的Running和Ready，也就是处于此状态的线程有可 能正在执行，也有可能正在等待着操作系统为它分配执行时间。

### 无限期等待（Waiting）：
处于这种状态的线程不会被分配处理器执行时间，它们要等待被其他线 程显式唤醒。以下方法会让线程陷入无限期的等待状态：
>* 没有设置Timeout参数的Object::wait()方法；
>* 没有设置Timeout参数的Thread::join()方法；
>* LockSupport::park()方法。 

### 限期等待（Timed Waiting）：
处于这种状态的线程也不会被分配处理器执行时间，不过无须等待被其他线程显式唤醒，在一定时间之后它们会由系统自动唤醒。以下方法会让线程进入限期等待状态：
>* Thread::sleep()方法； 
>* 设置了Timeout参数的Object::wait()方法； 
>* 设置了Timeout参数的Thread::join()方法； 
>* LockSupport::parkNanos()方法； 
>* LockSupport::parkUntil()方法。 

### 阻塞（Blocked）：
线程被阻塞了，“阻塞状态”与“等待状态”的区别是“阻塞状态”在等待着获取到一个排它锁，这个事件将在另外一个线程放弃这个锁的时候发生；而“等待状态”则是在等待一段时 间，或者唤醒动作的发生。在程序等待进入同步区域的时候，线程将进入这种状态。 

### 结束（Terminated）：
已终止线程的线程状态，线程已经结束执行


## 线程安全

### 线程安全的实现

#### 互斥同步

在Java里面，最基本的互斥同步手段就是synchronized关键字，这是一种块结构（Block Structured）的同步语法。synchronized关键字经过Javac编译之后，会在同步块的前后分别形成 `monitorenter` 和 `monitorexit` 这两个字节码指令。

根据《Java虚拟机规范》的要求，**在执行 `monitorenter` 指令时，首先要去尝试获取对象的锁。如果这个对象没被锁定，或者当前线程已经持有了那个对象的锁，就把锁的计数器的值增加一，而在执行 `monitorexit` 指令时会将锁计数器的值减一。一旦计数器的值为零，锁随即就被释放了。如果获取对象锁失败，那当前线程就应当被阻塞等待，直到请求锁定的对象被持有它的线程释放为止。（可重入锁的原理，此处以 synchronized 举例）**

自JDK 5起 （实现了JSR 166[1]），Java类库中新提供了java.util.concurrent包（下文称J.U.C包），其中的 java.util.concurrent.locks.Lock接口便成了Java的另一种全新的互斥同步手段。基于Lock接口，用户能够 以非块结构（Non-Block Structured）来实现互斥同步，从而摆脱了语言特性的束缚，改为在类库层面 去实现同步，这也为日后扩展出不同调度算法、不同特征、不同性能、不同语义的各种锁提供了广阔的空间。

重入锁（ReentrantLock）是Lock接口最常见的一种实现，顾名思义，它与synchronized一样是可重入的。在基本用法上，ReentrantLock也与synchronized很相似，只是代码写法上稍有区别而已。

**Synchronized 与 ReentrantLock 锁的区别，主要有以下三项：**
**等待可中断、可实现公平锁、锁可以绑定多个条件**

**等待可中断：**
是指当持有锁的线程长期不释放锁的时候，正在等待的线程可以选择放弃等待，改为处理其他事情。可中断特性对处理执行时间非常长的同步块很有帮助。

**公平锁、非公平锁：**
是指多个线程在等待同一个锁时，必须按照申请锁的时间顺序来依次获得锁；而非公平 锁则不保证这一点，在锁被释放时，任何一个等待锁的线程都有机会获得锁。synchronized中的锁是非 公平的，ReentrantLock在默认情况下也是非公平的，但可以通过带布尔值的构造函数要求使用公平锁。不过一旦使用了公平锁，将会导致ReentrantLock的性能急剧下降，会明显影响吞吐量。 

**锁绑定多个条件：**
是指一个ReentrantLock对象可以同时绑定多个Condition对象。
在synchronized 中，锁对象的wait()跟它的notify()或者notifyAll()方法配合可以实现一个隐含的条件，如果要和多于一个的条件关联的时候，就不得不额外添加一个锁；
而ReentrantLock则无须这样做，多次调用newCondition()方法即可。

#### 非阻塞同步

**互斥同步面临的主要问题是进行线程阻塞和唤醒所带来的性能开销，因此这种同步也被称为阻塞同步（Blocking Synchronization）。**

从解决问题的方式上看，互斥同步属于一种悲观的并发策略，其总是认为只要不去做正确的同步措施（例如加锁），那就肯定会出现问题，无论共享的数据是否真的会出现竞争，它都会进行加锁（这里讨论的是概念模型，实际上虚拟机会优化掉很大一部分不必要的加 锁），这将会导致用户态到核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等开销。

随着硬件指令集的发展，我们已经有了另外一个选择：**基于冲突检测的乐观并发策略，通俗地说就是不管风险，先进行操作，如果没有其他线程争用共享数据，那操作就直接成功了；如果共享的数据的确被争用，产生了冲突，那再进行其他的补偿措施，最常用的补偿措施是不断地重试，直到出现没有竞争的共享数据为止。这种乐观并发策略的实现不再需要把线程阻塞挂起，因此这种同步操作被 称为非阻塞同步（Non-Blocking Synchronization）**，使用这种措施的代码也常被称为无锁（Lock-Free） 编程。

**比较并交换（Compare-and-Swap，下文称CAS）；**

**CAS指令需要有三个操作数，分别是内存位置（在Java中可以简单地理解为变量的内存地址，用V 表示）、旧的预期值（用A表示）和准备设置的新值（用B表示）。
CAS指令执行时，当且仅当V符合A时，处理器才会用B更新V的值，否则它就不执行更新。但是，不管是否更新了V的值，都会返回V的旧值，上述的处理过程是一个原子操作，执行期间不会被其他线程中断。**

CAS具体实现：AtomicInteger #incrementAndGet()方法的JDK源码
```java
/**
 * Atomically increment by one the current value. 
 * @return the updated value
 */ 
public final int incrementAndGet() { 
 for (;;) { 
 int current = get(); 
 int next = current + 1; 
 if (compareAndSet(current, next)) 
 return next;
 } 
}
```

incrementAndGet()方法在一个无限循环中，不断尝试将一个比当前值大一的新值赋值给自己。如果失败了，那说明在执行CAS操作的时候，旧值已经发生改变，于是再次循环进行下一次操作，直到设置成功为止。

尽管CAS看起来很美好，既简单又高效，但显然这种操作无法涵盖互斥同步的所有使用场景，并且CAS从语义上来说并不是真正完美的，它存在一个逻辑漏洞：如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然为A值，那就能说明它的值没有被其他线程改变过了吗？

**“ABA”问题**

这是不能的，因为如果在这段期间它的值曾经被改成B，后来又被改回为A，那CAS操作就会误认为它从来没有被改变过。这个漏洞称为CAS操作的“ABA问题”。J.U.C包为了解决这个问题，提供了一个带有标记的原子引用类AtomicStampedReference，它可以通过控制变量值的版本来保证CAS的正确性。不过目前来说这个类处于相当鸡肋的位置，大部分情况下ABA问题不会影响程序并发的正确性，如果需要解决ABA问题，改用传统的互斥同步可能会比原子类更为高效。
 

## 锁优化

### 自旋锁与自适应锁

### 锁消除

### 锁粗化

### 轻量级锁

### 偏向锁

JVM 高效并发核心知识

baidu-site-verification

本人自己的博客，对工作与学习过程中的总结、一些场景设计的实现方案、遇到过的疑难问题与解决、以及面试总结等。