《极客时间教程 - 深入浅出 Java 虚拟机》笔记

开篇词：JVM，一块难啃的骨头

略

一探究竟：为什么需要 JVM？它处在什么位置？

JVM - Java Virtual Machine 的缩写，即 Java 虚拟机。JVM 是运行 Java 字节码的虚拟机。JVM 不理解 Java 源代码，这就是为什么要将 *.java 文件编译为 JVM 可理解的 *.class 文件（字节码）。Java 有一句著名的口号：“Write Once, Run Anywhere（一次编写，随处运行）”，JVM 正是其核心所在。实际上，JVM 针对不同的系统（Windows、Linux、MacOS）有不同的实现，目的在于用相同的字节码执行同样的结果。

JRE - Java Runtime Environment 的缩写，即 Java 运行时环境。它是运行已编译 Java 程序所需的一切的软件包，主要包括 JVM、Java 类库（Class Library）、Java 命令和其他基础结构。但是，它不能用于创建新程序。

JDK - Java Development Kit 的缩写，即 Java SDK。它不仅包含 JRE 的所有功能，还包含编译器 (javac) 和工具（如 javadoc 和 jdb）。它能够创建和编译程序。

总结来说，JDK、JRE、JVM 三者的关系是：JDK > JRE > JVM

JDK = JRE + 开发/调试工具

JRE = JVM + Java 类库 + Java 运行库

JVM = 类加载系统 + 运行时内存区域 + 执行引擎

摘自 stackoverflow 高票问题 - What is the difference between JDK and JRE?

大厂面试题：你不得不掌握的 JVM 内存管理

大厂面试题：从覆盖 JDK 的类开始掌握类的加载机制

Java 类的完整生命周期包括以下几个阶段：

• 加载（Loading） - 将 _.java 文件转为 _.class
• 链接（Linking）
  • 验证（Verification） - 确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求
  • 准备（Preparation） - 为 static 变量在方法区分配内存并初始化为默认值
  • 解析（Resolution） - 将常量池的符号引用替换为直接引用的过程
• 初始化（Initialization） - 为类的静态变量赋予正确的初始值，JVM 负责对类进行初始化，主要对类变量进行初始化

类加载器

• Bootstrap ClassLoader - 负责加载 <JAVA_HOME>\lib 或被 -Xbootclasspath 指定的路径

• ExtClassLoader - 负责加载 <JAVA_HOME>\lib\ext 或被java.ext.dir 指定的路径

• AppClassLoader - 负载加载 classpath 路径

• 自定义类加载器 - 继承自 java.lang.ClassLoader

双亲委派机制 - 除了顶层的启动类加载器以外，其余的类加载器，在加载之前，都会委派给它的父加载器进行加载。

动手实践：从栈帧看字节码是如何在 JVM 中进行流转的

• javap - javap 是 JDK 自带的反解析工具。它的作用是将 .class 字节码文件解析成可读的文件格式。

• jclasslib - jclasslib 是一个图形化的工具，能够更加直观的查看字节码中的内容。

大厂面试题：得心应手应对 OOM 的疑难杂症

对象生命周期判断

• 引用计数法
• 可达性分析法 - GC Roots

引用类型：

• 强引用
• 软引用
• 弱引用
• 虚引用

深入剖析：垃圾回收你真的了解吗？（上）

垃圾回收算法

• 标记-复制 - 效率最高，但会浪费大量内存空间
• 标记-清除 - 效率一般，会产生大量内存碎片
• 标记-整理 - 效率最差，但是不会浪费空间，也消除了内存碎片

GC 分代收集：年轻代 GC 使用标记-复制算法；老年代 GC 使用标记-清除算法、标记-整理算法。

常见 GC 收集器：

• 年轻代：Serial、ParNew、Parallel
• 老年代：Serial Old、Parallel Old、CMS
• 元空间：G1、ZGC

GC 收集器配置参数：

• -XX:+UseSerialGC 年轻代和老年代都用串行收集器
• -XX:+UseParNewGC 年轻代使用 ParNew，老年代使用 Serial Old
• -XX:+UseParallelGC 年轻代使用 ParallerGC，老年代使用 Serial Old
• -XX:+UseParallelOldGC 新生代和老年代都使用并行收集器
• -XX:+UseConcMarkSweepGC，表示年轻代使用 ParNew，老年代的用 CMS
• -XX:+UseG1GC 使用 G1 垃圾回收器
• -XX:+UseZGC 使用 ZGC 垃圾回收器

深入剖析：垃圾回收你真的了解吗？（下）

• Minor GC：发生在年轻代的 GC。
• Major GC：发生在老年代的 GC。
• Full GC：全堆垃圾回收。比如 Metaspace 区引起年轻代和老年代的回收。

CMS 垃圾回收器分为四个阶段：

1. 初始标记
2. 并发标记
3. 重新标记
4. 并发清理

CMS 中都会有哪些停顿（STW）：

1. 初始标记，这部分的停顿时间较短；
2. Minor GC（可选），在预处理阶段对年轻代的回收，停顿由年轻代决定；
3. 重新标记，由于 preclaen 阶段的介入，这部分停顿也较短；
4. Serial-Old 收集老年代的停顿，主要发生在预留空间不足的情况下，时间会持续很长；
5. Full GC，永久代空间耗尽时的操作，由于会有整理阶段，持续时间较长。

大厂面试题：有了 G1 还需要其他垃圾回收器吗？

G1 最重要的概念，其实就是 Region。它采用分而治之，部分收集的思想，尽力达到我们给它设定的停顿目标。

案例实战：亿级流量高并发下如何进行估算和调优

GC 指标：

• 系统容量（Capacity）
• 延迟（Latency）
• 吞吐量（Throughput）

选择垃圾回收器

• 如果你的堆大小不是很大（比如 100MB），选择串行收集器一般是效率最高的。参数：-XX:+UseSerialGC。
• 如果你的应用运行在单核的机器上，或者你的虚拟机核数只有 1C，选择串行收集器依然是合适的，这时候启用一些并行收集器没有任何收益。参数：-XX:+UseSerialGC。
• 如果你的应用是“吞吐量”优先的，并且对较长时间的停顿没有什么特别的要求。选择并行收集器是比较好的。参数：-XX:+UseParallelGC。
• 如果你的应用对响应时间要求较高，想要较少的停顿。甚至 1 秒的停顿都会引起大量的请求失败，那么选择 G1、ZGC、CMS 都是合理的。虽然这些收集器的 GC 停顿通常都比较短，但它需要一些额外的资源去处理这些工作，通常吞吐量会低一些。参数：-XX:+UseConcMarkSweepGC、-XX:+UseG1GC、-XX:+UseZGC 等。

第 09 讲：案例实战：面对突如其来的 GC 问题如何下手解决

第 10 讲：动手实践：自己模拟 JVM 内存溢出场景

第 11 讲：动手实践：遇到问题不要慌，轻松搞定内存泄漏

jinfo、jstat、jstack、jhsdb（jmap）等是经常被使用的一些工具，尤其是 jmap，在分析处理内存泄漏问题的时候，是必须的。

工具进阶：如何利用 MAT 找到问题发生的根本原因

MAT 是用来分析内存快照的。

动手实践：让面试官刮目相看的堆外内存排查

预警与解决：深入浅出 GC 监控与调优

案例分析：一个高死亡率的报表系统的优化之路

案例分析：分库分表后，我的应用崩溃了

动手实践：从字节码看方法调用的底层实现

大厂面试题：不要搞混 JMM 与 JVM

动手实践：从字节码看并发编程的底层实现

动手实践：不为人熟知的字节码指令

深入剖析：如何使用 Java Agent 技术对字节码进行修改

23 动手实践：JIT 参数配置如何影响程序运行？

案例分析：大型项目如何进行性能瓶颈调优？

未来：JVM 的历史与展望

福利：常见 JVM 面试题补充

Java 并发面试三

Java 线程池

【简单】为什么要用线程池？

顾名思义，线程池就是管理一系列线程的资源池。当有任务要处理时，直接从线程池中获取线程来处理，处理完之后线程并不会立即被销毁，而是等待下一个任务。

池化技术想必大家已经屡见不鲜了，线程池、数据库连接池、HTTP 连接池等等都是对这个思想的应用。池化技术的思想主要是为了减少每次获取资源的消耗，提高对资源的利用率。

线程池提供了一种限制和管理资源（包括执行一个任务）的方式。 每个线程池还维护一些基本统计信息，例如已完成任务的数量。

这里借用《Java 并发编程的艺术》提到的来说一下使用线程池的好处：

• 降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。
• 提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。
• 提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统的稳定性，使用线程池可以进行统一的分配，调优和监控。

【简单】Java 创建线程池有哪些方式？

Java 提供了多种创建线程池的方法，主要通过 java.util.concurrent.Executors 工厂类和直接使用 ThreadPoolExecutor 构造函数来实现。

• 简单场景使用 Executors 工厂方法
• 需要精细控制时使用 ThreadPoolExecutor 构造器
• 注意根据任务类型选择合适的线程池类型
• 避免使用无界队列以防内存溢出

（1）通过 Executors 工厂方法

Executors 类中提供了几种内置的 ThreadPoolExecutor 实现：

• **FixedThreadPool**：固定线程数量的线程池。该线程池中的线程数量始终不变。当有一个新的任务提交时，线程池中若有空闲线程，则立即执行。若没有，则新的任务会被暂存在一个任务队列中，待有线程空闲时，便处理在任务队列中的任务。
• **SingleThreadExecutor**： 只有一个线程的线程池。若多余一个任务被提交到该线程池，任务会被保存在一个任务队列中，待线程空闲，按先入先出的顺序执行队列中的任务。
• **CachedThreadPool**： 可根据实际情况调整线程数量的线程池。线程池的线程数量不确定，但若有空闲线程可以复用，则会优先使用可复用的线程。若所有线程均在工作，又有新的任务提交，则会创建新的线程处理任务。所有线程在当前任务执行完毕后，将返回线程池进行复用。
• **ScheduledThreadPool**：给定的延迟后运行任务或者定期执行任务的线程池。

（2）直接使用 ThreadPoolExecutor 构造器

1
2
3
4
5
6
7
8
9

new ThreadPoolExecutor(
    int corePoolSize,
    int maximumPoolSize,
    long keepAliveTime,
    TimeUnit unit,
    BlockingQueue<Runnable> workQueue,
    ThreadFactory threadFactory,
    RejectedExecutionHandler handler
);

• 提供更精细的控制参数
• 可以自定义线程工厂和拒绝策略

（3）ForkJoinPool (JDK7+)

1

ForkJoinPool forkJoinPool = new ForkJoinPool(int parallelism);

• 适用于分治算法和并行任务
• 使用工作窃取 (work-stealing) 算法

【中等】Java 线程池有哪些核心参数？各有什么作用？

ThreadPoolExecutor 有四个构造方法，前三个都是基于第四个实现。第四个构造方法定义如下：

1
2
3
4
5
6
7
8

public ThreadPoolExecutor(int corePoolSize,// 线程池的核心线程数量
						  int maximumPoolSize,// 线程池的最大线程数
						  long keepAliveTime,// 当线程数大于核心线程数时，多余的空闲线程存活的最长时间
						  TimeUnit unit,// 时间单位
						  BlockingQueue<Runnable> workQueue,// 任务队列，用来储存等待执行任务的队列
						  ThreadFactory threadFactory,// 线程工厂，用来创建线程，一般默认即可
						  RejectedExecutionHandler handler// 拒绝策略，当提交的任务过多而不能及时处理时，我们可以定制策略来处理任务
) {// 略}

参数说明：

• corePoolSize：表示线程池保有的最小线程数。
• maximumPoolSize：表示线程池允许创建的最大线程数。
  • 如果队列满了，并且已创建的线程数小于最大线程数，则线程池会再创建新的线程执行任务。
  • 值得注意的是：如果使用了无界的任务队列这个参数就没什么效果。
• keepAliveTime & unit：表示非核心线程存活时间。如果一个线程空闲了keepAliveTime & unit 这么久，而且线程池的线程数大于 corePoolSize ，那么这个空闲的线程就要被回收了。
• workQueue：等待执行的任务队列。用于保存等待执行的任务的阻塞队列。 可以选择以下几个阻塞队列。
  • ArrayBlockingQueue：基于数组的有界阻塞队列。
  • LinkedBlockingQueue：基于链表的无界阻塞队列，可能导致 OOM。
  • SynchronousQueue：不保存任务，直接新建一个线程来执行任务（需要有可用线程，否则拒绝）。
  • **DelayedWorkQueue**：延迟阻塞队列。
  • PriorityBlockingQueue：具有优先级的无界阻塞队列。
• threadFactory：线程工厂。线程工程用于自定义如何创建线程。
• handler：拒绝策略。它是 RejectedExecutionHandler 类型的变量。当队列和线程池都满了，说明线程池处于饱和状态，那么必须采取一种策略处理提交的新任务。线程池支持以下策略：
  • AbortPolicy：默认策略，丢弃任务并抛出异常，直接抛出 RejectedExecutionException。
  • DiscardPolicy：丢弃任务但不抛出异常。
  • DiscardOldestPolicy：丢弃队列最老的任务，然后重新尝试提交。
  • CallerRunsPolicy：提交任务的线程自己去执行该任务。
  • 如果以上策略都不能满足需要，也可以通过实现 RejectedExecutionHandler 接口来定制处理策略。如记录日志或持久化不能处理的任务。

合理配置这些参数可以优化线程池的性能和稳定性，避免 OOM 或任务丢失。

【中等】Java 线程池的工作原理是什么？

线程池的工作流程遵循 任务提交 → 线程分配 → 队列管理 → 拒绝处理 机制：

1. 提交任务：调用 execute(Runnable) 或 submit(Callable) 提交任务。
2. 线程分配逻辑
   • 核心线程可用 → 立即执行任务（即使有空闲线程也会优先创建新线程直到 corePoolSize）。
   • 核心线程已满 → 任务进入任务队列（workQueue）等待。
   • 队列已满 → 创建新线程（不超过 maximumPoolSize）。
   • 线程数达 maximumPoolSize 且队列满 → 触发拒绝策略（RejectedExecutionHandler）。
3. 线程回收：非核心线程在空闲超过 keepAliveTime 后被回收，核心线程默认常驻（除非设置 allowCoreThreadTimeOut=true）。

::: info 线程分配和队列管理源码

:::

默认情况下，创建线程池之后，线程池中是没有线程的，需要提交任务之后才会创建线程。提交任务可以使用 execute 方法，它是 ThreadPoolExecutor 的核心方法，通过这个方法可以向线程池提交一个任务，交由线程池去执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

// 用于控制线程池的运行状态和线程池中的有效线程数量
private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));

public void execute(Runnable command) {
	if (command == null)
		throw new NullPointerException();

    // 获取 ctl 中存储的线程池状态信息
	int c = ctl.get();

    // 线程池执行可以分为 3 个步骤
    // 1. 若工作线程数小于核心线程数，则尝试启动一个新的线程来执行任务
	if (workerCountOf(c) < corePoolSize) {
		if (addWorker(command, true))
			return;
		c = ctl.get();
	}

    // 2. 如果任务可以成功地加入队列，还需要再次确认是否需要添加新的线程（因为可能自从上次检查以来已经有线程死亡）或者检查线程池是否已经关闭
    // 	-> 如果是后者，则可能需要回滚入队操作；
    // 	-> 如果是前者，则可能需要启动新的线程
	if (isRunning(c) && workQueue.offer(command)) {
		int recheck = ctl.get();
		if (!isRunning(recheck) && remove(command))
			reject(command);
		else if (workerCountOf(recheck) == 0)
			addWorker(null, false);
	}
    // 如果任务无法加入队列，则尝试添加一个新的线程
    // 如果添加新线程失败，说明线程池已经关闭或者达到了容量上限，此时将拒绝该任务
	else if (!addWorker(command, false))
		reject(command);
}

execute 方法工作流程如下：

1. 如果 workerCount < corePoolSize，则创建并启动一个线程来执行新提交的任务；
2. 如果 workerCount >= corePoolSize，且线程池内的阻塞队列未满，则将任务添加到该阻塞队列中；
3. 如果 workerCount >= corePoolSize && workerCount < maximumPoolSize，且线程池内的阻塞队列已满，则创建并启动一个线程来执行新提交的任务；
4. 如果workerCount >= maximumPoolSize，并且线程池内的阻塞队列已满，则根据拒绝策略来处理该任务，默认的处理方式是直接抛异常。

::: info 线程池任务状态

:::

ThreadPoolExecutor 有以下重要字段：

1
2
3
4
5
6
7
8
9

private final AtomicInteger ctl = new AtomicInteger(ctlOf(RUNNING, 0));
private static final int COUNT_BITS = Integer.SIZE - 3;
private static final int CAPACITY   = (1 << COUNT_BITS) - 1;
// runState is stored in the high-order bits
private static final int RUNNING    = -1 << COUNT_BITS;
private static final int SHUTDOWN   =  0 << COUNT_BITS;
private static final int STOP       =  1 << COUNT_BITS;
private static final int TIDYING    =  2 << COUNT_BITS;
private static final int TERMINATED =  3 << COUNT_BITS;

ctl 用于控制线程池的运行状态和线程池中的有效线程数量。它包含两部分的信息：

• 线程池的运行状态 (runState)
• 线程池内有效线程的数量 (workerCount)
• 可以看到，ctl 使用了 Integer 类型来保存，高 3 位保存 runState，低 29 位保存 workerCount。COUNT_BITS 就是 29，CAPACITY 就是 1 左移 29 位减 1（29 个 1），这个常量表示 workerCount 的上限值，大约是 5 亿。

线程池一共有五种运行状态：

• RUNNING（运行状态）。接受新任务，并且也能处理阻塞队列中的任务。
• SHUTDOWN（关闭状态）。不接受新任务，但可以处理阻塞队列中的任务。
  • 在线程池处于 RUNNING 状态时，调用 shutdown 方法会使线程池进入到该状态。
  • finalize 方法在执行过程中也会调用 shutdown 方法进入该状态。
• STOP（停止状态）。不接受新任务，也不处理队列中的任务。会中断正在处理任务的线程。在线程池处于 RUNNING 或 SHUTDOWN 状态时，调用 shutdownNow 方法会使线程池进入到该状态。
• TIDYING（整理状态）。如果所有的任务都已终止了，workerCount （有效线程数） 为 0，线程池进入该状态后会调用 terminated 方法进入 TERMINATED 状态。
• TERMINATED（已终止状态）。在 terminated 方法执行完后进入该状态。默认 terminated 方法中什么也没有做。进入 TERMINATED 的条件如下：
  • 线程池不是 RUNNING 状态；
  • 线程池状态不是 TIDYING 状态或 TERMINATED 状态；
  • 如果线程池状态是 SHUTDOWN 并且 workerQueue 为空；
  • workerCount 为 0；
  • 设置 TIDYING 状态成功。

在 execute 方法中，多次调用 addWorker 方法。addWorker 这个方法主要用来创建新的工作线程，如果返回 true 说明创建和启动工作线程成功，否则的话返回的就是 false。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99

// 全局锁，并发操作必备
private final ReentrantLock mainLock = new ReentrantLock();
// 跟踪线程池的最大大小，只有在持有全局锁 mainLock 的前提下才能访问此集合
private int largestPoolSize;
// 工作线程集合，存放线程池中所有的（活跃的）工作线程，只有在持有全局锁 mainLock 的前提下才能访问此集合
private final HashSet<Worker> workers = new HashSet<>();
//获取线程池状态
private static int runStateOf(int c)     { return c & ~CAPACITY; }
//判断线程池的状态是否为 Running
private static boolean isRunning(int c) {
	return c < SHUTDOWN;
}

/**
 * 添加新的工作线程到线程池
 * @param firstTask 要执行
 * @param core 参数为 true 的话表示使用线程池的基本大小，为 false 使用线程池最大大小
 * @return 添加成功就返回 true 否则返回 false
 */
private boolean addWorker(Runnable firstTask, boolean core) {
	retry:
	for (;;) {
		//这两句用来获取线程池的状态
		int c = ctl.get();
		int rs = runStateOf(c);

		// Check if queue empty only if necessary.
		if (rs >= SHUTDOWN &&
			! (rs == SHUTDOWN &&
			   firstTask == null &&
			   ! workQueue.isEmpty()))
			return false;

		for (;;) {
		   //获取线程池中工作的线程的数量
			int wc = workerCountOf(c);
			// core 参数为 false 的话表明队列也满了，线程池大小变为 maximumPoolSize
			if (wc >= CAPACITY ||
				wc >= (core ? corePoolSize : maximumPoolSize))
				return false;
		   //原子操作将 workcount 的数量加 1
			if (compareAndIncrementWorkerCount(c))
				break retry;
			// 如果线程的状态改变了就再次执行上述操作
			c = ctl.get();
			if (runStateOf(c) != rs)
				continue retry;
			// else CAS failed due to workerCount change; retry inner loop
		}
	}
	// 标记工作线程是否启动成功
	boolean workerStarted = false;
	// 标记工作线程是否创建成功
	boolean workerAdded = false;
	Worker w = null;
	try {

		w = new Worker(firstTask);
		final Thread t = w.thread;
		if (t != null) {
		  // 加锁
			final ReentrantLock mainLock = this.mainLock;
			mainLock.lock();
			try {
			   //获取线程池状态
				int rs = runStateOf(ctl.get());
			   //rs < SHUTDOWN 如果线程池状态依然为 RUNNING, 并且线程的状态是存活的话，就会将工作线程添加到工作线程集合中
			  //(rs=SHUTDOWN && firstTask == null) 如果线程池状态小于 STOP，也就是 RUNNING 或者 SHUTDOWN 状态下，同时传入的任务实例 firstTask 为 null，则需要添加到工作线程集合和启动新的 Worker
			   // firstTask == null 证明只新建线程而不执行任务
				if (rs < SHUTDOWN ||
					(rs == SHUTDOWN && firstTask == null)) {
					if (t.isAlive()) // precheck that t is startable
						throw new IllegalThreadStateException();
					workers.add(w);
				   //更新当前工作线程的最大容量
					int s = workers.size();
					if (s > largestPoolSize)
						largestPoolSize = s;
				  // 工作线程是否启动成功
					workerAdded = true;
				}
			} finally {
				// 释放锁
				mainLock.unlock();
			}
			//// 如果成功添加工作线程，则调用 Worker 内部的线程实例 t 的 Thread#start() 方法启动真实的线程实例
			if (workerAdded) {
				t.start();
			  /// 标记线程启动成功
				workerStarted = true;
			}
		}
	} finally {
	   // 线程启动失败，需要从工作线程中移除对应的 Worker
		if (! workerStarted)
			addWorkerFailed(w);
	}
	return workerStarted;
}

【简单】Java 线程池的核心线程会被回收吗？

在标准情况下，核心线程（core threads）即使处于空闲状态也不会被线程池回收。这是线程池的默认行为，目的是保持一定数量的常驻线程，以便快速响应新任务。通过设置 allowCoreThreadTimeOut(true) 可以改变这一行为。

【中等】如何合理地设置 Java 线程池的线程数？

根据任务类型设置线程数指导

通用计算公式

1

线程数 = CPU 核心数 × 目标 CPU 利用率 × (1 + 等待时间/计算时间）

（目标 CPU 利用率建议 0.7-0.9）

场景化配置

• Web 服务器（如 Tomcat）推荐：50-200（需压测确定）。考虑因素：
  • 并发请求量
  • 平均响应时间
  • 系统资源（内存、CPU）
• 微服务调用推荐：核心数 * 2 到 核心数 * 5，需配合熔断/降级机制
• 批处理任务推荐：核心数 ± 2，避免与在线服务争抢资源

避坑指南

• 禁止设置maximumPoolSize=Integer.MAX_VALUE，以避免 OOM。
• 避免使用无界队列（推荐ArrayBlockingQueue），避免内存堆积
• 必须配置拒绝策略（建议日志+降级）
• 动态线程池优于静态配置

最佳实践

• 通过Runtime.getRuntime().availableProcessors()获取核心数
• 配合有界队列+合理拒绝策略
• 建立线程池监控（活跃线程/队列堆积等）
• 重要服务建议使用动态调整：

1
2
3
4
5
6
7
8
9
10
11
12
13

// 获取服务器 CPU 核心数
int cpuCores = Runtime.getRuntime().availableProcessors();

// 创建线程池（I/O 密集型场景）
ThreadPoolExecutor executor = new ThreadPoolExecutor(
    cpuCores * 2,          // corePoolSize
    cpuCores * 4,          // maximumPoolSize
    30,                    // keepAliveTime （秒）
    TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(1000),  // 有界队列
    new CustomThreadFactory(),       // 命名线程
    new LogAndFallbackPolicy()       // 自定义拒绝策略
);

【中等】Java 线程池支持哪些阻塞队列，如何选择？

关键说明：

• 有界性：
  • LinkedBlockingQueue 构造时可指定容量变为有界
  • SynchronousQueue 是特殊的”零容量”队列
• 吞吐量排序：SynchronousQueue > LinkedBlockingQueue > ArrayBlockingQueue > PriorityBlockingQueue ≈ DelayQueue
• 内存开销：PriorityBlockingQueue ≈ DelayQueue > LinkedBlockingQueue > ArrayBlockingQueue > SynchronousQueue
• 特殊机制：
  • 公平模式：ArrayBlockingQueue/SynchronousQueue 可设置公平锁（降低吞吐但减少线程饥饿）
  • 双锁分离：LinkedBlockingQueue 的 put/take 操作使用不同锁，提升并发度
  • 直接传递：SynchronousQueue 实现生产者-消费者直接握手

选型决策参考：

1
2
3
4
5
6
7

是否需要优先级/延迟？
├─ 是 → PriorityBlockingQueue/DelayQueue
└─ 否 → 是否接受任务丢失？
   ├─ 是 → SynchronousQueue+CallerRunsPolicy
   └─ 否 → 能否预估最大任务量？
      ├─ 能 → ArrayBlockingQueue（容量=预估峰值×1.5)
      └─ 不能 → LinkedBlockingQueue（建议显式设置安全上限）

生产建议：

• Web 服务：ArrayBlockingQueue（2000-10000 容量）+ AbortPolicy
• 消息处理：LinkedBlockingQueue（10 万上限）+ DiscardOldestPolicy
• 实时交易：SynchronousQueue + CachedThreadPool
• 定时任务：DelayQueue（单线程消费）

【中等】Java 线程池支持哪些拒绝策略？如何选择？

Java 线程池支持以下拒绝策略：

所有策略均在以下条件同时满足时触发：

• 线程数达到 maximumPoolSize
• 工作队列已满（对于有界队列）
• 仍有新任务提交

策略选择建议：

1
2
3
4
5

是否允许任务丢失？
├─ 允许 → 选择 DiscardPolicy/DiscardOldestPolicy
└─ 不允许 → 是否能接受降级？
   ├─ 能 → 自定义策略（如持久化存储）
   └─ 不能 → 选择 CallerRunsPolicy（影响调用方）

生产环境推荐组合：

• 严格系统：AbortPolicy + 告警监控
• 弹性系统：CallerRunsPolicy + 熔断机制
• 最终一致性系统：自定义策略（如写入 Redis 重试队列）

Spring 的增强策略：

ThreadPoolTaskExecutor 额外支持：

• 通过 TaskRejectedException 提供更详细的拒绝信息
• 与 @Async 注解配合时自动应用策略

【中等】Java 线程池内部任务出异常后，如何知道是哪个线程出了异常？

在 Java 线程池中，当任务抛出异常时，默认情况下异常会被线程池”吞掉”，不会直接抛出给调用者。

1. 对于需要获取结果的异步任务，使用submit()和Future组合
2. 对于不需要结果的批量任务，使用自定义的ThreadFactory或重写afterExecute
3. 在复杂系统中，考虑结合日志框架记录完整的异常堆栈和线程信息

通过以上方法，你可以有效地追踪线程池中哪个线程执行的任务抛出了异常。

以下是几种方法来识别哪个线程出了异常：

（1）使用 Future.get() 捕获异常

1
2
3
4
5
6
7
8
9
10
11
12

ExecutorService executor = Executors.newFixedThreadPool(5);
Future<?> future = executor.submit(() -> {
    // 任务代码
    throw new RuntimeException("模拟异常");
});

try {
    future.get(); // 这里会抛出 ExecutionException
} catch (ExecutionException e) {
    System.out.println("任务抛出异常：" + e.getCause());
    // e.getCause() 获取原始异常
}

（2）自定义 ThreadFactory 设置未捕获异常处理器

1
2
3
4
5
6
7
8
9

ThreadFactory factory = r -> {
    Thread t = new Thread(r);
    t.setUncaughtExceptionHandler((thread, throwable) -> {
        System.out.println("线程 " + thread.getName() + " 抛出异常：" + throwable);
    });
    return t;
};

ExecutorService executor = Executors.newFixedThreadPool(5, factory);

（3）重写 ThreadPoolExecutor 的 afterExecute 方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

ExecutorService executor = new ThreadPoolExecutor(..., ...) {
    @Override
    protected void afterExecute(Runnable r, Throwable t) {
        super.afterExecute(r, t);
        if (t != null) {
            System.out.println("任务执行抛出异常：" + t);
        }
        // 对于通过 FutureTask 运行的任务，异常被封装在 Future 中
        if (r instanceof Future<?>) {
            try {
                ((Future<?>) r).get();
            } catch (InterruptedException | ExecutionException e) {
                System.out.println("Future 任务异常：" + e.getCause());
            }
        }
    }
};

（4）在任务内部捕获异常

1
2
3
4
5
6
7
8

executor.execute(() -> {
    try {
        // 任务代码
    } catch (Exception e) {
        System.out.println("线程 " + Thread.currentThread().getName() + " 抛出异常：" + e);
        // 记录线程信息
    }
});

【中等】Java 线程池中 shutdown 与 shutdownNow 的区别是什么？

shutdown 不会立即终止线程池，而是要等所有任务缓存队列中的任务都执行完后才终止，但再也不会接受新的任务。

• 将线程池切换到 SHUTDOWN 状态；
• 并调用 interruptIdleWorkers 方法请求中断所有空闲的 worker；
• 最后调用 tryTerminate 尝试结束线程池。

shutdownNow 立即终止线程池，并尝试打断正在执行的任务，并且清空任务缓存队列，返回尚未执行的任务。与 shutdown 方法类似，不同的地方在于：

• 设置状态为 STOP；
• 中断所有工作线程，无论是否是空闲的；
• 取出阻塞队列中没有被执行的任务并返回。

【困难】Java 线程池参数在运行过程中能修改吗？如何修改？

• 可动态修改参数：核心线程数、最大线程数、空闲时间、拒绝策略
• 不可动态修改：队列实现类、线程工厂
• Spring 增强：ThreadPoolTaskExecutor提供更友好的 API
• 生产建议：
  • 配合监控系统实现自动扩缩容
  • 修改时遵循先 max 后 core 的顺序
  • 对队列容量修改要特别小心

::: info ThreadPoolExecutor 原生动态修改参数方法

:::

ThreadPoolExecutor 提供了以下核心参数的动态修改方法：

示例代码：

1
2
3
4
5
6
7
8
9
10

ThreadPoolExecutor executor = new ThreadPoolExecutor(
    2, 5, 60, TimeUnit.SECONDS,
    new LinkedBlockingQueue<>(10)
);

// 动态调整
executor.setCorePoolSize(4);  // 核心线程数 2→4
executor.setMaximumPoolSize(8); // 最大线程数 5→8
executor.setKeepAliveTime(30, TimeUnit.SECONDS); // 60s→30s
executor.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());

::: info Spring 的 ThreadPoolTaskExecutor 增强

:::

Spring 的ThreadPoolTaskExecutor在原生基础上增加了更多动态能力：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Bean
public ThreadPoolTaskExecutor taskExecutor() {
    ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
    executor.setCorePoolSize(4);
    executor.setMaxPoolSize(8);
    executor.setQueueCapacity(50);
    executor.initialize();
    return executor;
}

// 动态调整示例
@Autowired
private ThreadPoolTaskExecutor taskExecutor;

public void adjustThreadPool() {
    taskExecutor.setCorePoolSize(6);
    taskExecutor.setMaxPoolSize(10);
    taskExecutor.setQueueCapacity(100);
    // Spring 会自动应用新配置
}

::: info 动态调整队列容量

:::

队列容量的动态调整需要特殊处理，因为大多数 BlockingQueue 创建后容量固定：

解决方案：

1. 使用自定义的可变容量队列
2. 重建线程池（优雅迁移）

自定义队列示例：

1
2
3
4
5
6
7
8
9

public class ResizableCapacityLinkedBlockingQueue<E> extends LinkedBlockingQueue<E> {
    public ResizableCapacityLinkedBlockingQueue(int capacity) {
        super(capacity);
    }

    public synchronized void setCapacity(int capacity) {
        // 实现容量调整逻辑
    }
}

扩展：

• 《Java 线程池实现原理及其在美团业务中的实践》
• 如何设置线程池参数？美团给出了一个让面试官虎躯一震的回答

开源项目：

• **Hippo4j**：异步线程池框架，支持线程池动态变更&监控&报警，无需修改代码轻松引入。支持多种使用模式，轻松引入，致力于提高系统运行保障能力。
• **Dynamic TP**：轻量级动态线程池，内置监控告警功能，集成三方中间件线程池管理，基于主流配置中心（已支持 Nacos、Apollo，Zookeeper、Consul、Etcd，可通过 SPI 自定义实现）。

Java 并发同步工具

【中等】CountDownLatch 的工作原理是什么？

CountDownLatch 通过计数器实现线程间的“等待-通知”机制，适用于分阶段任务同步，但不可重复使用。

基本作用

• 允许一个或多个线程等待，直到其他线程完成一组操作后再继续执行。
• 典型场景：主线程等待多个子线程完成任务后再汇总结果。

核心机制

• 计数器初始化：创建时指定初始计数值（如 new CountDownLatch(3)）。
• 计数递减：子线程完成任务后调用 countDown()，计数器减 1（线程不会阻塞）。
• 等待阻塞：主线程调用 await() 会阻塞，直到计数器归零（或超时）。

关键特性

• 一次性：计数器归零后无法重置，需重新创建实例。
• 非中断递减：countDown() 不受线程中断影响，但 await() 可被中断。

代码示例

1
2
3
4
5
6
7
8
9
10
11

CountDownLatch latch = new CountDownLatch(3);

// 子线程完成任务后递减
new Thread(() -> {
    doTask();
    latch.countDown(); // 计数器-1
}).start();

// 主线程等待所有子线程完成
latch.await();
System.out.println("All tasks done!");

【中等】CyclicBarrier 的工作原理是什么？

CyclicBarrier 通过“线程互相等待”实现协同，适合需要多轮同步的场景，且具备更高的灵活性。

核心作用

• 让一组线程互相等待，直到所有线程都到达某个屏障点（Barrier）后，再一起继续执行。
• 适用于分阶段并行任务（如多线程计算后合并结果）。

关键机制

主要特性

• 可重复使用：一轮屏障突破后，自动重置计数器，支持下一轮同步。
• 回调任务：通过构造函数传入 Runnable，在所有线程到达后由最后一个到达的线程执行。
• 超时与中断：await(timeout, unit) 支持超时；线程在等待时若被中断，会抛出 BrokenBarrierException。

代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

CyclicBarrier barrier = new CyclicBarrier(3, () -> {
    System.out.println("All threads reached the barrier!");
});

for (int i = 0; i < 3; i++) {
    new Thread(() -> {
        System.out.println(Thread.currentThread().getName() + " is working...");
        try {
            barrier.await(); // 等待其他线程
        } catch (Exception e) {
            e.printStackTrace();
        }
        System.out.println(Thread.currentThread().getName() + " continues after barrier.");
    }).start();
}

对比 CountDownLatch

典型应用场景

• 多阶段并行计算：如 MapReduce 中，多个 Worker 完成局部计算后同步，再进入下一阶段。
• 模拟压力测试：让所有测试线程同时开始请求。
• 游戏同步：多个玩家加载资源完成后同时开始游戏。

【中等】Semaphore 的工作原理是什么？

Semaphore 译为信号量，是一种同步机制，用于控制多线程对共享资源的访问。

Semaphore 通过许可证机制灵活控制并发度，既可用于严格互斥（许可证=1 时类似锁），也可用于资源池管理。与 CyclicBarrier/CountDownLatch 不同，它关注的是资源的访问权限而非线程间的同步。

核心作用

• 控制并发访问资源的线程数量，通过“许可证”（permits）机制实现限流。
• 适用于：
  • 资源池管理（如数据库连接池）
  • 限流（如接口每秒最大请求数）
  • 互斥场景（类似锁，但更灵活）

关键机制

主要特性

• 动态调整：可通过 release() 增加许可证，或 reducePermits() 动态减少。
• 非阻塞尝试：tryAcquire() 立即返回是否成功，支持超时（如 tryAcquire(2, TimeUnit.SECONDS)）。
• 可中断：acquire() 可被其他线程中断（抛出 InterruptedException）。

代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

Semaphore semaphore = new Semaphore(3); // 允许 3 个线程并发

for (int i = 0; i < 5; i++) {
    new Thread(() -> {
        try {
            semaphore.acquire(); // 获取许可证
            System.out.println(Thread.currentThread().getName() + " 占用资源");
            Thread.sleep(2000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            semaphore.release(); // 释放许可证
            System.out.println(Thread.currentThread().getName() + " 释放资源");
        }
    }).start();
}

输出：

1
2
3
4
5
6
7
8
9

Thread-0 占用资源
Thread-1 占用资源
Thread-2 占用资源
（2 秒后）
Thread-0 释放资源
Thread-3 占用资源
Thread-1 释放资源
Thread-4 占用资源
...

对比其他同步工具

典型应用场景

• 连接池管理：限制同时使用的数据库连接数。
• 流量控制：限制每秒处理的请求数。
• 生产者-消费者模型：通过信号量控制缓冲区大小。

Java 并发分工工具

【中等】ForkJoinPool 的工作原理是什么？

ForkJoinPool 通过工作窃取机制高效处理分治任务，适合递归并行计算，核心是本地队列+LIFO 处理+FIFO 窃取。

设计目标

• 高效执行分治任务：适用于递归分解的可并行计算（如归并排序、MapReduce）。
• 工作窃取（Work-Stealing）：每个线程有自己的任务队列，空闲线程可从其他队列“窃取”任务，避免资源闲置。

核心组件

• 工作线程（ForkJoinWorkerThread）：每个线程维护一个双端队列（Deque），存放自己的任务。
• 任务队列：
  • 本地队列：LIFO（后进先出）处理自己生成的任务（fork()）。
  • 窃取队列：FIFO（先进先出）窃取其他线程的任务（公平性）。
• 任务类型（ForkJoinTask）：RecursiveAction（无返回值） / RecursiveTask（有返回值）。

工作流程

1. 任务拆分（Fork）：调用 fork() 将子任务压入本地队列（LIFO）。
2. 任务执行（Join）：调用 join() 等待子任务结果，期间线程会优先处理本地任务。
3. 工作窃取（Stealing）：若线程无任务，从其他线程队列尾部窃取任务（FIFO，减少竞争）。

关键特性

• 低竞争：线程优先处理本地任务，减少同步开销。
• 负载均衡：空闲线程自动窃取任务，提高 CPU 利用率。
• 递归优化：适合深度递归任务，避免线程阻塞。

与普通线程池对比

注意事项

• 避免阻塞操作：不适合 IO 密集型任务（线程数有限，易阻塞）。
• 任务粒度：过小的任务会增加调度开销。

【中等】CompleteFuture 的工作原理是什么？

CompletableFuture 通过回调链和 Completion 阶段机制实现灵活的异步编程，支持任务编排、结果转换和异常传播，底层采用无锁设计优化性能。

核心设计

• 异步编程模型：基于 Future 的增强实现，支持显式完成（手动设置结果）
• 回调驱动：通过链式调用实现异步任务编排
• 双阶段执行：
  • 异步计算阶段（任务执行）
  • 完成阶段（结果处理）

关键组件

• CompletionStage 接口：定义 50+种组合操作（thenApply/thenAccept/thenRun 等）
• 依赖关系堆栈：维护任务依赖链（类似链表结构）
• 执行器支持：可指定自定义线程池（默认使用 ForkJoinPool.commonPool）

工作流程

1. 任务创建：

   1	CompletableFuture.supplyAsync(() -> "task")

2. 结果转换：

   1	.thenApply(s -> s + " result")

3. 最终处理：

   1	.thenAccept(System.out::println)

核心机制

• 回调链（Completion 链）：
  • 每个操作生成新的 Completion 节点
  • 节点间形成单向链表
• 触发机制：
  • 前置任务完成时触发后续操作
  • 支持同步/异步执行切换
• 结果传递：
  • 异常传播（exceptionally 处理）
  • 结果转换（thenApply）

线程模型

• 默认线程池：ForkJoinPool.commonPool()
• 可控性：
  • 支持显式指定线程池
  • 可强制指定同步执行（thenApply vs thenApplyAsync）

特殊功能

• 组合操作：
  • allOf/anyOf（多任务协调）
  • thenCombine（双源合并）
• 完成控制：
  • complete()/completeExceptionally()（手动完成）
  • obtrudeValue（强制覆盖结果）

性能特点

• 无锁设计：基于 CAS 操作
• 零等待：回调立即触发（无轮询）
• 最小化线程切换：优化执行路径

注意事项

• 线程泄漏风险：未指定线程池时使用默认池
• 回调地狱：过度链式调用降低可读性
• 异常处理：必须显式处理异常

适用场景

• 服务调用编排
• 异步流水线处理
• 多源结果聚合

【中等】Timer 的工作原理是什么？

Timer 通过单线程+优先级队列调度任务，简单但不可靠；生产环境建议用线程池替代。

基本组成

• **Timer**：任务调度器，管理任务队列和后台线程。
• **TimerTask**：需实现 run()，定义要执行的任务。

核心机制

• 单线程调度：
  • 所有任务由单个后台线程（TimerThread）顺序执行。
  • 任务队列按执行时间排序（优先级队列，最小堆）。
• 任务触发流程：
  1. 调用 schedule() 将任务加入队列。
  2. 线程循环检查队首任务，通过 wait(timeout) 休眠至执行时间。
  3. 执行 run() 后，根据调度类型计算下次执行时间：
     • 固定延迟（schedule）：基于实际结束时间 + 周期。
     • 固定速率（scheduleAtFixedRate）：基于计划开始时间 + 周期（可能追赶延迟）。

关键问题

• 单线程阻塞：一个任务执行过长或崩溃会导致后续任务延迟/终止。
• 异常影响：任务抛出未捕获异常时，整个 Timer 线程停止。
• 资源释放：必须调用 cancel() 避免内存泄漏。

替代方案

ScheduledThreadPoolExecutor 更优：支持多线程、异常隔离、灵活调度。

【困难】时间轮（Time Wheel）的工作原理是什么？

JDK 内置的三种实现定时器的方式，实现思路都非常相似，都离不开任务、任务管理、任务调度三个角色。三种定时器新增和取消任务的时间复杂度都是 O(logn)，面对海量任务插入和删除的场景，这三种定时器都会遇到比较严重的性能瓶颈。对于性能要求较高的场景，一般都会采用时间轮算法来实现定时器。

时间轮通过环形数组分片管理定时任务，以 O(1) 时间复杂度实现高效调度，多级设计兼顾长短延迟任务，是高性能定时器的核心实现方案。

时间轮（Timing Wheel）是 George Varghese 和 Tony Lauck 在 1996 年的论文 Hashed and Hierarchical Timing Wheels: data structures to efficiently implement a timer facility 实现的，它在 Linux 内核中使用广泛，是 Linux 内核定时器的实现方法和基础之一。

核心设计思想

• 环形数组结构：采用环形缓冲区（类似时钟表盘）分层管理定时任务
• 时间分片：将时间划分为固定间隔的槽（tick），每个槽对应一个任务链表
• 层级扩展：支持多级时间轮（小时/分钟/秒）处理不同精度的时间任务

核心组件

工作流程

1. 任务添加

   • 计算目标槽位：槽位 = （当前指针 + 延迟时间/tick) % 轮盘大小
   • 相同槽位的任务以链表形式存储

   1 2	# 示例：tick=1s，轮盘大小=60，添加 10 秒后执行的任务 slot = (current_pos + 10) % 60 # 存入第 10 个槽

2. 时间推进（tick）

   • 每次 tick 移动当前指针到下一槽位
   • 执行该槽位所有任务
   • 多级时间轮：当低级轮转完一圈，高级轮降级一个任务到低级轮

3. 任务降级（多级时间轮）

   1 2	当秒级时间轮（60 槽）转完一圈： 将分钟轮当前槽的任务重新映射到秒轮

关键优势

单级 vs 多级时间轮

实际应用

• Kafka：延迟消息处理（DelayedOperationPurgatory）
• Netty：连接超时控制（HashedWheelTimer）
• Linux 内核：定时器管理

性能对比

HashedWheelTimer 是 Netty 中时间轮算法的实现类。

案例

生产者消费者模式

经典问题

（1）什么是生产者消费者模式

（2）Java 中如何实现生产者消费者模式

知识点

（1）什么是生产者消费者模式

生产者消费者模式是一个经典的并发设计模式。在这个模型中，有一个共享缓冲区；有两个线程，一个负责向缓冲区推数据，另一个负责向缓冲区拉数据。要让两个线程更好的配合，就需要一个阻塞队列作为媒介来进行调度，由此便诞生了生产者消费者模式。

（2）Java 中如何实现生产者消费者模式

在 Java 中，实现生产者消费者模式有 3 种具有代表性的方式：

• 基于 BlockingQueue 实现
• 基于 Condition 实现
• 基于 wait/notify 实现

【示例】基于 BlockingQueue 实现生产者消费者模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

public class ProducerConsumerDemo01 {

    public static void main(String[] args) throws InterruptedException {
        BlockingQueue<Object> queue = new ArrayBlockingQueue<>(10);
        Thread producer1 = new Thread(new Producer(queue), "producer1");
        Thread producer2 = new Thread(new Producer(queue), "producer2");
        Thread consumer1 = new Thread(new Consumer(queue), "consumer1");
        Thread consumer2 = new Thread(new Consumer(queue), "consumer2");
        producer1.start();
        producer2.start();
        consumer1.start();
        consumer2.start();
    }

    static class Producer implements Runnable {

        private long count = 0L;
        private final BlockingQueue<Object> queue;

        public Producer(BlockingQueue<Object> queue) {
            this.queue = queue;
        }

        @Override
        public void run() {
            while (count < 500) {
                try {
                    queue.put(new Object());
                    System.out.println(Thread.currentThread().getName() + " 生产 1 条数据，已生产数据量：" + ++count);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }

    }

    static class Consumer implements Runnable {

        private long count = 0L;
        private final BlockingQueue<Object> queue;

        public Consumer(BlockingQueue<Object> queue) {
            this.queue = queue;
        }

        @Override
        public void run() {
            while (count < 500) {
                try {
                    queue.take();
                    System.out.println(Thread.currentThread().getName() + " 消费 1 条数据，已消费数据量：" + ++count);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }

    }

}

【示例】基于 Condition 实现生产者消费者模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

public class ProducerConsumerDemo02 {

    public static void main(String[] args) {

        MyBlockingQueue<Object> queue = new MyBlockingQueue<>(10);
        Runnable producer = () -> {
            while (true) {
                try {
                    queue.put(new Object());
                    System.out.println("生产 1 条数据，总数据量：" + queue.size());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };

        new Thread(producer).start();

        Runnable consumer = () -> {
            while (true) {
                try {
                    queue.take();
                    System.out.println("消费 1 条数据，总数据量：" + queue.size());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };

        new Thread(consumer).start();
    }

    public static class MyBlockingQueue<T> {

        private final int max;
        private final Queue<T> queue;

        private final ReentrantLock lock = new ReentrantLock();
        private final Condition notEmpty = lock.newCondition();
        private final Condition notFull = lock.newCondition();

        public MyBlockingQueue(int size) {
            this.max = size;
            queue = new LinkedList<>();
        }

        public void put(T o) throws InterruptedException {
            lock.lock();
            try {
                while (queue.size() == max) {
                    notFull.await();
                }
                queue.add(o);
                notEmpty.signalAll();
            } finally {
                lock.unlock();
            }
        }

        public T take() throws InterruptedException {
            lock.lock();
            try {
                while (queue.isEmpty()) {
                    notEmpty.await();
                }
                T o = queue.remove();
                notFull.signalAll();
                return o;
            } finally {
                lock.unlock();
            }
        }

        public int size() {
            return queue.size();
        }

    }

}

【示例】基于 wait/notify 实现生产者消费者模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

public class ProducerConsumerDemo03 {

    public static void main(String[] args) {

        MyBlockingQueue<Object> queue = new MyBlockingQueue<>(10);
        Runnable producer = () -> {
            while (true) {
                try {
                    queue.put(new Object());
                    System.out.println("生产 1 条数据，总数据量：" + queue.size());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };

        new Thread(producer).start();

        Runnable consumer = () -> {
            while (true) {
                try {
                    queue.take();
                    System.out.println("消费 1 条数据，总数据量：" + queue.size());
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        };

        new Thread(consumer).start();
    }

    public static class MyBlockingQueue<T> {

        private final int max;
        private final Queue<T> queue;

        public MyBlockingQueue(int size) {
            max = size;
            queue = new LinkedList<>();
        }

        public synchronized void put(T o) throws InterruptedException {
            while (queue.size() == max) {
                wait();
            }
            queue.add(o);
            notifyAll();
        }

        public synchronized T take() throws InterruptedException {
            while (queue.isEmpty()) {
                wait();
            }
            T o = queue.remove();
            notifyAll();
            return o;
        }

        public synchronized int size() {
            return queue.size();
        }

    }

}

Java 并发面试二

Java 锁

【中等】Java 中，根据不同维度划分，锁有哪些分类？

在 Java 中，锁可以按照 多个维度 进行分类，不同维度的锁适用于不同的并发场景。以下是详细的分类：

按锁的公平性划分

按锁的获取方式划分

按锁的可重入性划分

按锁的共享性划分

按锁的阻塞方式划分

按锁的优化策略划分

按锁的实现方式划分

总结

选择合适的锁取决于：

• 并发竞争程度（高竞争→悲观锁，低竞争→乐观锁）
• 任务执行时间（长任务→公平锁，短任务→非公平锁）
• 读写比例（读多→共享锁，写多→独占锁）
• 是否需要跨 JVM（是→分布式锁）

这些分类帮助开发者根据业务场景选择最优的锁策略，平衡 性能、公平性、一致性。

【中等】悲观锁和乐观锁有什么区别？

以下是悲观锁与乐观锁的详细对比：

选择建议：

• 悲观锁适合”宁可排队等，不能出错”的场景（如金融交易）。
• 乐观锁适合”宁可重试，不要阻塞”的场景（如电商库存）。

【中等】公平锁和非公平锁有什么区别？

Java 中公平锁和非公平锁的对比：

如何选择？

• 选公平锁：

  • 需要严格顺序执行（如订单处理）
  • 避免低优先级线程饥饿
  • 线程任务执行时间差异大

• 选非公平锁：

  • 追求高吞吐量（如秒杀系统）
  • 任务执行时间短且均匀
  • 能接受偶尔的线程饥饿

注意事项：

• 默认行为：ReentrantLock 和 synchronized 默认都是非公平锁（因为性能更好）。
• 性能差异：非公平锁在高并发下吞吐量可提升 **10%~30%**，但可能增加延迟方差。
• synchronized 的公平性：Java 的 synchronized 不支持公平锁，仅 ReentrantLock 可配置。

【中等】synchronized 和 ReentrantLock 有什么区别？

使用差异：

::: code-tabs#synchronized 和 ReentrantLock 使用差异

@tab synchronized 使用

1
2
3
4
5
6
7
8
9
10

// 1. 用于代码块
synchronized (this) {}
// 2. 用于对象
synchronized (object) {}
// 3. 用于方法
public synchronized void test () {}
// 4. 可重入
for (int i = 0; i < 100; i++) {
	synchronized (this) {}
}

@tab ReentrantLock 使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public void test () throw Exception {
	// 1. 初始化选择公平锁、非公平锁
	ReentrantLock lock = new ReentrantLock(true);
	// 2. 可用于代码块
	lock.lock();
	try {
		try {
			// 3. 支持多种加锁方式，比较灵活；具有可重入特性
			if(lock.tryLock(100, TimeUnit.MILLISECONDS)){ }
		} finally {
			// 4. 手动释放锁
			lock.unlock()
		}
	} finally {
		lock.unlock();
	}
}

:::

以下是 synchronized 和 ReentrantLock 的详细对比表格，涵盖 锁机制、功能、性能、使用场景 等核心维度：

关键区别总结

• 灵活性

  • ReentrantLock 更强大：支持公平锁、可中断、超时、多条件变量。
  • synchronized 更简单：自动管理锁，适合基础同步需求。

• 性能差异：JDK 6 后两者性能接近，但 ReentrantLock 在高竞争场景仍略有优势。

• 使用选择建议

  • **选择 synchronized**：
    • 需要简单的代码块同步。
    • 不需要高级功能（如超时、公平锁）。
  • **选择 ReentrantLock**：
    • 需要精细控制（如公平性、可中断）。
    • 需要避免死锁（tryLock）。

• 注意

  • ReentrantLock 必须手动释放锁，否则会导致死锁！
  • synchronized 是 Java 并发的基础，而 ReentrantLock 是它的增强扩展。

适用场景

• synchronized 适用场景：单例模式的双重检查锁、简单的线程安全计数器。
• ReentrantLock 适用场景：
  • 需要公平性的任务队列（如订单处理）。
  • 需要超时控制的资源争用（如避免死锁）。
  • 复杂的多条件线程协调（如生产者-消费者模型）。

【困难】ReentrantLock 的实现原理是什么？

ReentrantLock 基于 AQS（AbstractQueuedSynchronizer）实现：

• 核心依赖：ReentrantLock 通过内部类 Sync（继承 AQS）实现锁机制。
• AQS 作用：提供线程阻塞/唤醒的队列管理（CLH 变体）和状态（state）的原子操作。

锁状态（state）管理

• state 字段：
  • =0：锁未被占用。
  • >0：锁被占用，数值表示重入次数（可重入性）。
• 修改方式：通过 CAS（Compare-And-Swap）保证原子性。

获取锁（公平 / 非公平）

• 公平锁（FairSync）：严格按照 FIFO 顺序获取锁（先检查队列是否有等待线程）。
  • 先检查是否有前驱节点（队列中有无等待线程），有则排队。
  • 无则尝试 CAS 获取锁。
• 非公平锁（NonfairSync，默认）：新线程直接尝试 CAS 抢锁（可能插队），失败才进入队列。
  • 直接尝试 CAS 修改 state（抢锁）。
  • 失败后调用 AQS.acquire() 进入队列等待。

释放锁

1. 减少 state 值（重入次数减 1）。
2. 若 state=0，唤醒队列中的下一个线程（通过 LockSupport.unpark()）。

可重入性

• 记录当前持有锁的线程（exclusiveOwnerThread）。
• 同一线程重复获取锁时，state 递增（无需重新排队）。

关键方法

• **tryLock()**：非阻塞尝试获取锁（直接 CAS）。
• **lockInterruptibly()**：支持中断的锁获取。
• **Condition**：基于 AQS 实现多个等待队列（如 await()/signal()）。

性能优化

• 非公平锁：减少线程切换，提高吞吐量（但可能饥饿）。
• 自旋优化：短暂自旋尝试获取锁，避免立即入队。

总结

ReentrantLock 的核心是通过 AQS 队列 + CAS 操作 实现：

• 锁竞争：通过 state 和 CLH 队列管理线程阻塞/唤醒。
• 灵活性：支持公平性、可中断、超时等高级功能。
• 可重入：记录持有线程和重入次数。

适用于需要精细控制锁行为的场景（如公平性、条件变量）。

【困难】AQS 的实现原理是什么？

AQS（AbstractQueuedSynchronizer）是 Java 并发包（java.util.concurrent.locks）的核心框架，用于构建锁（如 ReentrantLock）和同步器（如 CountDownLatch、Semaphore）。它的核心思想是 CLH 队列 + CAS + 状态管理，提供了一种高效、灵活的同步机制。

关键属性

• 状态变量（state）：一个 volatile 整型变量，用于表示同步状态。不同的同步组件对 state 有不同的解读，例如在 ReentrantLock 里，state 为 0 表示锁未被持有，大于 0 表示锁已被持有，且重入次数就是 state 的值。
• 等待队列（head 和 tail）：指向 FIFO 队列的头尾节点。队列中的每个节点都代表一个等待获取同步状态的线程。每个 Node 包含以下重要属性：
  • **thread**：指向等待获取同步状态的线程。
  • **prev 和 next**：分别指向前一个节点和后一个节点，从而形成双向链表。
  • **waitStatus**：表示节点的等待状态，常见的状态有：
    • CANCELLED（1）：表示该节点对应的线程已取消等待。
    • SIGNAL（-1）：表示该节点的后继节点需要被唤醒。
    • CONDITION（-2）：表示该节点处于条件队列中。
    • PROPAGATE（-3）：用于共享模式下，表明状态需要向后传播。

同步模式

AQS 支持两种同步模式：

• 独占模式：同一时刻仅允许一个线程获取同步状态，例如 ReentrantLock。
  • 获取锁：
    • 线程调用 acquire(int) → tryAcquire(int)（子类实现）。
    • 如果成功（state 修改成功），则获取锁。
    • 如果失败，线程被封装成 Node 加入 CLH 队列，并进入 park() 等待。
  • 释放锁：
    • 线程调用 release(int) → tryRelease(int)（子类实现）。
    • 如果成功，唤醒队列中的下一个线程（unparkSuccessor）。
• 共享模式：同一时刻允许多个线程获取同步状态，例如 CountDownLatch 和 Semaphore。
  • 获取锁：
    • 线程调用 acquireShared(int) → tryAcquireShared(int)（子类实现）。
    • 如果成功（返回 ≥0），获取锁；否则进入队列等待。
  • 释放锁：
    • 线程调用 releaseShared(int) → tryReleaseShared(int)（子类实现）。
    • 如果成功，唤醒后续等待的线程（可能多个）。

关键方法

• 独占模式
  • **tryAcquire(int arg)**：尝试以独占模式获取同步状态，此方法需由子类实现。
  • **acquire(int arg)**：以独占模式获取同步状态，若获取失败则将线程加入队列并阻塞。
  • **tryRelease(int arg)**：尝试以独占模式释放同步状态，需子类实现。
  • **release(int arg)**：以独占模式释放同步状态，若释放成功则唤醒队列中的后继节点。
• 共享模式
  • **tryAcquireShared(int arg)**：尝试以共享模式获取同步状态，需子类实现。
  • **acquireShared(int arg)**：以共享模式获取同步状态，若获取失败则将线程加入队列并阻塞。
  • **tryReleaseShared(int arg)**：尝试以共享模式释放同步状态，需子类实现。
  • **releaseShared(int arg)**：以共享模式释放同步状态，若释放成功则唤醒队列中的后继节点。

::: info AQS 核心机制

CAS（Compare-And-Swap）

使用 Unsafe 类的 compareAndSwapXXX 方法保证 state 和队列操作的原子性。

例如：

1
2
3

protected final boolean compareAndSetState(int expect, int update) {
    return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}

自旋 + park() 等待

• 线程在入队前会自旋尝试获取锁（减少上下文切换）。
• 如果仍然失败，则调用 LockSupport.park() 挂起线程。

公平性控制

• 公平锁：严格按照 CLH 队列顺序获取锁（hasQueuedPredecessors() 检查是否有前驱节点）。
• 非公平锁：新线程可以插队（tryAcquire 直接尝试获取锁，不检查队列）。

:::

::: tip 扩展

从 ReentrantLock 的实现看 AQS 的原理及应用

:::

【困难】ReentrantReadWriteLock 的实现原理是什么？

ReentrantReadWriteLock 是为【读多写少】的并发场景设计的锁实现。

ReentrantReadWriteLock 允许多个线程同时持有读锁，但同一时刻只允许一个线程持有写锁。此外，存在读锁时无法获取写锁，存在写锁时无法获取读锁。

ReentrantReadWriteLock 有以下特性：

• 可重入：读写锁都支持可重入。
• 支持公平锁，默认为非公平锁。
• 支持锁降级：持有写锁可以获取读锁；反之不允许。

ReentrantReadWriteLock 基于 AQS 实现的读写锁，其核心设计思想是将一个 32 位的 int 状态变量拆分为两部分：

• 高 16 位：表示读锁的持有数量（包括重入次数）
• 低 16 位：表示写锁的重入次数

1
2
3
4

状态变量结构：
+-------------------------------+-------------------------------+
|         读锁状态 (16 位）        |         写锁状态 (16 位）        |
+-------------------------------+-------------------------------+

写锁实现（WriteLock）

• 排他锁，使用 AQS 的独占模式
• 获取条件：
  • 读锁计数为 0（没有读锁）
  • 写锁计数为 0 或当前线程已持有写锁（可重入）
• 实现方法：

  1 2 3 4 5 6

  protected final boolean tryAcquire(int acquires) { // 检查是否有读锁或其他线程持有写锁 if (c != 0 && w == 0) return false; // 检查重入或 CAS 设置状态 // ... }

读锁实现（ReadLock）

• 共享锁，使用 AQS 的共享模式
• 获取条件：
  • 没有线程持有写锁，或写锁被当前线程持有（锁降级）
• 实现特点：
  • 使用 ThreadLocal 记录每个线程的重入次数
  • 第一个获取读锁的线程会记录自己（firstReader）
  • 后续线程使用 cachedHoldCounter 优化性能

锁降级实现

1
2
3
4
5
6
7
8
9

// 锁降级示例代码
writeLock.lock();         // 获取写锁
try {
    // 修改数据。..
    readLock.lock();      // 在保持写锁的情况下获取读锁（锁降级关键步骤）
} finally {
    writeLock.unlock();  // 释放写锁，降级为读锁
}
// 此时仍持有读锁，其他线程可以获取读锁但不能获取写锁

关键数据结构

HoldCounter

1
2
3
4

static final class HoldCounter {
    int count;          // 重入次数
    final long tid = Thread.currentThread().getId(); // 线程 ID
}

ThreadLocalHoldCounter

1
2
3
4
5
6

static final class ThreadLocalHoldCounter
    extends ThreadLocal<HoldCounter> {
    public HoldCounter initialValue() {
        return new HoldCounter();
    }
}

性能优化技巧

• firstReader 优化：记录第一个获取读锁的线程，避免 ThreadLocal 查找
• cachedHoldCounter：缓存最近一个获取读锁的线程计数器
• 读锁计数存储：使用 ThreadLocal 保存每个线程的重入次数，避免竞争

【困难】StampedLock 的实现原理是什么？

StampedLock是 JDK8 引入的高性能锁，适合读多写少且追求极致吞吐的场景，但需谨慎处理乐观读失败和死锁风险。

StampedLock 通过版本号+状态位拆分实现无锁读，牺牲重入性和公平性换取更高吞吐，适合短期读操作的并发场景。

StampedLock 支持三种锁模式：

• 写锁（独占锁）：类似ReentrantLock，同一时刻只有一个线程能获取。阻塞其他所有读锁和写锁请求。
• 悲观读锁（共享锁）：允许多线程并发读，但会阻塞写锁请求（类似ReentrantReadWriteLock的读锁）。
• 乐观读（无锁优化）：不阻塞写操作，仅通过tryOptimisticRead()获取一个”邮戳”（版本号），读完后需校验邮戳是否有效（未被写操作修改）。

特性

• 更高的并发度：乐观读允许读操作与写操作并发执行（无阻塞）。
• 不可重入：锁不可重入，嵌套获取可能导致死锁。
• 支持锁升级/降级：
  • 锁降级：写锁→悲观读锁（类似ReentrantReadWriteLock）。
  • 锁升级：乐观读→悲观读锁或写锁（需校验邮戳后尝试转换）。
• **不支持 Condition**：不能像ReentrantLock那样使用await()/signal()。

StampedLock vs. ReentrantReadWriteLock

状态设计

• 64 位长整型状态变量（state）拆分为三部分：
  • 写锁标记（最低位）：WBIT（写锁占用标志）
  • 版本号（中间 7 位）：乐观读的邮戳版本
  • 读锁计数（剩余 56 位）：记录悲观读锁的持有数量

1
2

State 结构：
[读锁计数 (56 位） | 版本号 (7 位） | 写锁标记 (1 位）]

关键操作实现

写锁获取

• CAS 设置 WBIT 位：若成功则获取写锁，失败则进入队列等待
• 版本号+1：每次写锁释放时递增版本号（保证乐观读的可见性）

悲观读锁获取

• 检查无写锁（WBIT=0）时通过 CAS 增加读计数
• 写锁占用时：进入等待队列（类似 AQS 的 CLH 队列）

乐观读实现

1. 调用tryOptimisticRead()获取当前版本号（不修改状态）
2. 读取共享数据
3. 调用validate(stamp)检查版本号是否变化（无写操作则有效）

锁转换机制

**tryConvertToXLock()**：核心转换方法（避免释放再获取的开销）

• 乐观读→悲观读：验证邮戳后直接获取读锁
• 读锁→写锁：当读计数=1 且当前线程唯一持有读锁时可转换

性能优化手段

• 无锁乐观读：完全不阻塞写操作（通过版本号校验）
• 延迟唤醒：读锁释放时不立即唤醒等待线程（减少竞争）
• 自旋优化：短时冲突时先自旋再入队（类似 AQS）

与 AQS 的差异

• 非 AQS 实现：独立的状态机设计（更轻量）
• 无公平性：所有锁均为非公平模式
• 无条件队列：不支持Condition功能

典型使用示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

StampedLock lock = new StampedLock();

// 乐观读示例
long stamp = lock.tryOptimisticRead();
// 读取共享数据。..
if (!lock.validate(stamp)) {
    // 版本失效，转悲观读
    stamp = lock.readLock();
    try {
        // 重新读取数据。..
    } finally {
        lock.unlockRead(stamp);
    }
}

// 写锁示例
long stamp = lock.writeLock();
try {
    // 修改数据。..
} finally {
    lock.unlockWrite(stamp);
}

Java 无锁

【中等】什么是 CAS？CAS 的实现原理是什么？

::: info 什么是 CAS？

:::

CAS（Compare-And-Swap，比较并交换） 是一种 无锁（Lock-Free） 的并发编程技术，基于 比较-交换 实现原子操作。它是现代并发编程的基石，被广泛应用于 Java 的 Atomic 类、ReentrantLock、ConcurrentHashMap 等并发工具中。

CAS 底层实现依赖 CPU 指令（如 CMPXCHG），通过 Unsafe 类调用本地方法。

CAS 的核心应用有：原子类、自旋锁、无锁数据结构（如 ConcurrentHashMap）。

CAS 的核心思想：

• 比较：检查某个内存位置的值是否等于预期值（Expected Value）。
• 交换：如果相等，则更新为新值（New Value），否则不做任何操作。
• 原子性：整个操作由 CPU 指令 保证不可分割，不会出现线程安全问题。

::: info CAS 的实现原理是什么？

:::

（1）底层 CPU 指令支持

在 Java 中，通过 Unsafe 类调用本地方法（Native Method）实现 CAS。更底层的实现依赖于 硬件指令（如 x86 的 CMPXCHG、ARM 的 LL/SC），确保操作是原子的。

1

public final native boolean compareAndSwapInt(Object o, long offset, int expected, int newValue);

（2）CAS 操作流程

1
2
3
4
5
6
7
8

// 伪代码
boolean CAS(Variable var, int expected, int newValue) {
    if (var.value == expected) {  // 比较当前值是否等于预期值
        var.value = newValue;     // 如果相等，更新为新值
        return true;
    }
    return false;  // 否则失败
}

实际执行流程：

1. 读取内存值 V。
2. 比较 V 和预期值 A：
   • 如果 V == A，说明没有其他线程修改过，更新为 B。
   • 如果 V != A，说明值已被修改，放弃更新。
3. 返回操作是否成功。

（3）Java 中的 CAS 实现（以 AtomicInteger 为例）

1
2
3
4

AtomicInteger count = new AtomicInteger(0);

// CAS 操作：如果当前值是 0，则设置为 1
boolean success = count.compareAndSet(0, 1);  // 内部调用 Unsafe.compareAndSwapInt

底层实现：

1
2
3

public final boolean compareAndSet(int expect, int update) {
    return unsafe.compareAndSwapInt(this, valueOffset, expect, update);
}

其中：

• this：目标对象（如 AtomicInteger 实例）。
• valueOffset：字段在对象内存中的偏移量（通过 Unsafe.objectFieldOffset 获取）。
• expect：预期值。
• update：新值。

CAS 的典型应用

（1）原子类

1
2

AtomicInteger atomicInt = new AtomicInteger(0);
atomicInt.incrementAndGet();  // CAS 实现原子自增

底层实现：

1
2
3

public final int incrementAndGet() {
    return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}

（2）自旋锁

1
2
3

while (!CAS(lock, 0, 1)) {  // 尝试获取锁
    // 自旋等待
}

（3）无锁数据结构

• ConcurrentHashMap（JDK 8 使用 CAS + synchronized 替代分段锁）。
• CopyOnWriteArrayList（CAS 保证写入原子性）。

CAS 的优缺点

优点

缺点

CAS vs 锁

【中等】CAS 算法存在哪些问题？

CAS（Compare-And-Swap）是一种无锁并发编程技术，广泛用于 Java 的 Atomic 类、AQS、ConcurrentHashMap 等并发工具中。但它也存在一些问题和限制：

ABA 问题

• 问题描述：变量值从 A → B → A，CAS 检查时认为没有变化，但实际上已经被修改过。
• 影响：可能导致数据不一致（如链表操作时节点被替换但指针仍有效）。
• 解决方案：
  • 使用 版本号/时间戳（如 AtomicStampedReference）。
  • 使用 boolean 标记（如 AtomicMarkableReference）。

自旋产生的 CPU 空转

• 问题描述：如果 CAS 长时间失败，线程会持续自旋（while 循环），占用 CPU 资源。
• 影响：高并发竞争时，可能导致 CPU 使用率飙升。
• 解决方案：
  • 限制自旋次数（如 LongAdder 改用分段 CAS）。
  • 结合 yield() 或 Thread.sleep() 减少竞争。

只能保证单个变量的原子性

• 问题描述：CAS 只能对一个变量进行原子操作，无法保证多个变量的复合操作（如 i++ 和 j--）。
• 影响：需要额外同步机制（如锁）来保证多变量一致性。
• 解决方案：
  • 使用 synchronized 或 ReentrantLock。
  • 设计不可变对象（如 String、BigInteger）。

公平性问题

• 问题描述：CAS 是非公平的，新线程可能比等待队列中的线程更快获取锁。
• 影响：可能导致线程饥饿（某些线程长期得不到执行）。
• 解决方案：
  • 使用公平锁（如 ReentrantLock(true)）。
  • 结合队列调度（如 AQS 的 CLH 队列）。

不适用于复杂操作

• 问题描述：CAS 适合简单操作（如 count++），但不适合复杂逻辑（如数据库事务）。
• 影响：需要拆分为多个 CAS 步骤，可能引入中间状态不一致。
• 解决方案：
  • 使用锁（如 synchronized）。
  • 改用事务内存（如 Clojure STM）。

平台依赖性

• 问题描述：CAS 依赖底层 CPU 指令（如 CMPXCHG），不同架构性能可能差异较大。
• 影响：在 ARM 等弱内存模型平台可能出现意外行为。
• 解决方案：使用 JVM 内置原子类（如 AtomicInteger），而非手动实现。

总结

CAS 在无锁编程中非常高效，但需结合场景权衡利弊。在高竞争环境下，可能需要改用锁或其他并发策略。

【中等】什么是 ThreadLocal？

::: info 什么是 ThreadLocal？

:::

在多线程环境下，共享变量存在并发安全问题。换个思路，如果变量非共享，而是各个线程独享，就不会有并发安全问题。这种思想有个术语叫线程封闭，其本质上就是避免共享。没有共享，自然也就没有并发安全问题。在 Java 中，ThreadLocal 正是根据这个思路而设计的。

ThreadLocal 为每个线程都创建了一个本地副本，这个副本只能被当前线程访问，其他线程无法访问，那么自然是线程安全的。

::: info ThreadLocal 有哪些应用场景？

:::

（1）存储线程私有数据

• 用户会话（Session）管理：每个请求线程存储当前用户的 Session。

  1 2 3 4 5 6

  private static final ThreadLocal<User> currentUser = ThreadLocal.withInitial(() -> null); // 设置当前用户 currentUser.set(user); // 获取当前用户 User user = currentUser.get();

• 数据库连接（Connection）管理：避免传递 Connection 参数。

  1 2	private static final ThreadLocal<Connection> connectionHolder = ThreadLocal.withInitial(() -> dataSource.getConnection());

避免参数透传

问题：多层方法调用需要透传某个上下文参数（如 traceId）。

解决：使用 ThreadLocal 存储，避免方法参数传递。

1
2
3
4
5
6
7

private static final ThreadLocal<String> traceIdHolder = new ThreadLocal<>();

// 在入口处设置 traceId
traceIdHolder.set("req-123");

// 在任意深层方法获取
String traceId = traceIdHolder.get(); // 无需透传参数

（3）线程安全的工具类

例如：SimpleDateFormat 是线程不安全的，但可以用 ThreadLocal 包装：

1
2
3
4
5

private static final ThreadLocal<SimpleDateFormat> dateFormatHolder =
    ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));

// 线程安全地使用
String formattedDate = dateFormatHolder.get().format(new Date());

最佳实践

（1）尽量用 static final

1

private static final ThreadLocal<User> userHolder = new ThreadLocal<>();

避免重复创建 ThreadLocal 实例。

（2）必须调用 remove()

尤其在线程池场景，否则会导致内存泄漏。

（3）推荐初始化默认值

1

ThreadLocal<User> userHolder = ThreadLocal.withInitial(() -> new User());

（4）避免在父子线程间传递

ThreadLocal 不能自动继承，需手动处理（可用 InheritableThreadLocal）。

【中等】ThreadLocal 的原理是什么？

内部结构

ThreadLocal 主要依赖于两个类：ThreadLocal 自身和 ThreadLocalMap。

• Thread 类：每个 Thread 对象内部都有一个类型为 ThreadLocalMap 的成员变量 threadLocals，用于存储该线程的所有 ThreadLocal 变量及其对应的值。
• **ThreadLocalMap**：它是 ThreadLocal 的一个静态内部类，类似于 HashMap，但它使用弱引用的 ThreadLocal 对象作为键，值则是用户设置的对象。

存储机制

• 当调用 ThreadLocal 的 set 方法时，它会首先获取当前线程的 ThreadLocalMap。
• 如果 ThreadLocalMap 存在，则以当前 ThreadLocal 对象为键，将值存储到 ThreadLocalMap 中。
• 如果 ThreadLocalMap 不存在，则创建一个新的 ThreadLocalMap，并将当前 ThreadLocal 对象和值作为第一个元素存入其中。

获取机制

• 当调用 ThreadLocal 的 get 方法时，它会先获取当前线程的 ThreadLocalMap。
• 如果 ThreadLocalMap 存在，则以当前 ThreadLocal 对象为键去查找对应的值。
• 如果 ThreadLocalMap 不存在或者没有找到对应的值，则调用 initialValue 方法（可以通过继承 ThreadLocal 类并重写该方法来设置初始值）来获取初始值，并将其存储到 ThreadLocalMap 中。

弱引用机制

ThreadLocalMap 的键是对 ThreadLocal 对象的弱引用。这意味着当外部对 ThreadLocal 对象的强引用被释放后，ThreadLocal 对象会在下次垃圾回收时被回收。这样可以避免内存泄漏，因为如果使用强引用，即使外部不再使用 ThreadLocal 对象，它也不会被回收，从而导致 ThreadLocalMap 中的条目一直存在。

【中等】如何解决 ThreadLocal 内存泄漏问题？

ThreadLocal 的内存泄漏问题源于其特殊的 “弱引用 Key + 强引用 Value” 存储结构，主要发生在以下两种场景：

(1) Key 被回收，Value 残留（主要泄漏场景）

• ThreadLocal 实例（Key）是弱引用，会被 GC 回收
• 对应的 Value 是强引用，会持续占用内存
• 导致 ThreadLocalMap 中出现 key=null 但 value≠null 的无效 Entry

(2) 线程长期存活时的累积泄漏

• 线程池复用线程（如 Tomcat worker 线程）
• 每次任务执行后未调用 remove()
• 导致多个无效 Entry 堆积在 ThreadLocalMap 中

::: code-tabs#内存泄漏的具体场景

@tab 线程池环境未清理

1
2
3
4
5
6
7
8

ExecutorService pool = Executors.newFixedThreadPool(5);
ThreadLocal<BigObject> tl = new ThreadLocal<>();

pool.execute(() -> {
    tl.set(new BigObject());  // 存储大对象
    // 业务逻辑。..
    // 缺少 tl.remove()！线程复用后旧 Value 仍然存在
});

后果：线程被重复使用时，之前的 BigObject 实例无法被回收

@tab 静态 ThreadLocal 长期持有

1
2
3
4
5
6
7

static final ThreadLocal<User> userHolder = new ThreadLocal<>();

void processRequest() {
    userHolder.set(new User()); // 每次请求新 User 对象
    // 业务逻辑。..
    // 忘记调用 userHolder.remove()
}

后果：Web 应用中，线程处理多个请求后，内存中堆积多个废弃 User 对象

@tab 使用非 static 的 ThreadLocal

1
2
3
4
5
6
7
8

class Service {
    ThreadLocal<Config> configHolder = new ThreadLocal<>(); // 非 static

    void serve() {
        configHolder.set(loadConfig());
        // ...
    }
}

后果：每次创建 Service 实例都会产生新的 ThreadLocal，增加内存泄漏风险

:::

解决方案与最佳实践

(1) 强制清理方案

代码示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// 方案 1：try-finally（推荐）
try {
    threadLocal.set(data);
    // 业务逻辑。..
} finally {
    threadLocal.remove();
}

// 方案 2：Spring 拦截器
@Override
public void afterCompletion(HttpServletRequest request,
                          HttpServletResponse response,
                          Object handler, Exception ex) {
    threadLocal.remove();
}

(2) 设计优化方案

1. 使用 static final 修饰

   1	private static final ThreadLocal<User> holder = new ThreadLocal<>();

   • 避免重复创建 ThreadLocal 实例

2. 初始化默认值

   1	ThreadLocal.withInitial(() -> new LightweightObject());

   • 避免持有大对象

3. 改用 InheritableThreadLocal（需谨慎）

   • 适用于需要父子线程传递数据的场景

ThreadLocalMap 的自动清理机制

虽然 ThreadLocalMap 有部分自清理能力，但不可依赖：

• set() 触发清理：探测式清理（expungeStaleEntry）
• get() 触发清理：启发式清理（cleanSomeSlots）
• remove() 触发清理：完全清理指定 Entry

重要结论：

• 自动清理不彻底（只清理部分无效 Entry）
• 高并发场景可能清理不及时
• 必须显式调用 remove()

【中等】InheritableThreadLocal 的实现原理是什么？

核心设计目标

• 线程间值继承：子线程自动继承父线程的 ThreadLocal 值
• 与 ThreadLocal 兼容：继承自ThreadLocal，保持相同 API

数据存储位置

继承自ThreadLocal，但使用线程对象的独立字段；Thread.inheritableThreadLocals（专门存储可继承的变量）

线程创建时的值拷贝

• 触发时机：当父线程创建子线程（Thread.init()方法）

• 拷贝逻辑：

  1 2 3 4

  if (parent.inheritableThreadLocals != null) { this.inheritableThreadLocals = ThreadLocal.createInheritedMap(parent.inheritableThreadLocals); }

• 深拷贝保证隔离：子线程获得父线程值的独立副本（修改互不影响）

值传递规则

• 仅初始化时拷贝：子线程创建后父线程对值的修改不再影响子线程
• 浅拷贝问题：若存储引用对象，父子线程仍共享同一对象（需开发者自行处理线程安全）

与 ThreadLocal 的对比

使用注意事项

• 对象共享风险：若值是可变的引用对象，需自行保证线程安全
• 线程池陷阱：线程池复用线程时会导致旧值残留（需手动清理）
• 性能影响：大量线程创建时，值拷贝可能成为瓶颈

典型应用场景

1
2
3
4
5
6
7
8

// 父线程设置值
InheritableThreadLocal<String> itl = new InheritableThreadLocal<>();
itl.set("parent_value");

new Thread(() -> {
    // 子线程自动读取到父线程设置的值
    System.out.println(itl.get()); // 输出：parent_value
}).start();

实现局限

• 不支持动态更新：子线程启动后父线程的修改不可见
• 无回调机制：无法像ThreadLocal的initialValue()那样自定义子线程初始值

【中等】Java 中支持哪些原子类？

原子性是确保并发安全三大特性之一。为了兼顾原子性以及锁带来的性能问题，Java 引入了 CAS （主要体现在 Unsafe 类）来实现非阻塞同步（也叫乐观锁），CAS 底层基于 CPU 指令（硬件支持）支持，具有原子性。并基于 CAS ，提供了一套原子工具类。

原子类比锁的粒度更细，更轻量级，并且对于在多处理器系统上实现高性能的并发代码来说是非常关键的。原子变量将发生竞争的范围缩小到单个变量上。

原子类相当于一种泛化的 volatile 变量，能够支持原子的、有条件的读/改/写操作。

原子类可以分为 5 个类别，这 5 个类别提供的方法基本上是相似的：

• 基本数据类型：基本数据类型原子类针对 Java 基本类型提供原子操作。
  • AtomicBoolean - 布尔类型原子类
  • AtomicInteger - 整型原子类
  • AtomicLong - 长整型原子类
• 引用数据类型：Java 数据类型分为 基本数据类型 和 引用数据类型 两大类（不了解 Java 数据类型划分可以参考： Java 基本数据类型 ）。如果想针对引用类型做原子操作怎么办？Java 也提供了相关的原子类：
  • AtomicReference - 引用类型原子类
  • AtomicMarkableReference - 带有标记位的引用类型原子类
  • AtomicStampedReference - 带有版本号的引用类型原子类
• 数组数据类型：数组类型的原子类为数组元素提供了 volatile 类型的访问语义，这是普通数组所不具备的特性——**volatile 类型的数组仅在数组引用上具有 volatile 语义**。
  • AtomicIntegerArray - 整形数组原子类
  • AtomicLongArray - 长整型数组原子类
  • AtomicReferenceArray - 引用类型数组原子类
• 属性更新器类型：属性更新器支持基于反射机制的更新字段值的原子操作。
  • AtomicIntegerFieldUpdater - 整型字段的原子更新器
  • AtomicLongFieldUpdater - 长整型字段的原子更新器
  • AtomicReferenceFieldUpdater - 原子更新引用类型里的字段
• 累加器：相比原子化的基本数据类型，速度更快，但是不支持 compareAndSet() 方法。
  • DoubleAdder - 浮点型原子累加器
  • LongAdder - 长整型原子累加器。
  • DoubleAccumulator - 更复杂的浮点型原子累加器
  • LongAccumulator - 更复杂的长整型原子累加器

原子类底层实现

所有原子类都基于 Unsafe + CAS 实现：

1
2
3

public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

• Unsafe：直接操作内存（CAS 原子指令）
• valueOffset：字段内存偏移量

适用场景

• 读多写少：AtomicXXX
• 高并发写：LongAdder
• 无锁数据结构：AtomicReference + CAS

注意事项

• 原子类 不适用于复合操作（如 check-then-act，仍需锁）
• LongAdder 适合统计，但 不保证实时精确值（调用 sum() 时才合并）。LongAdder 在操作后的返回值只是一个近似准确的数值，但是 LongAdder 最终返回的是一个准确的数值，所以在一些对实时性要求比较高的场景下，LongAdder 并不能取代 AtomicInteger 或 AtomicLong。

Java 基础面试三

Java 泛型

【中等】Java 泛型的作用是什么？

::: info Java 泛型是什么？

:::

泛型允许在类、接口、方法上使用类型参数（如 <T>），使代码能适应多种数据类型，同时保证类型安全。

::: info Java 泛型有什么用？

:::

• 类型安全：编译时检查类型，避免运行时 ClassCastException。
• 代码复用：同一套逻辑可处理不同数据类型（如 List<String> 和 List<Integer>）。
• 消除强制转换：直接使用泛型类型，无需手动转换（如 (String) list.get(0)）。

::: info Java 泛型有什么特性？

:::

• 类型擦除：泛型仅在编译时有效，运行时类型信息会被擦除（List<String> 运行时变成 List）。
• **通配符 <?>**：表示未知类型（如 List<?> 可接受任意类型的 List）。
• 界限限定：
  • T extends Class（限定类型范围，如 <T extends Number>）。
  • <? super T>（支持父类类型）。

简单示例

1
2
3
4
5
6
7
8
9
10
11

// 泛型类
class Box<T> {
    private T content;
    public void set(T content) { this.content = content; }
    public T get() { return content; }
}

// 使用
Box<String> box = new Box<>();
box.set("Hello");
String value = box.get(); // 无需强制转换