Concurrency on pipo's site

从 Future 到 CompletableFuture

Mon, 29 Dec 2025 15:37:35 +0800

使用 Future 完成多线程任务（ThreadPoolExecutor）

快速上手

创建线程池

ThreadPoolExecutor executor = new ThreadPoolExecutor(10, 20, 30, TimeUnit.SECONDS, queue, Executors.defaultThreadFactory());

完成多线程任务要执行的逻辑

// 创建一个新的类 实现 Callable 接口中的 call() 方法
public class Task implements Callable<Long> {
	@Override
	public Long call() throws Exception {
		System.out.println("the Thread name is " + Thread.currentThread().getName());
		return System.currentTimeMillis();
		}
}

创建 Future 实例提交任务
```
Future<Long> future = executor.submit(new Task());
```
⚠️ 注意 submit() 只是提交任务到线程池，并非立即执行任务，执行时机由线程池自行决定。

获取返回值

Long res = future.get(); // 阻塞式无限时返回
Long res = future.get(1, TimeUnit.SECONDS); // 阻塞式限时返回

代码实例：

// Task.java
	public class Task implements Callable<Long> {
		@Override
		public Long call() throws Exception {
			System.out.println("the Thread name is " + Thread.currentThread().getName());
			return System.currentTimeMillis();
			}
	}

// main
public static void main(String[] args) {
	BlockingQueue<Runnable> queue = new ArrayBlockingQueue<>(10);
	ThreadPoolExecutor executor = new ThreadPoolExecutor(10, 20, 30, TimeUnit.SECONDS, queue,                 Executors.defaultThreadFactory());
	//提交任务
	Future<Long> future = executor.submit(new Task());
	try {

		try {
			//阻塞式限时 1s 获取返回值
			System.out.println("the return value is " + future.get(1, TimeUnit.SECONDS));	
		} catch(TimeoutException e) {
		//超时取消任务
			future.cancel(true);
		} catch (ExecutionException e) {
			System.err.println("Task failed: " + e.getCause());
		} catch (InterruptedException e) {
			Thread.currentThread().interrupt();
			System.err.println("Main thread interrupted");
		}

	//关闭线程池	
	} finally {
		executor.shutdown(); // 禁止新任务
		try {
			// 等待已提交任务完成
			if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
			executor.shutdownNow(); // 取消正在执行的任务
			}
		} catch (InterruptedException e) {
			executor.shutdownNow(); // 被中断时强制关闭
			
			// 为什么要恢复中断状态？
		    // 因为 catch 住异常后，中断标志被清除了
		    // 如果上层代码也想知道 "发生过中断"，必须重新设置
			Thread.currentThread().interrupt(); // 恢复中断状态
		}
	}
	
	
	}

几个注意点

cancel(boolean mayInterruptIfRunning) 向任务发送 Thread.interrupt() 只有任务能够响应中断才有效

当 bool 为 false 时不中断当前正在执行的任务，只暂停未开始执行的任务
当 bool 为 true 时会中断当前正在执行的任务通用写法：

public Long call() throws Exception {
	while (!Thread.currentThread().isInterrupted()) { //
		try {
		//注意：这不是修改上面的 Task，而是展示一个通用写法。
		//  Task 瞬间执行完毕而且 return 不会循环检查，没有响应中断。
		// 在该例中不会被中断，因为没有可中断阻塞点和循环检查
			System.out.println("the Thread name is " + Thread.currentThread().getName());
			return System.currentTimeMillis();

		} catch(InterruptedException e) {
			Thread.currentThread().interrupt();
			System.err.println("thread interrupted");
		}
	}
}

可中断阻塞点是什么？调用 thread.interrupt() 会：将该线程的中断状态（interrupt status）设置为 true。如果线程正处于 sleep()、wait()、join() 等阻塞状态，会立即抛出 InterruptedException，并清除中断状态（变回 false）。

如何优雅关闭线程池

明晰 executor.shutdownNow() 与 executor.shutdown()

方法	shutdown()	shutdownNow()
线程池状态变化	不允许新任务提交，但已提交的任务继续执行	不允许新任务提交，且试图停止正在执行的任务
新任务提交	拒绝（抛出 RejectedExecutionException）	拒绝（抛出 RejectedExecutionException）
正在执行的任务	允许正常执行完成	尝试中断（调用 thread.interrupt()）
等待队列中的任务	会继续执行（队列任务会逐个取出执行）	不执行，直接从队列中移除并返回
中断行为	只中断空闲的线程（interruptIdleWorkers()）	中断所有工作线程（interruptWorkers()）
返回值	void（无返回值）	List ：返回队列中尚未开始执行的任务列表
适用场景	希望程序正常结束，不丢失任何已提交的任务	需要尽快停止，愿意牺牲队列中的任务
是否会等待任务结束	是（线程池会等到所有任务执行完才彻底终止）	否（立即尝试停止）

四步走关闭线程池：
1. 先优雅关闭 `shutdown()` 放在最外层，确保执行
2. 等待一定时间 `if(!executor.awaitTermination(5, TimeUnit.SECONDS))` 
3. 时间到后强行关闭 `shutdownNow()`
4. 包裹 2-3 catch 中断异常，防止意外退出未关闭线程池

实战示例

多线程并发执行任务 思路：

创建数组或 list
将任务通过 for 循环提交到线程池中
查看结果

框架:

//1.创建线程池
//2.创建待执行的任务队列 
List<Future<Long>> futures = new ArrayList<>();

try {
	//将任务提交到线程池
	for (int i = 0; i < n; i++) {
		futures.add(executor.submit(new Task()));	
	}
	for (Future<Long> future : futures) {
		//查看结果
	}
} finally {
	//关闭线程池
}

操作	关键代码	备注
定义任务	implements Callable	有返回值，能抛异常
提交任务	Future f = exec.submit(task)	异步，不阻塞
获取结果	f.get(1, TimeUnit.SECONDS)	阻塞，建议设超时
取消任务	f.cancel(true)	需要任务代码配合响应中断
大忌	在 submit 循环中直接 get	会变成串行

使用现代的 CompletableFuture 完成多线程任务

快速上手

创建线程池
创建逻辑（与 Future 不同，要实现 Supplier 接口的 get() 方法）
使用 CompletableFuture 提交任务
添加你要的操作代码实例：

try (ThreadPoolExecutor executor = new ThreadPoolExecutor(10, 20, 30, TimeUnit.SECONDS, queue, Executors.defaultThreadFactory())) {
	CompletableFuture<Long> cf = CompletableFuture.supplyAsync(new CFTask(), executor); 
	Long long1 = cf.join();
	System.out.println(long1);
} catch (Exception e) {
	// close thread pool
}

supplyAsync() 异步非阻塞提交任务

方法	阻塞？	异常处理
`get()`	✅ 阻塞	抛 checked exception（必须 try-catch）
`join()`	✅ 阻塞	抛 unchecked `CompletionException`（可不 catch）

常见的几种方法

创建异步任务


方法	作用	例子
supplyAsync(Supplier, Executor)	指定线程池执行，返回有结果的异步线程	cf = CompletableFuture.supplyAsync(() -> dbQuery(), myExecutor);
runAsync(Runnable, Executor)	无返回值异步任务，指定线程池	CompletableFuture.runAsync(() -> sendEmail());

supplyAsync 异步执行要有返回值，被执行的任务要去实现 Supplier 接口
runAsync 异步执行但无返回值，要实现 Runnable 接口

转换结果（链式处理的核心）

方法	作用	例子
thenApply(fn)	获取上一方法的返回值并执行逻辑，再次返回	.thenApply(user -> user.getName())
thenApplyAsync(fn)	异步转换（新线程）	常用
thenCompose(fn)	上一步返回另一个 CF → 扁平化（避免嵌套）	.thenCompose(id -> getOrderCF(id))
thenComposeAsync(fn)	异步扁平化	常用

thenApply vs thenCompose：

thenApply：函数返回普通值
thenCompose：函数返回 CompletableFuture（必须用这个才能链下去不嵌套）

消费结果（只关心结果，不返回新值）

方法	作用	例子
thenAccept(result -> …)	拿到结果处理（比如打印、存库）	.thenAccept(pname -> System.out.println(pname))
thenAcceptAsync(…)	异步消费
thenRun(() -> …)	不关心上一步结果，只做后续动作	.thenRun(() -> {System.out.println(“flushing”);}

异常处理

方法	作用
exceptionally(ex -> defaultValue)	出异常时返回备用值（继续链）
handle((result, ex) -> …)	无论正常还是异常都能处理，最灵活
whenComplete((result, ex) -> …)	只观察，不改变结果（常用于日志）
推荐优先用 handle 或 exceptionally。

两个任务组合

方法	作用
thenCombine(otherCF, (r1, r2) -> newResult)	两个任务都完成 → 合并结果
thenCombineAsync(…)	异步合并
thenAcceptBoth(otherCF, (r1, r2) -> …)	两个完成 → 消费，不返回
runAfterBoth(otherCF, () -> …)	两个完成 → 执行动作

多个任务全部完成

方法	作用
CompletableFuture.allOf(cf1, cf2, cf3…)	等待所有任务完成，返回 void 的 CF
CompletableFuture.anyOf(cf1, cf2…)	哪个最快完成就返回那个结果
等待 n 个任务方式：
`CompletableFuture.allof(futures.toArray(CompletableFuture[]::new)).join();` 或者
`CompletableFuture.allof(futures.toArray(CompletableFuture[0])).join();`

为什么要加 join()? 为了 阻塞等待所有任务完成, 如果不加 join 他会异步执行后续代码，未等待所有线程完成。

实战示例

练习 supplyAsync (发起) thenApply (加工) thenCombine(合并) exceptionally（异常处理） thenAccept (最终消费) 已有

    public static String queryDB(String queryName);
    public static String unsafeApi()

目标：

使用 queryDB 查询 username 查到结果后加入前缀 “Proccessed_”, 打印
使用 queryDB 查询 UserStats 和 OrderCounts 完成后组合结果合并成一个字符串 “UserStats + OrderCounts” 并打印
调用 unsafeApi() 如果发生错误，进行处理并且返回默认值 “Default_Safe_Data”

//task.1
CompletableFuture.supplyAsync(() -> 
					queryDB("username"), executor) //{ return queryDB("username");} 
					//此处加入 executor，后续会自动沿用这个线程，如果不使用 executor 会使用 forkjoinpool
				.thenApply(res -> { 
				//自己命名接收到的值然后进行处理
					return "Proccessed_" + res;
				})
				.thenAccept(name -> {
					System.out.println(name);
				});


//task.2
CompletableFuture<String> cf1 = CompletableFuture.supplyAsync(() -> queryDB("UserStats"), executor);
CompletableFuture<String> cf2 = CompletableFuture.supplyAsync(() -> queryDB("OrderCounts"), executor);
cf1.thenCombine(cf2, (cf1, cf2) -> { // thenCombine 会自动等待两个任务完成，不需要加 join() 或 get() 来强制等待
	return cf1 + ": " + cf2; 
})
.thenAccept(combined -> {
log("合并报表: " + combined); 
});
CompletableFuture.supplyAsync(() -> queryDB("UserStats"), executor).thenCombine()

//task.3
CompletableFuture.supplyAsync(() -> unsafeApi(), executor)
		.exceptionally((error) -> {
            log("error: " + error.getMessage());
            return "Default_Safe_Data";
        })
        .thenAccept(data -> System.out.println(data));

⚠️ 注意

thenApply 必须返回对象，不能是 void（比如只 println 不 return）。

异步异常必须处理，否则链会断掉

练习 allOf(Future… cfs) （聚合多任务）， completeOnTimeout() (超时控制) 已有
```
public static double fetchPrice(String platform);
public static List<Double> batchQuery(List<String> platforms){}
```
目的：
- 在 batchQuery() 中并发查询所有 platform
- 查询时长超过 2s 与错误的返回 -1
- 等待所有任务完成后，获取数据返回 List<Double>

public static List<Double> batchQuery(List<String> platforms) {

        ExecutorService executor = Executors.newFixedThreadPool(platforms.size());
        Double defaultValue = -1.0;
        List<Double> result = new ArrayList<>();
        try {
            List<CompletableFuture<Double>> futures = new ArrayList<>(); //创建数组用来查询和接收 N 个平台的数据

            for (String platform : platforms) { 
                futures.add(CompletableFuture.supplyAsync(() -> fetchPrice(platform), executor)
                        .exceptionally((e) -> {
                            System.err.println(platform + "  " + e.getMessage());
                            return -1.0; //报错，将异常吞掉，返回 -1 作为默认值
                        }).completeOnTimeout(defaultValue, 2, TimeUnit.SECONDS)); //(返回值， 时间， 单位)
            }
            //这里编排 有一些讲究
            //❌ ~~如果 completeOnTimeout 在 exceptionally 前，exceptionally 会接收到超时的报错~~ 
			//✅ exceptionally：会吞掉真实的异常，返回正常值。 
			// completeOnTimeout：不会抛异常，但它吞掉的不是“异常”，而是“超时未完成”的状态，直接转为正常完成 + 默认值。
			
			
			//⚠️ 着重 必须加 join 存放任务方式是 cf.toArray(CompletableFuture []::new)
            CompletableFuture.allOf(futures.toArray(CompletableFuture[]::new)).join();
            for (CompletableFuture<Double> future : futures) {
                result.add(future.join()); // 这里拿真正的结果
            }


            return result;

        } finally {
            executor.shutdown();
            try {
                if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
                    executor.shutdownNow();
                }
            } catch (InterruptedException e) {
                executor.shutdownNow();
                Thread.currentThread().interrupt();
            }

        }
    }

⚠️ 注意 CompletableFuture.allOf(futures.toArray(CompletableFuture[]::new)).join(); 返回值是 void 需要手动对单个任务获取 completeOnTimeout：不会抛异常，但它吞掉的不是“异常”，而是“超时未完成”的状态，直接转为正常完成 + 默认值。

Reference

ExecutorService (Java SE 17 & JDK 17)

Guide To CompletableFuture | Baeldung

Redis 生产问题

Sun, 19 Oct 2025 00:00:00 +0000

缓存穿透

指使用非法 key 进行请求, 这个 key 不存在于 Redis 缓存和数据库中. 导致数据库一直忙于处理非法 key 的查询请求.

1. 缓存空值

使用 Redis 缓存空值,将不存在的 key 加入缓存,之后直接在 Redis 被拦截.

优点 :实现简单,成本低.
缺点 : 大量不同非法 key 访问会占用大量 redis 缓存.
改进: 给空值 key 设置较短的过期时间或者加入布隆过滤器.

2. 布隆过滤器

使用布隆过滤器首先判断当前请求的数据是否存在, 若不存在直接拦截, “存在"后继续交由 redis 进行. 优点: bloomfilter 使用了散列算法"存储”,占用空间极小,速度快. 缺点: bloomfilter 会出现假阳性,同时无法删除数据. 改进: 使用缓存空值兜底,同时定期刷新写入真实的数据.

缓存击穿

1. 分布式锁

通过加入分布式只允许一个线程同时去访问数据库进行缓存重建,其他线程等待缓存好的数据. 步骤: A. redis 缓存未命中,尝试获取锁 B. 获取锁成功,进行双重检查 C. 查询数据库 D.重新加入 Redis 缓存 (若为空则构造空值)

缺点:

导致大量用户被堵塞,体验较差.
锁竞争激烈时，性能下降
如果锁未正确释放（如程序崩溃），可能导致死锁

改进:

使用 Redis 的 SET key value NX PX milliseconds 命令原子操作加锁。
加锁失败时，不要无限等待，可以返回“稍后再试”或“默认值”。

2.逻辑过期 + 异步更新

在非强一致性场景下,缓存数据时加入逻辑过期时间,若发生过期则先返回旧数据,同时获取分布式锁进行异步更新缓存. 步骤: A. redis 缓存命中, 但此时逻辑过期 B. 返回旧数据,同时尝试获取锁. C. 开启子线程,进行双重检查 D. 重构缓存缺点:

复杂度较高, 需要维护逻辑过期字段、异步线程、锁机制
用户可能无法及时获取到最新数据.
内存占用略高,因为缓存不会真正过期，除非手动清理。

改进:

对缓存设置较长的过期时间,大于逻辑过期时间.

3. 缓存预热

针对热点数据提前预热，将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。

缓存雪崩

指缓存内同时出现大量 key 过期或者 Redis 奔溃重启,没有缓存任何key,导致大量的请求都直接落到了数据库上，对数据库造成了巨大的压力。

1. 随机过期时间

通过在 Redis 重构缓存时在过期时间中加入随机抖动使得过期时间均匀分散,避免了大量 key 同时过期的情况.

2. Redis 集群

通过构建 Redis 主从架构+哨兵机制实现, 当主节点下线后,哨兵会自动把从节点提升为主节点. 多个节点保证了不会出现缓存全部消失的情况.

**服务降级 & 熔断

当数据库压力过大时：

返回默认值（如“系统繁忙，请稍后再试”）。
启用本地缓存（如 Caffeine）作为二级缓存。
使用限流（如 Sentinel、Hystrix）保护数据库。

3.预热数据

Redis RDB & AOF

Fri, 17 Oct 2025 00:00:00 +0000

RDB

RDB是对 Redis 某一瞬间保存的全量快照,本质上是一份二进制文件,用来在 Redis 重启或丢失数据后进行恢复,通常用作数据恢复、主从全量同步以及定期备份.

执行方式

1.手动

可以通过 `SAVE` 与 `BGSAVE` 手动执行 RDB 备份, `SAVE` 命令会在主线程内进行备份操作,此时Redis主线程会被堵塞直到写入 RDB 完成.
使用 `BGSAVE` 时 则是通过 `fork` 一个子线程进行写时复制写入硬盘,不会造成 Redis 主线程堵塞.

Copy-On-Write（写时复制） 是一种 优化内存使用和提升性能的系统级技术，广泛用于操作系统（如 Linux）、数据库、虚拟化等领域。

多个进程/线程共享同一份物理内存，只有当某个进程试图“修改”数据时，才真正复制一份私有副本。

读操作：直接共享原始数据，无需复制；

写操作：触发复制，之后修改的是副本，不影响原数据。

2. 自动(通过配置文件)

Redis 支持通过在 redis.conf 文件中配置 save 选项，让服务器每隔一段时间自动执行一次 BGSAVE 命令。save 选项可以设置多个保存条件，只要其中任意一个条件被满足，服务器就会执行 BGSAVE 命令。

【示例】redis.conf 中自动保存配置

# 900 秒内，至少对数据库进行了 1 次修改
save 900 1
# 300 秒内，至少对数据库进行了 10 次修改
save 300 10
# 60 秒内，至少对数据库进行了 10000 次修改
save 60 10000

只要满足以上任意条件，Redis 服务就会执行 BGSAVE 命令。

RDB 优缺点

优点

重启后加载快, 相比 AOF 命令执行式恢复, RDB本质就是压缩过的二进制文件,只需要将其全部读入内存即可.
相比 AOF RDB空间利用率更高.

缺点

备份频率较低,每次只能全量备份,如果在备份开始前发生故障,会导致丢失大量数据,无法满足强一致性.
备份时间长,如果数据量很大，保存快照的时间会很长.

AOF（Append Only File）

AOF 是 Redis 的另一种持久化机制，它通过记录服务器接收到的每一个写命令，以日志形式追加到文件末尾。在 Redis 重启时，通过重新执行 AOF 文件中的命令来恢复数据。AOF 文件是可读的文本格式，通常用于对数据安全性要求较高的场景。

执行方式

1. 手动

开启 AOF：默认关闭，需在 redis.conf 中设置 appendonly yes。
重写 AOF：执行 BGREWRITEAOF 命令，Redis 会 fork 一个子进程，根据当前数据库状态生成一个更紧凑的新 AOF 文件（利用 Copy-On-Write 机制，不阻塞主线程）。

2. 自动（通过配置文件）

AOF 的同步策略由 appendfsync 配置项控制，决定写命令何时从缓冲区刷入磁盘：

# 每次写操作都同步到磁盘（最安全，性能最差）
appendfsync always

# 每秒同步一次（默认推荐，平衡安全与性能）
appendfsync everysec

# 由操作系统决定何时同步（性能最好，但可能丢失较多数据）
appendfsync no

此外，AOF 重写也可自动触发，通过以下配置：

# 当 AOF 文件大小超过上一次重写后大小的指定百分比时，自动触发重写
auto-aof-rewrite-percentage 100
# AOF 文件至少达到指定大小（字节）才触发自动重写
auto-aof-rewrite-min-size 64mb

AOF 优缺点

优点

数据更安全：everysec 模式下最多丢失 1 秒数据，always 模式可做到几乎零丢失。
可读可编辑：AOF 是纯文本格式，若误操作（如误删 key），可手动修改文件删除对应命令后恢复。
自动压缩：通过重写机制，可将冗余命令（如多次 INCR）合并为一条 SET，减小文件体积。

缺点

文件体积大：相比 RDB，AOF 通常更大（尽管重写可优化）。
恢复速度慢：需逐条重放命令，大数据集下恢复时间远长于 RDB。
性能开销：尤其在 always 模式下，每次写操作都需同步磁盘，影响吞吐量。

JMM

Mon, 13 Oct 2025 00:00:00 +0000

JMM

1. 什么是 JMM？

Java 内存模型（JMM）是一个抽象模型，它定义了线程和主内存之间的抽象关系。JMM 的核心目的是屏蔽各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果，为开发者提供清晰的并发编程保证。

2. JMM 的核心抽象

JMM 通过以下概念来抽象内存交互：

主内存：所有线程共享的区域，存储了所有的实例字段、静态字段和构成数组对象的元素。
本地内存：每个线程私有的区域，是 JMM 的一个抽象概念。它存储了该线程对主内存变量的副本。
通信原则：线程间的通信必须通过主内存进行。一个线程将本地内存的变量副本写入主内存，另一个线程再从主内存读取到最新的值。

3. JMM 诞生的原因

JMM 的出现主要是为了解决现代计算机体系结构带来的两个核心问题：

CPU 缓存导致的可见性问题：为了提高速度，每个 CPU 都有自己的高速缓存。当多个线程运行在不同 CPU 上时，它们可能各自持有一个共享变量的缓存副本，导致一个线程的修改对另一个线程不可见。尽管硬件层面有缓存一致性协议（如 MESI）来协调，但 JMM 提供了更高层、更强的可见性保证。
指令重排导致的有序性问题：为了优化性能，编译器和处理器可能会对输入的代码进行指令重排序。在单线程环境下，重排序不会影响最终结果，但在多线程环境下，可能会破坏代码原有的执行逻辑，导致意想不到的结果。

4. JMM 的核心工具：Happens-Before 原则

happens-before 是 JMM 中最核心的概念，它定义了两个操作之间的偏序关系。如果操作 A happens-before 操作 B，那么 A 操作的执行结果对 B 操作是可见的，且 A 操作的执行顺序在 B 操作之前。

目的：happens-before 原则主要用于保证并发环境下的可见性和有序性。

常见规则：

程序顺序规则：在一个线程内，书写在前面的代码操作 happens-before 书写在后面的代码操作。
监视器锁规则：对一个锁的解锁操作 happens-before 后续对同一个锁的加锁操作。
volatile 变量规则：对一个 volatile 变量的写操作 happens-before 后续对该变量的读操作。
传递性：如果 A happens-before B，且 B happens-before C，那么 A happens-before C。
线程启动规则：线程的 start() 方法 happens-before 于此线程的每一个动作。
线程终止规则：线程中的所有操作都 happens-before 对此线程的终止检测。
线程中断规则：对线程 interrupt() 方法的调用 happens-before 发生于被中断线程的代码检测到中断时。
对象终结规则：一个对象的初始化完成（构造函数执行结束）happens-before 它的 finalize() 方法的开始。

总结

JMM 通过抽象出主内存和本地内存，并提供一套 happens-before 规则，成功地为 Java 开发者屏蔽了底层硬件的复杂性。理解 JMM 有助于我们编写出正确、可靠的并发程序，避免可见性和有序性带来的问题。

volatile & synchronized

Mon, 13 Oct 2025 00:00:00 +0000

volatile 关键字是 Java 并发编程中的一个基础且至关重要的概念。它就像是 Java 虚拟机 ([[JVM]]) 和底层硬件之间立下的一份“契约”，专门用于解决多线程环境下共享变量的可见性（Visibility）和有序性（Ordering）问题。

一、 `volatile` 的含义及在 Java 中的作用

1. 单词的意思（Literal Meaning）

在 Java 中，volatile 关键字用来标记一个 Java 变量是 “存储在主内存中"（“being stored in main memory”）的。它指示 JVM，这个变量是共享且不稳定的。

2. 它在 Java 中干什么（核心机制）

volatile 的核心作用是强制读写操作直接与主内存进行交互，从而解决了由于 CPU 缓存和指令重排序带来的并发问题。

A. 解决可见性问题（强制内存访问）

由于现代 CPU 为了性能，会将变量副本存储在 CPU 寄存器或缓存中。如果变量未被声明为 volatile，线程在操作共享变量时，对主内存的读写时间是不确定的。

读取操作： 对 volatile 变量的每一次读取都将直接从计算机的主内存中读取，而不是从 CPU 寄存器中读取。
写入操作： 对 volatile 变量的每一次写入都将立即被写入到主内存中，而不仅仅是写入到 CPU 寄存器或写缓冲区中。

通过这种方式，volatile 确保了当一个线程更新变量值时，处理器会立即刷新这些更新，保证其他线程随后读取时能看到这个最新值。

B. 解决有序性问题（禁止指令重排序）

编译器、运行时环境或处理器可能会对指令进行重排序以优化性能。volatile 变量是与运行时和处理器进行通信，以避免重排序任何涉及该 volatile 变量的指令。

它通过插入内存屏障 (Memory Barrier) 来实现这一目标。内存屏障就像一道墙，禁止某些类型的处理器重排序。

二、 `volatile` 保证了什么？（核心承诺）

volatile 关键字提供了 Java 内存模型 ([[Java/Concurrency/JMM|JMM]]) 规定的两大核心保证：

1. 内存可见性（Visibility Guarantee）

这是 volatile 最主要也是最基础的保证。

一致性保证： volatile 保证了所有线程看到的共享变量的值是一致的。当对 volatile 字段进行更新后，该字段的共享值会立即更新，其他线程不会获取到不一致的值。
完整可见性保证（Full Volatile Visibility Guarantee）： volatile 的可见性保证甚至延伸到了变量本身之外。
- 如果线程 A 写入一个 volatile 变量，随后线程 B 读取了它，那么在 A 写入该 volatile 变量之前对所有其他变量所做的更改，对 B 来说都是可见的。
- 类似地，当线程 A 读取 volatile 变量时，所有对线程 A 可见的变量都会被强制重新从主内存读取。

2. 有序性与 Happens-Before 关系

volatile 关键字提供了 Java 内存模型中的 Happens-Before 保证。

Volatile 变量规则： 对一个 volatile 变量的写操作 Happens-Before 后面对这个 volatile 变量的读操作。
重排序约束：
- 写入屏障： 发生在 volatile 变量写入之前对其他变量的读写，不能被重排到 volatile 写入之后发生。
- 读取屏障： 发生在 volatile 变量读取之后对其他变量的读写，不能被重排到 volatile 读取之前发生。

3. 对 64 位值操作的原子性保障

[[Java/Concurrency/JMM|JMM]] 对 64 位值（如 long 和 double）的访问原子性有所放宽，因为在某些 32 位平台上，读写 64 位值可能需要两次内存事务，导致操作非原子。

volatile 作为一种逃生出口（escape hatch），可以用来强制确保 64 位值的访问原子性。
如果代码可能在 32 位平台上运行，开发者必须使用 volatile 关键字来保障 64 位操作的可移植性。

三、什么时候使用 `volatile`？（适用场景）

volatile 是一个轻量级的同步机制，适用于只需要保证可见性和有序性，但不需要互斥的场景。

单写多读场景 (State Flag)：当只有一个线程会修改（写入）变量的值，而其他所有线程只负责读取该变量时，volatile 是足够的。

class Server {
    // 状态标志：只有一个线程会把它设为 true
    private volatile boolean isRunning = true;

    public void shutdown() {
        this.isRunning = false; // 单写操作
    }

    public void doWork() {
        while (isRunning) { // 多读操作
            // ... 执行任务
        }
        System.out.println("Server has been shut down.");
    }
}

值不依赖于旧值： 即使有多个线程写入 volatile 变量，只要写入的新值不依赖于其旧值（例如，设置一个布尔状态标记，而不是计数器递增），volatile 也是足够的。
替代重量级锁： 当应用程序需要确保数据的可见性方面，但同时又希望避免 synchronized 方法和块带来的性能开销时，volatile 很有用。
“搭便车"技巧 (Piggybacking)：利用 volatile 带来的 happens-before 顺序性，将普通变量的写入放在 volatile 变量写入之前，可以使普通变量的可见性“搭上” volatile 变量的便车。

四、什么时候不使用 `volatile`？（局限性与替代方案）

volatile 具有明显的局限性，在需要复杂同步时，不应单独依赖它。

1. 不能保证互斥性（Mutual Exclusion）

volatile 字段的读写不会阻塞其他线程的读写操作。
volatile 关键字不提供互斥（mutual exclusion），即它不能保证在任何时刻只有一个线程执行关键代码段。

2. 无法保障复合操作的原子性

一旦线程需要先读取 volatile 变量的值，然后根据该值生成一个新的值（即复合操作，如 i++ 或 count = count + 1），单独的 volatile 就不够了。
在读取和写入新值之间的短暂时间差内，会产生竞态条件（race condition），多个线程可能读取到相同的值，导致相互覆盖，最终结果错误。
替代方案： 在这种需要原子性（读取和写入是一个不可分割操作）的情况下，必须使用：
- synchronized 块或方法。
- java.util.concurrent 包中的各种原子数据类型，如 AtomicLong 或 AtomicReference。

3. 性能考量

访问 volatile 变量会将其读写到主内存，这比访问 CPU 寄存器更昂贵。
volatile 还会阻止指令重排序，而指令重排序是常见的性能增强技术。
因此，应该只在真正需要强制变量可见性时才使用 volatile 变量，以避免不必要的同步开销。

class UnsafeCounter {
    // 即使使用了 volatile，也无法保证正确性
    private volatile int count = 0;

    public void increment() {
        count++; // 这不是原子操作！它包含三步：
                 // 1. 读取 count 的值
                 // 2. 将值加 1
                 // 3. 写入新值
    }

    public int getCount() {
        return count;
    }
}

特性	`volatile`	`synchronized`	`AtomicInteger` (原子类)
保证可见性	✅ 是	✅ 是	✅ 是
保证有序性	✅ 是 (禁止重排序)	✅ 是	✅ 是
保证原子性	❌ 否 (仅限单次读/写)	✅ 是 (代码块)	✅ 是 (特定操作)
互斥/阻塞	❌ 否 (非阻塞)	✅ 是 (阻塞)	❌ 否 (非阻塞，CAS)
性能开销	较低	较高	较低 (通常优于 `volatile`)
适用场景	状态标志、单写多读	复杂同步逻辑、临界区保护	计数器、累加等复合操作

synchronized 关键字是 Java 并发编程的基石，它提供了一种强大而直接的同步机制。它就像是为一间“共享资源室”配备的“唯一钥匙”，专门用于解决多线程环境下的原子性、可见性和有序性问题，其核心是互斥访问。

一、 `synchronized` 的含义及在 Java 中的作用

1. 意思

synchronized 的字面意思是“同步的”。在 Java 中，它用于确保一段代码或一个方法在同一时刻最多只有一个线程能执行它。

2. 它在 Java 中干什么（核心机制）

synchronized 的核心作用是实现线程间的互斥，它通过一个叫做监视器锁 的东西来实现。

监视器锁：每个 Java 对象都可以作为一个锁，这个锁就是对象的内置锁或监视器锁。当线程试图进入一个被 synchronized 保护的代码块时，它必须先获取该代码块所关联对象的锁。
锁的获取与释放：
- 获取锁：如果锁未被其他线程持有，当前线程会获取锁并进入代码块执行。
- 阻塞等待：如果锁已被其他线程持有，当前线程将被阻塞，并进入锁的等待队列，直到锁被释放。
- 释放锁：当线程执行完 synchronized 代码块或方法，或者在代码块中抛出异常时，锁会自动被释放。

二、 `synchronized` 保证了什么？（核心承诺）

synchronized 关键字提供了三大核心保证，比 volatile 更为强大。

1. 原子性

这是 synchronized 最核心的保证。

互斥执行：synchronized 确保被它保护的代码块（临界区）是原子的。一个线程一旦进入该代码块，在它退出之前，其他任何线程都无法进入。这从根本上杜绝了竞态条件。
类比：就像一个只有一把钥匙的洗手间。一个人进去后锁上门（获取锁），在里面无论待多久，外面的人都只能排队等待（阻塞）。直到他出来并交出钥匙（释放锁），下一个人才能进去。

2. 内存可见性

volatile 保证可见性，synchronized 同样保证，而且更强。

Happens-Before 保证：[[Java/Concurrency/JMM|JMM]] 规定，对一个锁的解锁操作 [[Java/Concurrency/JMM#^444be5|Happens-Before]] 后面对同一个锁的加锁操作。
强制刷新：这意味着，当线程 A 释放锁时，[[Java/Concurrency/JMM|JMM]] 会强制将该线程工作内存中的所有共享变量的最新值刷新到主内存。而当线程 B 随后获取同一个锁时，[[Java/Concurrency/JMM|JMM]] 会强制将该线程的工作内存置为无效，使其必须从主内存中重新读取所有共享变量的值。
效果：这确保了前一个线程对共享变量的修改，对后一个获取锁的线程是立即可见的。

3. 有序性

volatile 通过内存屏障禁止指令重排，synchronized 通过其“原子性”隐式地保证了有序性。

隐式保证：由于 synchronized 块内的代码与块外的代码是互斥执行的，一个线程在 synchronized 块内观察到的状态，一定是另一个线程在之前或之后同步块内操作的结果。[[Java/Concurrency/JMM|JMM]] 可以在保证最终结果正确性的前提下，对 synchronized 块内的代码进行重排序，但它绝不会允许块内的代码“[[Runtime Data Area#Escape|逃逸]]”到块外，从而破坏整体的同步语义。

4. 可重入性

这是 synchronized 一个非常重要的特性。

定义：一个已经获取到锁的线程，可以再次进入由它自己持有的锁所保护的任何代码块，而不会造成死锁。
机制：JVM 会为每个锁关联一个持有计数器和一个持有线程。当一个线程获取锁时，计数器加一。当同一线程再次获取时，计数器再次加一。当线程退出同步块时，计数器减一。直到计数器为 0 时，锁才被真正释放。
意义：可重入性极大地简化了代码编写，避免了因在同步方法中调用另一个同步方法而导致的自我死锁。

三、什么时候使用 `synchronized`？（适用场景）

synchronized 是一个重量级的同步工具，适用于需要强一致性保证的场景。

保护临界区：当多个线程需要访问和修改共享资源（如共享的数据结构、文件、设备等）时，必须使用 synchronized 来保护访问这些资源的代码块。
保证复合操作的原子性：对于像 check-then-act（检查再操作，如单例模式的懒加载）或 read-modify-write（读取再修改，如 i++）这样的复合操作，volatile 无能为力，synchronized 是最直接的解决方案。
实现简单的线程安全类：在创建自定义的线程安全容器或工具类时，synchronized 是最基础、最可靠的实现手段。

三种使用方式

public class MySynchronizedClass {

    // 1. 修饰实例方法，锁是当前实例对象 (this)
    public synchronized void instanceMethod() {
        // 临界区代码
        System.out.println("Instance method. Lock on: " + this);
    }

    // 2. 修饰静态方法，锁是当前类的 Class 对象 (MySynchronizedClass.class)
    public static synchronized void staticMethod() {
        // 临界区代码
        System.out.println("Static method. Lock on: " + MySynchronizedClass.class);
    }

    private final Object lockObject = new Object(); // 专用锁对象

    public void blockMethod() {
        // 3. 修饰代码块，锁是指定的对象 (lockObject)
        synchronized (lockObject) {
            // 临界区代码
            System.out.println("Code block. Lock on: " + lockObject);
        }
    }
}

四、什么时候不使用 `synchronized`？（局限性与替代方案）

synchronized 虽然强大，但其“重量级”的特性也带来了局限。

1. 性能开销

线程阻塞与上下文切换：当锁竞争激烈时，无法获取锁的线程会被阻塞，涉及从用户态到内核态的切换，这是一个非常昂贵的操作。
性能瓶颈：在高并发场景下，synchronized 容易成为系统的性能瓶颈。

2. 灵活性不足

不可中断：一个线程在等待获取 synchronized 锁时，不能被中断。
无法设置超时：无法设置一个线程等待锁的最长时间。
非公平锁：synchronized 是非公平的，即等待时间长的线程不一定能优先获取锁。

3. 替代方案

为了克服 synchronized 的局限性，Java 提供了更灵活、更高效的并发工具。

volatile：当只需要保证可见性和有序性，而不需要互斥访问时，volatile 是更轻量级的选择。
java.util.concurrent.atomic 包：对于单个变量的原子性复合操作（如计数器），AtomicInteger 等原子类基于 CAS（Compare-And-Swap）操作，通常比 synchronized 性能更好。
java.util.concurrent.locks.Lock 接口：提供了更高级的锁功能，如可中断的锁获取（lockInterruptibly()）、可超时的锁获取（tryLock()）和公平锁（ReentrantLock 的构造函数参数）。它为复杂并发场景提供了更精细的控制。

核心要点总结（一图流）

特性	`synchronized`	`java.util.concurrent.locks.Lock`
保证原子性	✅ 是	✅ 是
保证可见性	✅ 是	✅ 是
保证有序性	✅ 是	✅ 是
互斥/阻塞	✅ 是 (阻塞)	✅ 是 (阻塞)
可重入	✅ 是	✅ 是 (如 `ReentrantLock`)
可中断	❌ 否	✅ 是 (`lockInterruptibly()`)
可超时	❌ 否	✅ 是 (`tryLock()`)
公平性	❌ 否 (仅非公平)	✅ 是 (可选公平/非公平)
使用方式	关键字 (JVM 实现，自动释放)	接口 (API 调用，需手动 `unlock()`)
性能开销	较高 (JDK 6 后大幅优化)	通常较低，但依赖具体实现

乐观锁 & 悲观锁

Sun, 12 Oct 2025 00:00:00 +0000

悲观锁

悲观锁的核心思想是在共享资源被操作时假设冲突一定会发生全部都加锁.

实现方式

synchronized : Java 中的关键字，可以修饰方法或代码块，保证同一时刻只有一个线程可以执行被修饰的代码。
ReentrantLock: Java java.util.concurrent.locks 包下的一个类，提供了比 synchronized 更广泛的锁操作。例如，它可以实现公平锁、非公平锁，可以被中断地获取锁等。

缺点

多个线程在持有锁并请求对方已持有的锁时，会造成相互等待，导致所有线程都无法继续执行。
当一个线程获取锁失败后，会被阻塞（挂起），操作系统需要将其从运行态切换到等待态。当锁被释放时，又需要将等待的线程唤醒，这个线程上下文的切换会消耗一定的 CPU 资源。
只要有一个线程持有了锁，其他所有想要访问该资源的线程都必须等待，这会降低系统的并发性能和吞吐量。

适用场景

适合写多读少的情况,因为读操作并不对资源进行修改不会出现线程问题,而写操作要求强数值一致性所以适合悲观锁.

乐观锁

它总是假设最好的情况，认为数据在被自己操作时不会被其他线程修改。所以它不会加锁，而是在更新数据时，去检查在此期间有没有其他线程修改过数据。

实现方式

concurrent.atomic: Java 的 java.util.concurrent.atomic 包下的一系列原子类，如 AtomicInteger, AtomicLong 等。它们内部使用了 CAS 机制来实现原子操作。

机制

版本控制

在数据库中加入版本属性,当线程操作时需要携带当前操作数据的版本号,操作完成后比较此时版本与数据库中版本是否相同.

CAS(Compare And Swap)

CAS 是一个原子操作，底层依赖于一条 CPU 的原子指令。

原子操作 即最小不可拆分的操作，也就是说操作一旦开始，就不能被打断，直到操作完成。

CAS 涉及到三个操作数：

V：要更新的变量值(Var)
E：预期值(Expected)
N：拟写入的新值(New)

当且仅当 V 的值等于 E 时，CAS 通过原子方式用新值 N 来更新 V 的值。如果不等，说明已经有其它线程更新了 V，则当前线程放弃更新。

来源

Javaguide# 乐观锁和悲观锁详解

Concurrency on pipo's site

从 Future 到 CompletableFuture

使用 Future 完成多线程任务 （ThreadPoolExecutor）

快速上手

几个注意点

实战示例

使用现代的 CompletableFuture 完成多线程任务

快速上手

常见的几种方法

创建异步任务

转换结果（链式处理的核心）

消费结果（只关心结果，不返回新值）

异常处理

两个任务组合

多个任务全部完成

实战示例

Reference

Redis 生产问题

缓存穿透

1. 缓存空值

2. 布隆过滤器

缓存击穿

1. 分布式锁

2.逻辑过期 + 异步更新

3. 缓存预热

缓存雪崩

1. 随机过期时间

2. Redis 集群

**服务降级 & 熔断

Redis RDB & AOF

RDB

执行方式

1.手动

2. 自动(通过配置文件)

RDB 优缺点

优点

缺点

AOF（Append Only File）

执行方式

1. 手动

2. 自动（通过配置文件）

AOF 优缺点

优点

缺点

JMM

JMM

1. 什么是 JMM？

2. JMM 的核心抽象

3. JMM 诞生的原因

4. JMM 的核心工具：Happens-Before 原则

总结

volatile & synchronized

一、 volatile 的含义及在 Java 中的作用

1. 单词的意思（Literal Meaning）

2. 它在 Java 中干什么（核心机制）

A. 解决可见性问题（强制内存访问）

B. 解决有序性问题（禁止指令重排序）

二、 volatile 保证了什么？（核心承诺）

1. 内存可见性（Visibility Guarantee）

2. 有序性与 Happens-Before 关系

3. 对 64 位值操作的原子性保障

三、 什么时候使用 volatile？（适用场景）

四、 什么时候不使用 volatile？（局限性与替代方案）

1. 不能保证互斥性（Mutual Exclusion）

2. 无法保障复合操作的原子性

3. 性能考量

一、 synchronized 的含义及在 Java 中的作用

1. 意思

2. 它在 Java 中干什么（核心机制）

二、 synchronized 保证了什么？（核心承诺）

1. 原子性

2. 内存可见性

3. 有序性

4. 可重入性

三、 什么时候使用 synchronized？（适用场景）

三种使用方式

四、 什么时候不使用 synchronized？（局限性与替代方案）

1. 性能开销

2. 灵活性不足

3. 替代方案

使用 Future 完成多线程任务（ThreadPoolExecutor）

一、 `volatile` 的含义及在 Java 中的作用

二、 `volatile` 保证了什么？（核心承诺）

三、什么时候使用 `volatile`？（适用场景）

四、什么时候不使用 `volatile`？（局限性与替代方案）

一、 `synchronized` 的含义及在 Java 中的作用

二、 `synchronized` 保证了什么？（核心承诺）

三、什么时候使用 `synchronized`？（适用场景）

四、什么时候不使用 `synchronized`？（局限性与替代方案）