JAVA 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

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# 乐观锁和悲观锁详解

GC 垃圾回收

Sat, 27 Sep 2025 00:00:00 +0000

GC（Garbage Collection）是 JVM 中实现自动内存管理的一类机制的统称，其具体实现包括 Parallel、G1、ZGC 等垃圾回收器。GC 主要作用于堆（Heap）内存——在新生代执行 Minor GC，在老年代触发 Major GC 或 Full GC****。虽然 GC 不直接管理直接内存，但会间接影响其回收（例如通过 GC 触发 Cleaner 释放 DirectByteBuffer）。在 JVM 架构中，GC 与运行时数据区（Runtime Data Area）、执行引擎（Execution Engine）、本地方法接口（Native Method Interface）等组件协同工作，共同支撑 Java 程序的运行。

什么是可被回收的,如何判断?

引用计数器

通过一个计数器标记一个对象被引用的次数来判断是否进行垃圾回收,当引用数量为 0 时在垃圾回收时将会进行回收.

问题: 出现循环引用时将导致无法释放内存.

如 A 引用 B,B 引用 A.

可达性分析算法

GC 会从一组“GC 根”（GCRoots）出发，沿着引用链一路向下找到所有可达对象。这些可达对象被认为是“存活”的，不会被回收。其他不可达的对象（被称为“可回收对象”）则有资格被回收。

GC Roots

GC Roots 是一组在Java虚拟机中被直接引用的对象，是垃圾收集器从它们开始遍历所有可达对象（即存活对象）的起点

来源包括（但不限于）：

栈中的引用（局部变量、方法参数）

public void method() {
    Object localObj = new Object(); // localObj 是 GC Root
    String str = "hello";           // str 是 GC Root
    // 这些变量在栈帧中，直接引用堆中的对象
}

public void process(Object param) {
    // param 是 GC Root，引用传入的对象
}

public String concat(String a, String b) {
    return a + b; // 编译器可能生成临时变量引用中间结果
}

Meta Space 中的静态 (static) 变量和常量引用对象

public class MyClass {
    private static Object staticField = new Object(); // 静态字段是 GC Root
    public static final String CONSTANT = "constant"; // 静态常量也是 GC Root
}

// 即使没有 MyClass 的实例，staticField 仍然可达

public class Constants {
    // 字符串常量池中的对象
    String s1 = "literal"; // "literal" 对象被常量池引用，是 GC Root
    String s2 = new String("created"); // "created" 也在常量池中
}

JNI 环境引用

// C/C++ 本地代码
JNIEXPORT void JNICALL Java_MyClass_nativeMethod
  (JNIEnv *env, jobject obj) {
    // 通过 JNI 创建的全局引用或局部引用
    // 这些引用的对象都是 GC Root
    jobject globalRef = (*env)->NewGlobalRef(env, someObject);
}


public class HeapHprofBinWriter extends AbstractHeapGraphWriter {

    // hprof binary file header
    private static final String HPROF_HEADER_1_0_2 = "JAVA PROFILE 1.0.2";
    //    .....
    private static final int HPROF_GC_ROOT_UNKNOWN       = 0xFF;
    private static final int HPROF_GC_ROOT_JNI_GLOBAL    = 0x01;
    private static final int HPROF_GC_ROOT_JNI_LOCAL     = 0x02;
    private static final int HPROF_GC_ROOT_JAVA_FRAME    = 0x03;
    private static final int HPROF_GC_ROOT_NATIVE_STACK  = 0x04;
    private static final int HPROF_GC_ROOT_STICKY_CLASS  = 0x05;
    private static final int HPROF_GC_ROOT_THREAD_BLOCK  = 0x06;
    private static final int HPROF_GC_ROOT_MONITOR_USED  = 0x07;
    private static final int HPROF_GC_ROOT_THREAD_OBJ    = 0x08;
    //    .....
}

方法区回收(或Meta Space)

finalize()

GC 主要作用范围

Heap

堆内的垃圾收集算法主要基于分代收集法，根据对象的生命周期长短将内存分为年轻代和老年代，分别采用不同的收集策略，以提高垃圾收集的效率。

部分 GC

部分 GC (Partial GC) 是指不完整的垃圾收集，只针对堆的特定部分进行收集。主要包括 Young GC 和 Old GC。

Young GC

仅作用于 Young generation 的垃圾收集，每次将可回收内存标记回收，存活内存移入 Survivor 区域。由于大多数对象的生命周期较短，Young GC 发生频繁但速度较快。

Old GC (Major GC) 是指只针对老年代进行的垃圾收集。通常会导致应用程序暂停，但发生频率低于 Young GC。当老年代空间不足时触发。

Full GC

Full GC 是对整个堆进行垃圾收集，包括年轻代、老年代和元空间（JDK 8 之前称为永久代）。Full GC 的暂停时间通常较长，会导致应用程序长时间停顿，影响用户体验。

混合 GC (Mixed GC)

G1 收集器特有的收集方式，既会收集年轻代也会收集部分老年代。G1 通过将堆分成多个区域（Region），每次收集时可以有选择地收集部分区域，减少停顿时间。

MetaSpace

MetaSpace 使用的是本地内存，不在 JVM 堆中。它主要用于存储类的元数据信息，如类结构、方法数据、常量池等。MetaSpace 的垃圾收集通常在 Full GC 时进行。

引用类型

StrongReference

Java 中最常见最普通的引用方式，比如：

Foo foo = new Foo();

这个 foo 就是一个强引用。只要存在这样的强引用链路指向 Foo 对象，GC 就不会回收它,即使发生 OOM,

几乎所有日常编码用到的对象引用都是强引用。

SoftReference

Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);
obj = null;  // 使对象只被软引用关联

如果一个对象只有软引用可达（即没有强引用链路指向它），JVM 并不一定立刻回收它。只有在内存紧张、垃圾回收器判断“需要腾出空间”的时候，才可能清除这些对象。

用途通常是缓存（cache）例如你希望保留一个对象作为缓存，但如果 JVM 内存紧张，希望它被垃圾回收掉，而不是导致 OOM。

WeakReference

Object obj = new Object();
WeakReference<Object> wf = new WeakReference<Object>(obj);
obj = null;

如果一个对象仅被弱引用可达（即没有强引用或软引用链路指向它），那么在下一次垃圾回收时，GC 就可以回收它，不要保留。换言之，弱引用对象是最容易被回收的那类。

PhantomReference

引用类型	可达性状态名称	是否阻止 GC	`get()` 方法是否可得	被清除 / 入队列时机 / 特性	典型用途
Strong (强引用)	“强可达”（strong reachable）	阻止 GC — 只要有强引用，GC 不会回收这个对象	—（不是通过 `Reference` 对象访问的）	不会自动被 GC 清除	日常使用、常规引用
SoftReference (软引用)	“软可达”（soft reachable）	不阻止 GC，但 GC 在内存紧张时可能清除	`get()` 返回对象，除非已被清除	在内存不足时（JVM 判断需要）可被回收；若注册了 ReferenceQueue，则被清除后其引用对象会入队	缓存 (cache)、内存敏感的数据保留
WeakReference (弱引用)	“弱可达”（weak reachable）	不阻止 GC — 一旦对象只被弱引用可达，就将被回收	`get()` 若对象未被回收则返回，否则返回 null	在下一次垃圾回收（或更早）就可被回收；若注册队列，则在清除／回收时入队	WeakHashMap、 canonicalizing map、避免内存泄漏辅助结构
PhantomReference (虚引用，也称幻影引用)	“虚可达”（phantom reachable）	不阻止回收（比软弱还“弱”）	`get()` 总是返回 null（永远不可通过它获取对象）	当对象“几乎要被回收”时被入队列（通常是在对象 finalize/清理之后） — 但 GC 在回收对象之前，必须先将其 phantom 引用入队（让程序得知该对象将被回收）	用于跟踪对象被回收的时刻，做清理 (cleanup)、资源释放、内存调度等

ReferenceQueue

垃圾回收算法

垃圾收集动图示例

标记-清除（Mark-Sweep）

核心思想：两阶段完成回收。先从 GC Roots 出发“标记”所有存活对象，再“清除”未标记对象以回收其占用的内存。
典型流程：
1. Stop-The-World，遍历对象图进行可达性分析并标记存活对象
2. 扫描堆空间，释放未标记对象所占内存
优点：实现简单，无需移动大量对象
缺点：
- 会产生内存碎片，后续大对象分配可能失败而触发 Full GC
- 清除阶段需要遍历堆，吞吐不佳
适用场景：老年代的早期实现或碎片不敏感的场景

标记-整理（Mark-Compact）

核心思想：同样先标记，再把存活对象“压缩”到一端，保持内存连续，最后清理边界之外的区域。
典型流程：
1. 标记存活对象
2. 计算新地址并更新引用（有的实现先计算转发表）
3. 将对象按新地址搬迁并整理出连续可用空间
优点：避免内存碎片，便于后续大对象分配
缺点：对象移动成本较高，需要更新引用，暂停时间可能更长
适用场景：老年代常用策略，G1、ZGC 等也在混合或并发阶段引入压缩思想

复制（Copying）

核心思想：将内存按比例分为两个对等或不对等的区域，每次只使用其中一个。GC 时把存活对象复制到“空闲”区域，随后整体清空原区域。
典型流程：
1. 新生代常见布局：Eden + S0 + S1（两个 Survivor）
2. Minor GC 时从 Eden 和一个 Survivor 里复制存活对象到另一个 Survivor
3. 完成后交换两个 Survivor 的角色
优点：复制后空间天然连续，没有碎片，分配可用指针碰撞，速度快
缺点：需要预留额外空间，内存利用率较低；存活率高时复制成本上升
适用场景：新生代（对象朝生夕死，存活率低，复制效率高）

分代收集（Generational Collection）

核心思想：依据“绝大多数对象朝生夕死”的经验法则，将堆划分为新生代与老年代，针对不同代采用不同算法和回收频率。
典型实现：
- 新生代：多用复制算法（Eden + Survivor），Minor GC 频繁且停顿短
- 老年代：多用标记-清除或标记-整理，Major/Full GC 频率低但停顿长
- 跨代引用：通过 Remembered Set 或 Card Table 跟踪老年代指向新生代的引用，避免每次扫描整个老年代
优点：综合性能好，在典型负载下能显著降低总停顿时间
缺点：需要维护跨代写屏障与集合结构，调参复杂
适用场景：几乎所有 HotSpot 回收器的基础设计，如 Parallel、CMS（历史）、G1、Shenandoah、ZGC 等都体现了分代思想
小结
- 标记-清除：简单但易碎片化
- 标记-整理：无碎片但移动成本高
- 复制：快速无碎片，牺牲一部分空间
- 分代：按对象存活特征选择算法，工程上最常见的组合策略

垃圾回收器

来源

详解Java的 GCRoot

JVM之垃圾回收机制（GC）

JVM垃圾回收详解（重点）

Types of References in Java

Java四种引用类型原理你真的搞明白了吗？五分钟带你深入理解！

说一说Java中的四种引用类型？

RuntimeDataArea

Thu, 25 Sep 2025 00:00:00 +0000

Java Virtual Machine Stacks

是一块内存区域,用于存放存放单个线程的数据如方法和局部变量,一个Stack里有多个Stack Frame.

更大的栈内存设置不会提高效率，会减少最大同时运行线程数量
栈内存可固定也可以动态变化
static变量可以被多个线程同时调用，需要考虑线程安全
私有局部变量只存在在该栈内只能被这个栈调用，通常认为是安全的。
当局部变量发生Escape时，不再线程安全，如参数传递，返回值泄露
即使没有递归也有可能发生StackOverFlow,比如循环引用.

Heap

最大的一块内存空间,被所有线程共享,存放着大部分的对象实例,就是new出来的对象.

Heap分为三大类,新生区,老年区和元空间(永久代).

Young Generation

新生代由Eden和两组Survivor空间组成,通常eden要远大于Survivor区域,而Survivor中s0 : s1 == 1 : 1

当有新的对象加入 Heap 时通常首先进入 Eden.
当发生 [[GC(Garbage Collectors)#^Young GC|Young GC]] 时Eden尝试会将Eden和 s1/s0 中全部对象移入s0或s1,并给这些对象年龄加1
当对象进行多次 GC 后年龄达到阈值会被移入** Old Generation **
如果新加入的对象过大会直接进入 Old Generation
Survivor Space的 from 和 to 指的是在复制整理对象时的原位置和复制位置.

Old Generation

老年代存放着大对象和长期存活的对象

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。

大对象直接进入老年代的行为是由虚拟机动态决定的，它与具体使用的垃圾回收器和相关参数有关。大对象直接进入老年代是一种优化策略，旨在避免将大对象放入新生代，从而减少新生代的垃圾回收频率和成本。

当对象经历过多次 Young GC 依旧存活达到阈值(通常是15/8) 将被移入 Old Generation.

Method Area

是JVM运行时内存结构中的一块区域, 被所有JVM线程共享, 存储每个类的结构信息.

run-time constant pool, field and method data, and the code for methods and constructors, including the special methods used in class and interface initialization and in instance initialization.

StirngTable

StringTable(String Pool) 在Java7之前存放在 ConstantPool,之后Method Area移动到本地内存实现,但是 StringTable 依旧在堆中.

String 存放在 StringTable中,是不可变对象,能够被多个对象引用.

String s1 = "a";
String s2 = "b";

String s3 = s1 + s2; 
//StirngBuilder().append(s1).append.(s2).toString(); new String("ab");

String s4 = "ab"

// s3 != s4

String s5 = "a" + "b"
//s4 == s5

因为s3 相当于new了一个新对象存储,所以存储在堆中.

而s4则是存储在 StringPool 当中.

两者指向的对象不同, 而 == 是比较的引用地址,所以flase

如果使用.equals() 就相同.

在拼接s5时编译器进行优化,直接从StringPool找到 a b 进行拼接,发现结果是已有的 ab,

于是直接指向ab.

intern方法 1.8

调用字符串对象的 intern 方法，会将当前**堆中字符串对象的引用注册**到串池中

检查字符串常量池中是否已存在该字符串
如果不存在，则将当前堆中字符串对象的引用注册到字符串常量池中
如果存在，直接返回池中的引用,不更新引用.

public class Main {
	public static void main(String[] args) {
		// "a" "b" 被放入串池中，str 则存在于堆内存之中
		String str = new String("a") + new String("b");
		// 调用 str 的 intern 方法，这时串池中没有 "ab" ，则会将堆中字符串对象的引用注册到串池，此时堆内存与串池中的 "ab" 是同一个对象
		String st2 = str.intern();
		// 给 str3 赋值，因为此时串池中已有 "ab" ，则直接将串池中的内容返回
		String str3 = "ab";
		// 因为堆内存与串池中的 "ab" 是同一个对象，所以以下两条语句打印的都为 true
		System.out.println(str == st2);
		System.out.println(str == str3);
	}
}

Native Method Stack

PC Register

Escape

public static StringBuffer craeteStringBuffer(String s1, String s2) {
   StringBuffer sb = new StringBuffer();
   sb.append(s1);
   sb.append(s2);
   return sb;
}

创建的局部变量 sb 通过return方法传递,将sb脱离了自己掌控,线程逃逸.

来源

JVM 基础 - JVM 内存结构

21_堆_内存诊断_jvirsualvm_哔哩哔哩_bilibili

Chapter 2. The Structure of the Java Virtual Machine

JVM垃圾回收详解（重点）

JAVA on pipo's site

从 Future 到 CompletableFuture

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

快速上手

几个注意点

实战示例

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

快速上手

常见的几种方法

创建异步任务

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

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

异常处理

两个任务组合

多个任务全部完成

实战示例

Reference

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. 替代方案

核心要点总结（一图流）

乐观锁 & 悲观锁

悲观锁

实现方式

缺点

适用场景

乐观锁

实现方式

机制

版本控制

CAS(Compare And Swap)

来源

GC 垃圾回收

什么是可被回收的,如何判断?

引用计数器

可达性分析算法

GC Roots

方法区回收(或Meta Space)

finalize()

GC 主要作用范围

Heap

部分 GC

Young GC

Full GC

引用类型

StrongReference

SoftReference

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

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

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

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

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

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

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

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

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