mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-07-28 12:22:17 +08:00
[docs update&add]完善部分内容描述&新增一篇cas详解
This commit is contained in:
Guide
parent
97dd88a54c
commit
fe697ad4a3
@ -88,6 +88,8 @@
|
||||
|
||||
**重要知识点详解**：
|
||||
|
||||
- [乐观锁和悲观锁详解](./docs/java/concurrent/jmm.md)
|
||||
- [CAS 详解](./docs/java/concurrent/cas.md)
|
||||
- [JMM（Java 内存模型）详解](./docs/java/concurrent/jmm.md)
|
||||
- **线程池**：[Java 线程池详解](./docs/java/concurrent/java-thread-pool-summary.md)、[Java 线程池最佳实践](./docs/java/concurrent/java-thread-pool-best-practices.md)
|
||||
- [ThreadLocal 详解](./docs/java/concurrent/threadlocal.md)
|
||||
|
||||
@ -112,6 +112,7 @@ export default sidebar({
|
||||
collapsible: true,
|
||||
children: [
|
||||
"optimistic-lock-and-pessimistic-lock",
|
||||
"cas",
|
||||
"jmm",
|
||||
"java-thread-pool-summary",
|
||||
"java-thread-pool-best-practices",
|
||||
|
||||
@ -385,6 +385,14 @@ EXPLAIN SELECT * FROM student WHERE name = 'Anne Henry' AND class = 'lIrm08RYVk'
|
||||
SELECT * FROM student WHERE class = 'lIrm08RYVk';
|
||||
```
|
||||
|
||||
再来看一个常见的面试题：如果有索引 `联合索引（a，b，c）`，查询 `a=1 AND c=1`会走索引么？`c=1` 呢？`b=1 AND c=1`呢？
|
||||
|
||||
先不要往下看答案，给自己 3 分钟时间想一想。
|
||||
|
||||
1. 查询 `a=1 AND c=1`：根据最左前缀匹配原则，查询可以使用索引的前缀部分。因此，该查询仅在 `a=1` 上使用索引，然后对结果进行 `c=1` 的过滤。
|
||||
2. 查询 `c=1` ：由于查询中不包含最左列 `a`，根据最左前缀匹配原则，整个索引都无法被使用。
|
||||
3. 查询`b=1 AND c=1`：和第二种一样的情况，整个索引都不会使用。
|
||||
|
||||
MySQL 8.0.13 版本引入了索引跳跃扫描（Index Skip Scan，简称 ISS），它可以在某些索引查询场景下提高查询效率。在没有 ISS 之前，不满足最左前缀匹配原则的联合索引查询中会执行全表扫描。而 ISS 允许 MySQL 在某些情况下避免全表扫描，即使查询条件不符合最左前缀。不过，这个功能比较鸡肋， 和 Oracle 中的没法比，MySQL 8.0.31 还报告了一个 bug：[Bug #109145 Using index for skip scan cause incorrect result](https://bugs.mysql.com/bug.php?id=109145)（后续版本已经修复）。个人建议知道有这个东西就好，不需要深究，实际项目也不一定能用上。
|
||||
|
||||
## 索引下推
|
||||
|
||||
@ -148,7 +148,7 @@ WHERE username = 'root';
|
||||
### 删除数据
|
||||
|
||||
- `DELETE` 语句用于删除表中的记录。
|
||||
- `TRUNCATE TABLE` 可以清空表，也就是删除所有行。
|
||||
- `TRUNCATE TABLE` 可以清空表，也就是删除所有行。说明：`TRUNCATE` 语句不属于 DML 语法而是 DDL 语法。
|
||||
|
||||
**删除表中的指定数据**
|
||||
|
||||
|
||||
@ -72,6 +72,8 @@ title: JavaGuide（Java学习&面试指南）
|
||||
|
||||
**重要知识点详解**：
|
||||
|
||||
- [乐观锁和悲观锁详解](./java/concurrent/jmm.md)
|
||||
- [CAS 详解](./java/concurrent/cas.md)
|
||||
- [JMM（Java 内存模型）详解](./java/concurrent/jmm.md)
|
||||
- **线程池**：[Java 线程池详解](./java/concurrent/java-thread-pool-summary.md)、[Java 线程池最佳实践](./java/concurrent/java-thread-pool-best-practices.md)
|
||||
- [ThreadLocal 详解](./java/concurrent/threadlocal.md)
|
||||
|
||||
@ -216,7 +216,7 @@ public class Student {
|
||||
|
||||
在 Java 8 及以上版本中，接口引入了新的方法类型：`default` 方法、`static` 方法和 `private` 方法。这些方法让接口的使用更加灵活。
|
||||
|
||||
Java 8 引入的`default` 方法用于提供接口方法的默认实现，可以在实现类中被覆盖。
|
||||
Java 8 引入的`default` 方法用于提供接口方法的默认实现，可以在实现类中被覆盖。这样就可以在不修改实现类的情况下向现有接口添加新功能，从而增强接口的扩展性和向后兼容性。
|
||||
|
||||
```java
|
||||
public interface MyInterface {
|
||||
@ -226,7 +226,7 @@ public interface MyInterface {
|
||||
}
|
||||
```
|
||||
|
||||
Java 8 引入的`static` 方法无法在实现类中被覆盖，只能通过接口名直接调用（ `MyInterface.staticMethod()`），类似于类中的静态方法。
|
||||
Java 8 引入的`static` 方法无法在实现类中被覆盖，只能通过接口名直接调用（ `MyInterface.staticMethod()`），类似于类中的静态方法。`static` 方法通常用于定义一些通用的、与接口相关的工具方法，一般很少用。
|
||||
|
||||
```java
|
||||
public interface MyInterface {
|
||||
@ -255,7 +255,7 @@ public interface MyInterface {
|
||||
System.out.println("This is a private method used internally.");
|
||||
}
|
||||
|
||||
// 私有方法，只能被 default 方法调用。
|
||||
// 实例私有方法，只能被 default 方法调用。
|
||||
private void instanceCommonMethod() {
|
||||
System.out.println("This is a private instance method used internally.");
|
||||
}
|
||||
|
||||
160
docs/java/concurrent/cas.md
Normal file
160
docs/java/concurrent/cas.md
Normal file
@ -0,0 +1,160 @@
|
||||
---
|
||||
title: CAS 详解
|
||||
category: Java
|
||||
tag:
|
||||
- Java并发
|
||||
---
|
||||
|
||||
乐观锁和悲观锁的介绍以及乐观锁常见实现方式可以阅读笔者写的这篇文章：[乐观锁和悲观锁详解](https://javaguide.cn/java/concurrent/optimistic-lock-and-pessimistic-lock.html)。
|
||||
|
||||
这篇文章主要介绍 ：Java 中 CAS 的实现以及 CAS 存在的一些问题。
|
||||
|
||||
## Java 中 CAS 是如何实现的？
|
||||
|
||||
在 Java 中，实现 CAS（Compare-And-Swap, 比较并交换）操作的一个关键类是`Unsafe`。
|
||||
|
||||
`Unsafe`类位于`sun.misc`包下，是一个提供低级别、不安全操作的类。由于其强大的功能和潜在的危险性，它通常用于 JVM 内部或一些需要极高性能和底层访问的库中，而不推荐普通开发者在应用程序中使用。关于 `Unsafe`类的详细介绍，可以阅读这篇文章：📌[Java 魔法类 Unsafe 详解](https://javaguide.cn/java/basis/unsafe.html)。
|
||||
|
||||
`sun.misc`包下的`Unsafe`类提供了`compareAndSwapObject`、`compareAndSwapInt`、`compareAndSwapLong`方法来实现的对`Object`、`int`、`long`类型的 CAS 操作：
|
||||
|
||||
```java
|
||||
/**
|
||||
* 以原子方式更新对象字段的值。
|
||||
*
|
||||
* @param o 要操作的对象
|
||||
* @param offset 对象字段的内存偏移量
|
||||
* @param expected 期望的旧值
|
||||
* @param x 要设置的新值
|
||||
* @return 如果值被成功更新，则返回 true；否则返回 false
|
||||
*/
|
||||
boolean compareAndSwapObject(Object o, long offset, Object expected, Object x);
|
||||
|
||||
/**
|
||||
* 以原子方式更新 int 类型的对象字段的值。
|
||||
*/
|
||||
boolean compareAndSwapInt(Object o, long offset, int expected, int x);
|
||||
|
||||
/**
|
||||
* 以原子方式更新 long 类型的对象字段的值。
|
||||
*/
|
||||
boolean compareAndSwapLong(Object o, long offset, long expected, long x);
|
||||
```
|
||||
|
||||
`Unsafe`类中的 CAS 方法是`native`方法。`native`关键字表明这些方法是用本地代码（通常是 C 或 C++）实现的，而不是用 Java 实现的。这些方法直接调用底层的硬件指令来实现原子操作。也就是说，Java 语言并没有直接用 Java 实现 CAS，而是通过 C++ 内联汇编的形式实现的（通过 JNI 调用）。因此，CAS 的具体实现与操作系统以及 CPU 密切相关。
|
||||
|
||||
`java.util.concurrent.atomic` 包提供了一些用于原子操作的类。这些类利用底层的原子指令，确保在多线程环境下的操作是线程安全的。
|
||||
|
||||
|
||||
|
||||
关于这些 Atomic 原子类的介绍和使用，可以阅读这篇文章：[Atomic 原子类总结](https://javaguide.cn/java/concurrent/atomic-classes.html)。
|
||||
|
||||
`AtomicInteger`是 Java 的原子类之一，主要用于对 `int` 类型的变量进行原子操作，它利用`Unsafe`类提供的低级别原子操作方法实现无锁的线程安全性。
|
||||
|
||||
下面，我们通过解读`AtomicInteger`的核心源码（JDK1.8），来说明 Java 如何使用`Unsafe`类的方法来实现原子操作。
|
||||
|
||||
`AtomicInteger`核心源码如下：
|
||||
|
||||
```java
|
||||
// 获取 Unsafe 实例
|
||||
private static final Unsafe unsafe = Unsafe.getUnsafe();
|
||||
private static final long valueOffset;
|
||||
|
||||
static {
|
||||
try {
|
||||
// 获取“value”字段在AtomicInteger类中的内存偏移量
|
||||
valueOffset = unsafe.objectFieldOffset
|
||||
(AtomicInteger.class.getDeclaredField("value"));
|
||||
} catch (Exception ex) { throw new Error(ex); }
|
||||
}
|
||||
// 确保“value”字段的可见性
|
||||
private volatile int value;
|
||||
|
||||
// 如果当前值等于预期值，则原子地将值设置为newValue
|
||||
// 使用 Unsafe#compareAndSwapInt 方法进行CAS操作
|
||||
public final boolean compareAndSet(int expect, int update) {
|
||||
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
|
||||
}
|
||||
|
||||
// 原子地将当前值加 delta 并返回旧值
|
||||
public final int getAndAdd(int delta) {
|
||||
return unsafe.getAndAddInt(this, valueOffset, delta);
|
||||
}
|
||||
|
||||
// 原子地将当前值加 1 并返回加之前的值（旧值）
|
||||
// 使用 Unsafe#getAndAddInt 方法进行CAS操作。
|
||||
public final int getAndIncrement() {
|
||||
return unsafe.getAndAddInt(this, valueOffset, 1);
|
||||
}
|
||||
|
||||
// 原子地将当前值减 1 并返回减之前的值（旧值）
|
||||
public final int getAndDecrement() {
|
||||
return unsafe.getAndAddInt(this, valueOffset, -1);
|
||||
}
|
||||
```
|
||||
|
||||
`Unsafe#getAndAddInt`源码：
|
||||
|
||||
```java
|
||||
// 原子地获取并增加整数值
|
||||
public final int getAndAddInt(Object o, long offset, int delta) {
|
||||
int v;
|
||||
do {
|
||||
// 以 volatile 方式获取对象 o 在内存偏移量 offset 处的整数值
|
||||
v = getIntVolatile(o, offset);
|
||||
} while (!compareAndSwapInt(o, offset, v, v + delta));
|
||||
// 返回旧值
|
||||
return v;
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，`getAndAddInt` 使用了 `do-while` 循环：在`compareAndSwapInt`操作失败时，会不断重试直到成功。也就是说，`getAndAddInt`方法会通过 `compareAndSwapInt` 方法来尝试更新 `value` 的值，如果更新失败（当前值在此期间被其他线程修改），它会重新获取当前值并再次尝试更新，直到操作成功。
|
||||
|
||||
由于 CAS 操作可能会因为并发冲突而失败，因此通常会与`while`循环搭配使用，在失败后不断重试，直到操作成功。这就是 **自旋锁机制** 。
|
||||
|
||||
## CAS 算法存在哪些问题？
|
||||
|
||||
ABA 问题是 CAS 算法最常见的问题。
|
||||
|
||||
### ABA 问题
|
||||
|
||||
如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 **"ABA"问题。**
|
||||
|
||||
ABA 问题的解决思路是在变量前面追加上**版本号或者时间戳**。JDK 1.5 以后的 `AtomicStampedReference` 类就是用来解决 ABA 问题的，其中的 `compareAndSet()` 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
|
||||
|
||||
```java
|
||||
public boolean compareAndSet(V expectedReference,
|
||||
V newReference,
|
||||
int expectedStamp,
|
||||
int newStamp) {
|
||||
Pair<V> current = pair;
|
||||
return
|
||||
expectedReference == current.reference &&
|
||||
expectedStamp == current.stamp &&
|
||||
((newReference == current.reference &&
|
||||
newStamp == current.stamp) ||
|
||||
casPair(current, Pair.of(newReference, newStamp)));
|
||||
}
|
||||
```
|
||||
|
||||
### 循环时间长开销大
|
||||
|
||||
CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。
|
||||
|
||||
如果 JVM 能够支持处理器提供的`pause`指令，那么自旋操作的效率将有所提升。`pause`指令有两个重要作用：
|
||||
|
||||
1. **延迟流水线执行指令**：`pause`指令可以延迟指令的执行，从而减少 CPU 的资源消耗。具体的延迟时间取决于处理器的实现版本，在某些处理器上，延迟时间可能为零。
|
||||
2. **避免内存顺序冲突**：在退出循环时，`pause`指令可以避免由于内存顺序冲突而导致的 CPU 流水线被清空，从而提高 CPU 的执行效率。
|
||||
|
||||
### 只能保证一个共享变量的原子操作
|
||||
|
||||
CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5 开始，提供了`AtomicReference`类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用`AtomicReference`类把多个共享变量合并成一个共享变量来操作。
|
||||
|
||||
CAS 操作仅能对单个共享变量有效。当需要操作多个共享变量时，CAS 就显得无能为力。不过，从 JDK 1.5 开始，Java 提供了`AtomicReference`类，这使得我们能够保证引用对象之间的原子性。通过将多个变量封装在一个对象中，我们可以使用`AtomicReference`来执行 CAS 操作。
|
||||
|
||||
除了 `AtomicReference` 这种方式之外，还可以利用加锁来保证。
|
||||
|
||||
## 总结
|
||||
|
||||
在 Java 中，CAS 通过 `Unsafe` 类中的 `native` 方法实现，这些方法调用底层的硬件指令来完成原子操作。由于其实现依赖于 C++ 内联汇编和 JNI 调用，因此 CAS 的具体实现与操作系统以及 CPU 密切相关。
|
||||
|
||||
CAS 作为实现乐观锁的核心算法，虽然具有高效的无锁特性，但也需要注意 ABA 问题、循环时间长开销大等问题。
|
||||
@ -285,6 +285,108 @@ public final native boolean compareAndSwapLong(Object o, long offset, long expec
|
||||
|
||||
关于 `Unsafe` 类的详细介绍可以看这篇文章：[Java 魔法类 Unsafe 详解 - JavaGuide - 2022](https://javaguide.cn/java/basis/unsafe.html) 。
|
||||
|
||||
### Java 中 CAS 是如何实现的？
|
||||
|
||||
在 Java 中，实现 CAS（Compare-And-Swap, 比较并交换）操作的一个关键类是`Unsafe`。
|
||||
|
||||
`Unsafe`类位于`sun.misc`包下，是一个提供低级别、不安全操作的类。由于其强大的功能和潜在的危险性，它通常用于 JVM 内部或一些需要极高性能和底层访问的库中，而不推荐普通开发者在应用程序中使用。关于 `Unsafe`类的详细介绍，可以阅读这篇文章：📌[Java 魔法类 Unsafe 详解](https://javaguide.cn/java/basis/unsafe.html)。
|
||||
|
||||
`sun.misc`包下的`Unsafe`类提供了`compareAndSwapObject`、`compareAndSwapInt`、`compareAndSwapLong`方法来实现的对`Object`、`int`、`long`类型的 CAS 操作：
|
||||
|
||||
```java
|
||||
/**
|
||||
* 以原子方式更新对象字段的值。
|
||||
*
|
||||
* @param o 要操作的对象
|
||||
* @param offset 对象字段的内存偏移量
|
||||
* @param expected 期望的旧值
|
||||
* @param x 要设置的新值
|
||||
* @return 如果值被成功更新，则返回 true；否则返回 false
|
||||
*/
|
||||
boolean compareAndSwapObject(Object o, long offset, Object expected, Object x);
|
||||
|
||||
/**
|
||||
* 以原子方式更新 int 类型的对象字段的值。
|
||||
*/
|
||||
boolean compareAndSwapInt(Object o, long offset, int expected, int x);
|
||||
|
||||
/**
|
||||
* 以原子方式更新 long 类型的对象字段的值。
|
||||
*/
|
||||
boolean compareAndSwapLong(Object o, long offset, long expected, long x);
|
||||
```
|
||||
|
||||
`Unsafe`类中的 CAS 方法是`native`方法。`native`关键字表明这些方法是用本地代码（通常是 C 或 C++）实现的，而不是用 Java 实现的。这些方法直接调用底层的硬件指令来实现原子操作。也就是说，Java 语言并没有直接用 Java 实现 CAS，而是通过 C++ 内联汇编的形式实现的（通过 JNI 调用）。因此，CAS 的具体实现与操作系统以及 CPU 密切相关。
|
||||
|
||||
`java.util.concurrent.atomic` 包提供了一些用于原子操作的类。这些类利用底层的原子指令，确保在多线程环境下的操作是线程安全的。
|
||||
|
||||
|
||||
|
||||
关于这些 Atomic 原子类的介绍和使用，可以阅读这篇文章：[Atomic 原子类总结](https://javaguide.cn/java/concurrent/atomic-classes.html)。
|
||||
|
||||
`AtomicInteger`是 Java 的原子类之一，主要用于对 `int` 类型的变量进行原子操作，它利用`Unsafe`类提供的低级别原子操作方法实现无锁的线程安全性。
|
||||
|
||||
下面，我们通过解读`AtomicInteger`的核心源码（JDK1.8），来说明 Java 如何使用`Unsafe`类的方法来实现原子操作。
|
||||
|
||||
`AtomicInteger`核心源码如下：
|
||||
|
||||
```java
|
||||
// 获取 Unsafe 实例
|
||||
private static final Unsafe unsafe = Unsafe.getUnsafe();
|
||||
private static final long valueOffset;
|
||||
|
||||
static {
|
||||
try {
|
||||
// 获取“value”字段在AtomicInteger类中的内存偏移量
|
||||
valueOffset = unsafe.objectFieldOffset
|
||||
(AtomicInteger.class.getDeclaredField("value"));
|
||||
} catch (Exception ex) { throw new Error(ex); }
|
||||
}
|
||||
// 确保“value”字段的可见性
|
||||
private volatile int value;
|
||||
|
||||
// 如果当前值等于预期值，则原子地将值设置为newValue
|
||||
// 使用 Unsafe#compareAndSwapInt 方法进行CAS操作
|
||||
public final boolean compareAndSet(int expect, int update) {
|
||||
return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
|
||||
}
|
||||
|
||||
// 原子地将当前值加 delta 并返回旧值
|
||||
public final int getAndAdd(int delta) {
|
||||
return unsafe.getAndAddInt(this, valueOffset, delta);
|
||||
}
|
||||
|
||||
// 原子地将当前值加 1 并返回加之前的值（旧值）
|
||||
// 使用 Unsafe#getAndAddInt 方法进行CAS操作。
|
||||
public final int getAndIncrement() {
|
||||
return unsafe.getAndAddInt(this, valueOffset, 1);
|
||||
}
|
||||
|
||||
// 原子地将当前值减 1 并返回减之前的值（旧值）
|
||||
public final int getAndDecrement() {
|
||||
return unsafe.getAndAddInt(this, valueOffset, -1);
|
||||
}
|
||||
```
|
||||
|
||||
`Unsafe#getAndAddInt`源码：
|
||||
|
||||
```java
|
||||
// 原子地获取并增加整数值
|
||||
public final int getAndAddInt(Object o, long offset, int delta) {
|
||||
int v;
|
||||
do {
|
||||
// 以 volatile 方式获取对象 o 在内存偏移量 offset 处的整数值
|
||||
v = getIntVolatile(o, offset);
|
||||
} while (!compareAndSwapInt(o, offset, v, v + delta));
|
||||
// 返回旧值
|
||||
return v;
|
||||
}
|
||||
```
|
||||
|
||||
可以看到，`getAndAddInt` 使用了 `do-while` 循环：在`compareAndSwapInt`操作失败时，会不断重试直到成功。也就是说，`getAndAddInt`方法会通过 `compareAndSwapInt` 方法来尝试更新 `value` 的值，如果更新失败（当前值在此期间被其他线程修改），它会重新获取当前值并再次尝试更新，直到操作成功。
|
||||
|
||||
由于 CAS 操作可能会因为并发冲突而失败，因此通常会与`while`循环搭配使用，在失败后不断重试，直到操作成功。这就是 **自旋锁机制** 。
|
||||
|
||||
### CAS 算法存在哪些问题？
|
||||
|
||||
ABA 问题是 CAS 算法最常见的问题。
|
||||
@ -314,15 +416,19 @@ public boolean compareAndSet(V expectedReference,
|
||||
|
||||
CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。
|
||||
|
||||
如果 JVM 能支持处理器提供的 pause 指令那么效率会有一定的提升，pause 指令有两个作用：
|
||||
如果 JVM 能够支持处理器提供的`pause`指令，那么自旋操作的效率将有所提升。`pause`指令有两个重要作用：
|
||||
|
||||
1. 可以延迟流水线执行指令，使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。
|
||||
2. 可以避免在退出循环的时候因内存顺序冲突而引起 CPU 流水线被清空，从而提高 CPU 的执行效率。
|
||||
1. **延迟流水线执行指令**：`pause`指令可以延迟指令的执行，从而减少 CPU 的资源消耗。具体的延迟时间取决于处理器的实现版本，在某些处理器上，延迟时间可能为零。
|
||||
2. **避免内存顺序冲突**：在退出循环时，`pause`指令可以避免由于内存顺序冲突而导致的 CPU 流水线被清空，从而提高 CPU 的执行效率。
|
||||
|
||||
#### 只能保证一个共享变量的原子操作
|
||||
|
||||
CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5 开始，提供了`AtomicReference`类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用`AtomicReference`类把多个共享变量合并成一个共享变量来操作。
|
||||
|
||||
CAS 操作仅能对单个共享变量有效。当需要操作多个共享变量时，CAS 就显得无能为力。不过，从 JDK 1.5 开始，Java 提供了`AtomicReference`类，这使得我们能够保证引用对象之间的原子性。通过将多个变量封装在一个对象中，我们可以使用`AtomicReference`来执行 CAS 操作。
|
||||
|
||||
除了 `AtomicReference` 这种方式之外，还可以利用加锁来保证。
|
||||
|
||||
## synchronized 关键字
|
||||
|
||||
### synchronized 是什么？有什么用？
|
||||
|
||||
@ -7,8 +7,6 @@ tag:
|
||||
|
||||
如果将悲观锁（Pessimistic Lock）和乐观锁（PessimisticLock 或 OptimisticLock）对应到现实生活中来。悲观锁有点像是一位比较悲观（也可以说是未雨绸缪）的人，总是会假设最坏的情况，避免出现问题。乐观锁有点像是一位比较乐观的人，总是会假设最好的情况，在要出现问题之前快速解决问题。
|
||||
|
||||
在程序世界中，乐观锁和悲观锁的最终目的都是为了保证线程安全，避免在并发场景下的资源竞争问题。但是，相比于乐观锁，悲观锁对性能的影响更大！
|
||||
|
||||
## 什么是悲观锁？
|
||||
|
||||
悲观锁总是假设最坏的情况，认为共享资源每次被访问的时候就会出现问题(比如共享数据被修改)，所以每次在获取资源操作的时候都会上锁，这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说，**共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程**。
|
||||
@ -31,34 +29,30 @@ try {
|
||||
}
|
||||
```
|
||||
|
||||
高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题，影响代码的正常运行。
|
||||
高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题（线程获得锁的顺序不当时），影响代码的正常运行。
|
||||
|
||||
## 什么是乐观锁？
|
||||
|
||||
乐观锁总是假设最好的情况，认为共享资源每次被访问的时候不会出现问题，线程可以不停地执行，无需加锁也无需等待，只是在提交修改的时候去验证对应的资源（也就是数据）是否被其它线程修改了（具体方法可以使用版本号机制或 CAS 算法）。
|
||||
|
||||
像 Java 中`java.util.concurrent.atomic`包下面的原子变量类（比如`AtomicInteger`、`LongAdder`）就是使用了乐观锁的一种实现方式 **CAS** 实现的。
|
||||
|
||||
|
||||
在 Java 中`java.util.concurrent.atomic`包下面的原子变量类（比如`AtomicInteger`、`LongAdder`）就是使用了乐观锁的一种实现方式 **CAS** 实现的。
|
||||
|
||||
|
||||
```java
|
||||
// LongAdder 在高并发场景下会比 AtomicInteger 和 AtomicLong 的性能更好
|
||||
// 代价就是会消耗更多的内存空间（空间换时间）
|
||||
LongAdder longAdder = new LongAdder();
|
||||
// 自增
|
||||
longAdder.increment();
|
||||
// 获取结果
|
||||
longAdder.sum();
|
||||
LongAdder sum = new LongAdder();
|
||||
sum.increment();
|
||||
```
|
||||
|
||||
高并发的场景下，乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。但是，如果冲突频繁发生（写占比非常多的情况），会频繁失败和重试（悲观锁的开销是固定的），这样同样会非常影响性能，导致 CPU 飙升。
|
||||
高并发的场景下，乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁问题，在性能上往往会更胜一筹。但是，如果冲突频繁发生（写占比非常多的情况），会频繁失败并重试，这样同样会非常影响性能，导致 CPU 飙升。
|
||||
|
||||
不过，大量失败重试的问题也是可以解决的，像我们前面提到的 `LongAdder`以空间换时间的方式就解决了这个问题。
|
||||
|
||||
理论上来说：
|
||||
|
||||
- 悲观锁通常多用于写比较多的情况下（多写场景，竞争激烈），这样可以避免频繁失败和重试影响性能，悲观锁的开销是固定的。不过，如果乐观锁解决了频繁失败和重试这个问题的话（比如`LongAdder`），也是可以考虑使用乐观锁的，要视实际情况而定。
|
||||
- 乐观锁通常多于写比较少的情况下（多读场景，竞争较少），这样可以避免频繁加锁影响性能。不过，乐观锁主要针对的对象是单个共享变量（参考`java.util.concurrent.atomic`包下面的原子变量类）。
|
||||
- 悲观锁通常多用于写比较多的情况（多写场景，竞争激烈），这样可以避免频繁失败和重试影响性能，悲观锁的开销是固定的。不过，如果乐观锁解决了频繁失败和重试这个问题的话（比如`LongAdder`），也是可以考虑使用乐观锁的，要视实际情况而定。
|
||||
- 乐观锁通常多用于写比较少的情况（多读场景，竞争较少），这样可以避免频繁加锁影响性能。不过，乐观锁主要针对的对象是单个共享变量（参考`java.util.concurrent.atomic`包下面的原子变量类）。
|
||||
|
||||
## 如何实现乐观锁？
|
||||
|
||||
@ -100,77 +94,21 @@ CAS 涉及到三个操作数：
|
||||
|
||||
当多个线程同时使用 CAS 操作一个变量时，只有一个会胜出，并成功更新，其余均会失败，但失败的线程并不会被挂起，仅是被告知失败，并且允许再次尝试，当然也允许失败的线程放弃操作。
|
||||
|
||||
Java 语言并没有直接实现 CAS，CAS 相关的实现是通过 C++ 内联汇编的形式实现的（JNI 调用）。因此， CAS 的具体实现和操作系统以及 CPU 都有关系。
|
||||
|
||||
`sun.misc`包下的`Unsafe`类提供了`compareAndSwapObject`、`compareAndSwapInt`、`compareAndSwapLong`方法来实现的对`Object`、`int`、`long`类型的 CAS 操作
|
||||
|
||||
```java
|
||||
/**
|
||||
* CAS
|
||||
* @param o 包含要修改field的对象
|
||||
* @param offset 对象中某field的偏移量
|
||||
* @param expected 期望值
|
||||
* @param update 更新值
|
||||
* @return true | false
|
||||
*/
|
||||
public final native boolean compareAndSwapObject(Object o, long offset, Object expected, Object update);
|
||||
|
||||
public final native boolean compareAndSwapInt(Object o, long offset, int expected,int update);
|
||||
|
||||
public final native boolean compareAndSwapLong(Object o, long offset, long expected, long update);
|
||||
```
|
||||
|
||||
关于 `Unsafe` 类的详细介绍可以看这篇文章：[Java 魔法类 Unsafe 详解 - JavaGuide - 2022](https://javaguide.cn/java/basis/unsafe.html) 。
|
||||
|
||||
## CAS 算法存在哪些问题？
|
||||
|
||||
ABA 问题是 CAS 算法最常见的问题。
|
||||
|
||||
### ABA 问题
|
||||
|
||||
如果一个变量 V 初次读取的时候是 A 值，并且在准备赋值的时候检查到它仍然是 A 值，那我们就能说明它的值没有被其他线程修改过了吗？很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回 A，那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 **"ABA"问题。**
|
||||
|
||||
ABA 问题的解决思路是在变量前面追加上**版本号或者时间戳**。JDK 1.5 以后的 `AtomicStampedReference` 类就是用来解决 ABA 问题的，其中的 `compareAndSet()` 方法就是首先检查当前引用是否等于预期引用，并且当前标志是否等于预期标志，如果全部相等，则以原子方式将该引用和该标志的值设置为给定的更新值。
|
||||
|
||||
```java
|
||||
public boolean compareAndSet(V expectedReference,
|
||||
V newReference,
|
||||
int expectedStamp,
|
||||
int newStamp) {
|
||||
Pair<V> current = pair;
|
||||
return
|
||||
expectedReference == current.reference &&
|
||||
expectedStamp == current.stamp &&
|
||||
((newReference == current.reference &&
|
||||
newStamp == current.stamp) ||
|
||||
casPair(current, Pair.of(newReference, newStamp)));
|
||||
}
|
||||
```
|
||||
|
||||
### 循环时间长开销大
|
||||
|
||||
CAS 经常会用到自旋操作来进行重试，也就是不成功就一直循环执行直到成功。如果长时间不成功，会给 CPU 带来非常大的执行开销。
|
||||
|
||||
如果 JVM 能支持处理器提供的 pause 指令那么效率会有一定的提升，pause 指令有两个作用：
|
||||
|
||||
1. 可以延迟流水线执行指令，使 CPU 不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。
|
||||
2. 可以避免在退出循环的时候因内存顺序冲突而引起 CPU 流水线被清空，从而提高 CPU 的执行效率。
|
||||
|
||||
### 只能保证一个共享变量的原子操作
|
||||
|
||||
CAS 只对单个共享变量有效，当操作涉及跨多个共享变量时 CAS 无效。但是从 JDK 1.5 开始，提供了`AtomicReference`类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行 CAS 操作.所以我们可以使用锁或者利用`AtomicReference`类把多个共享变量合并成一个共享变量来操作。
|
||||
关于 CAS 的进一步介绍，可以阅读读者写的这篇文章：[CAS 详解](./cas.md)，其中详细提到了 Java 中 CAS 的实现以及 CAS 存在的一些问题。
|
||||
|
||||
## 总结
|
||||
|
||||
- 高并发的场景下，激烈的锁竞争会造成线程阻塞，大量阻塞线程会导致系统的上下文切换，增加系统的性能开销。并且，悲观锁还可能会存在死锁问题，影响代码的正常运行。乐观锁相比悲观锁来说，不存在锁竞争造成线程阻塞，也不会有死锁的问题，在性能上往往会更胜一筹。不过，如果冲突频繁发生（写占比非常多的情况），会频繁失败和重试，这样同样会非常影响性能，导致 CPU 飙升。
|
||||
- 乐观锁一般会使用版本号机制或 CAS 算法实现，CAS 算法相对来说更多一些，这里需要格外注意。
|
||||
- CAS 的全称是 **Compare And Swap（比较与交换）** ，用于实现乐观锁，被广泛应用于各大框架中。CAS 的思想很简单，就是用一个预期值和要更新的变量值进行比较，两值相等才会进行更新。
|
||||
- CAS 算法的问题：ABA 问题、循环时间长开销大、只能保证一个共享变量的原子操作。
|
||||
本文详细介绍了乐观锁和悲观锁的概念以及乐观锁常见实现方式：
|
||||
|
||||
- 悲观锁基于悲观的假设，认为共享资源在每次访问时都会发生冲突，因此在每次操作时都会加锁。这种锁机制会导致其他线程阻塞，直到锁被释放。Java 中的 `synchronized` 和 `ReentrantLock` 是悲观锁的典型实现方式。虽然悲观锁能有效避免数据竞争，但在高并发场景下会导致线程阻塞、上下文切换频繁，从而影响系统性能，并且还可能引发死锁问题。
|
||||
- 乐观锁基于乐观的假设，认为共享资源在每次访问时不会发生冲突，因此无须加锁，只需在提交修改时验证数据是否被其他线程修改。Java 中的 `AtomicInteger` 和 `LongAdder` 等类通过 CAS（Compare-And-Swap）算法实现了乐观锁。乐观锁避免了线程阻塞和死锁问题，在读多写少的场景中性能优越。但在写操作频繁的情况下，可能会导致大量重试和失败，从而影响性能。
|
||||
- 乐观锁主要通过版本号机制或 CAS 算法实现。版本号机制通过比较版本号确保数据一致性，而 CAS 通过硬件指令实现原子操作，直接比较和交换变量值。
|
||||
|
||||
悲观锁和乐观锁各有优缺点，适用于不同的应用场景。在实际开发中，选择合适的锁机制能够有效提升系统的并发性能和稳定性。
|
||||
|
||||
## 参考
|
||||
|
||||
- 《Java 并发编程核心 78 讲》
|
||||
- 通俗易懂 悲观锁、乐观锁、可重入锁、自旋锁、偏向锁、轻量/重量级锁、读写锁、各种锁及其 Java 实现！：<https://zhuanlan.zhihu.com/p/71156910>
|
||||
- 一文彻底搞懂 CAS 实现原理 & 深入到 CPU 指令：<https://zhuanlan.zhihu.com/p/94976168>
|
||||
|
||||
<!-- @include: @article-footer.snippet.md -->
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user