编程 on Liangweidong's blog

AQS原理简述

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.5 AQS原理简述

考察意图：理解AQS作为JUC基石的原理深度，而非泛泛而谈"抽象队列同步器"。

回答样板：

AQS（AbstractQueuedSynchronizer）是JUC锁和同步器（ReentrantLock、CountDownLatch、Semaphore等）的基石。

核心三要素：

volatile int state——同步状态（独占模式0表示未锁，大于0表示已锁；共享模式表示剩余资源数）
CLH变体双向队列——等待获取锁的线程队列，每个节点通过CAS和前驱节点的waitStatus状态协作
模板方法模式——子类实现tryAcquire/tryRelease等抽象方法决定同步语义，AQS内部维护队列和状态流转

独占模式获取锁流程：tryAcquire尝试获取 → 成功则返回 → 失败则将当前线程包装成Node加入等待队列 → 在队列中自旋或阻塞等待前驱节点唤醒。

项目层面：日常使用多是读API层面（直接用ReentrantLock、CountDownLatch），没有深入到定制AQS同步器那个层面。但对AQS的CLH队列原理、state状态机有清晰理解。

陷阱提示：说"精通AQS"结果说不出CLH队列原理；泛泛而谈"抽象队列同步器"没深度。

备选话术：我日常使用线程池处理异步任务（如设备数据批量写入），对JUC核心类有实操经验。但AQS源码实现细节或无锁编程（CAS/Unsafe）不是日常写代码的层面，坦诚需要查资料。

JDK LTS版本新特性（8 / 11 / 17 / 21）

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.8 JDK LTS版本新特性（8 / 11 / 17 / 21）

考察意图：是否跟得上Java生态演进，知道每个LTS版本的关键变化和升级价值。

回答样板：

Oracle 2017年宣布6个月发布周期（3月/9月），每2年一个LTS（长期支持版本）。截至目前四个主要LTS：

JDK 8（2014.03）——革命性版本，目前仍有海量存量：

特性	说明	实际价值
Lambda + Stream API	函数式编程，集合操作的声明式写法	Java 8的核心卖点，改变了Java编程范式
Optional类	优雅处理null，避免NPE	链式调用，配合orElse/orElseGet兜底
新的日期时间API	java.time包（LocalDate/LocalDateTime/Instant）	线程安全+不可变对象，替代joda-time
接口默认方法	`default`关键字，接口可提供默认实现	不破坏实现类的情况下给接口加新方法
Metaspace替代PermGen	方法区移到本地内存	不再OOM: PermGen space
CompletableFuture	异步编程组合能力	thenApply/thenCompose/thenCombine编排异步任务

JDK 11（2018.09 LTS）——模块化成熟、HTTP Client标准化：

特性	说明	实际价值
Java Platform Module System	从JDK 9开始的模块化（Project Jigsaw），JDK 11达稳定	拆大单体应用、控制可访问性、`module-info.java`声明依赖（团队小不一定需要）
HttpClient标准化	`java.net.http.HttpClient`替代第三方库	原生支持HTTP/2、WebSocket、异步请求
ZGC实验性	亚毫秒停顿GC	JDK 11首次引入（实验性），JDK 15生产可用
Epsilon GC	只分配内存不回收的"假GC"	性能基准测试、短生命周期应用
Flight Recorder开源	JFR性能分析工具（原商业版）	零性能损耗的生产环境Profiling
var局部变量推导	`var list = new ArrayList<String>()`	减少样板代码（从JDK 10开始）
移除内容	Java EE模块（JAXB/JAX-WS）被移除	迁移要注意：旧项目升级要额外加JAXB等依赖
收费政策	Oracle JDK 11起商用收费	OpenJDK免费，以此版本为分界线

JDK 17（2021.09 LTS）——当前主流LTS，G1/GC全面成熟：

特性	说明	实际价值
Sealed Classes	`sealed class Shape permits Circle, Rectangle`	受控继承，编译期保证子类列表，增强类型安全
Pattern Matching for switch	switch支持类型匹配和解构（预览）	减少instanceof+强转的模板代码
Record类	`record Point(int x, int y){}` 一行搞定数据载体	消除getter/setter/equals/hashCode/toString（从JDK 14正式）
Text Blocks	`"""..."""` 多行文本块	SQL/JSON/HTML不再用string拼接（从JDK 15正式）
增强型伪随机数生成器	新接口+新算法（LXM系列）	高性能多线程随机数生成
Foreign Function & Memory API	替代JNI的现代方案（孵化）	安全高效调用C/C++代码
macOS AArch64支持	原生支持Apple M1/M2芯片	无需Rosetta转译
G1成为事实标准	多年打磨，大堆场景表现稳定	多数项目升级JDK 17的直接理由

JDK 21（2023.09 LTS）——最新LTS，虚拟线程时代来临：

特性	说明	实际价值
Virtual Threads（虚拟线程）	Project Loom正式落地	JDK 21最大卖点——数百万轻量级线程，阻塞操作几乎免费。Spring Boot 3.2已集成
Pattern Matching for switch（正式）	switch模式匹配结束预览，正式GA	类型安全+解构式编程
Record Patterns	嵌套解构Record对象	`if (p instanceof Point(int x, int y) && x > 0)`
Sequenced Collections	有序集合统一接口 `getFirst()/getLast()/addFirst()/addLast()`	List/Deque/SortedSet有统一的操作有序元素的API
String Templates（预览）	`STR."Hello \{name}"` 字符串模板	替代String.format和字符串拼接
Scoped Values（预览）	线程间共享不可变数据的新方案	替代ThreadLocal部分场景（轻量、明确生命周期）
Structured Concurrency（预览）	结构化并发，`StructuredTaskScope`	把多个并发子任务作为一个"工作单元"管理
ZGC正式支持分代	ZGC从单代发展为分代回收	进一步提升吞吐量
Key Encapsulation Mechanism API	抗量子加密（PQC）支持	面向未来的安全

LTS升级路径建议：

1
2
3


JDK 8 ──→ JDK 11（稳妥保守派，最小迁移成本）
 ──→ JDK 17（推荐跳板，G1成熟+Record+密封类）
 ──→ JDK 21（激进尝鲜派，虚拟线程巨大诱惑）

实际项目选型经验：

目前主力在JDK 8上，原因是客户本地部署环境限制——很多客户只有JDK 8的授权或安全基线认证。升级到JDK 11/17的最大阻力不是技术（代码兼容性很好），而是客户的环境审批流程。但如果是新项目或云端部署，我会直接选JDK 17——Record+Sealed Classes提升代码表达力、G1比JDK 8的Parallel更稳定、长期支持到2029年。如果场景有高并发连接需求（比如Netty做数万设备同时接入），那我就选JDK 21——虚拟线程让一个TCP连接一个虚拟线程成为可能，代码模型从异步回调退化为同步写法但性能不降。

陷阱提示：把var说成"和JS一样动态类型"（var是编译期类型推断，运行时强类型）；不知道JDK 11 Oracle JDK开始商用收费；不知道ZGC不同版本的状态（实验性/生产可用/分代）；把Record和Lombok @Data简单等同（Record是不可变对象，Lombok是可变）；不知道虚拟线程和平台线程的本质区别（虚拟线程由JVM调度，不绑定OS线程）。

JVM调优常用参数

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.4 JVM调优常用参数

考察意图：能否根据实际场景选择合适的JVM参数，而非无脑复制粘贴。

回答样板：

基础内存参数：

参数	含义	常见设置
`-Xms` / `-Xmx`	初始/最大堆大小	建议设为相同值，避免堆动态扩缩带来的GC抖动。4G服务通常 `-Xms4g -Xmx4g`
`-Xss`	线程栈大小	默认1MB。线程数多且调用栈浅可缩小（512k），递归深可加大
`-XX:NewRatio`	老年代:新生代比例	默认2（Old=堆的2/3，Young=1/3）。高并发短命对象可调为1
`-XX:SurvivorRatio`	Eden:Survivor比例	默认8（Eden:S0:S1=8:1:1）。大多数场景不需改
`-XX:MaxTenuringThreshold`	晋升老年代年龄阈值	默认15（CMS默认6）。值小则对象快速晋升但可能过早填满老年代
`-XX:MetaspaceSize` / `-XX:MaxMetaspaceSize`	元空间初始/最大大小	默认无上限（受物理内存限制）。动态生成类多的场景建议设上限防泄漏。典型256m-512m

GC日志参数：

1
2
3
4
5
6
7
8


# JDK 8 经典三件套
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/to/gc.log
-XX:+PrintHeapAtGC # GC前后打印堆快照（排查内存泄漏利器）
-XX:+PrintTenuringDistribution # 打印各年龄段的存活对象分布

# JDK 9+ 统一日志
-Xlog:gc*=info:file=/path/to/gc.log:time,level,tags:filecount=10,filesize=100M
# gc* 表示所有GC相关日志，info级别，滚动10个文件每个100MB

OOM排查必开：

参数	作用
`-XX:+HeapDumpOnOutOfMemoryError`	OOM时自动dump堆快照，生产环境必须开
`-XX:HeapDumpPath=/path/to/dumps`	dump文件路径，防止撑爆根目录
`-XX:OnOutOfMemoryError="kill -9 %p"`	OOM时执行自定义命令（注意安全隐患）

G1调优参数：

参数	含义	建议
`-XX:MaxGCPauseMillis`	期望最大停顿时间	默认200ms，不要设太低（比如10ms）——G1达不到会疯狂GC反而性能下降。服务端通常50-200ms
`-XX:G1HeapRegionSize`	Region大小	默认堆/2048，取值1/2/4/8/16/32M。大对象多可调大
`-XX:ConcGCThreads`	并发GC线程数	默认≈CPU核数的1/4。CPU资源紧张时减半
`-XX:InitiatingHeapOccupancyPercent`	触发并发标记的堆占用阈值	默认45%。堆占用达此值触发并发标记周期。值设太低频繁GC浪费CPU，太高预留不够触发Full GC

真实配置示例——安全生产平台（JDK 8, 4核8G）：

1
2
3
4
5
6
7
8
9


-Xms4g -Xmx4g
-XX:+UseG1GC
-XX:MaxGCPauseMillis=100
-XX:G1HeapRegionSize=4m
-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=/data/logs/dumps
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/data/logs/gc-%t.log
-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=50M

陷阱提示：把线上配置直接复制粘贴但说不清每个参数的业务取舍原因；设 MaxGCPauseMillis=10显得不专业；不知道生产环境必须开HeapDumpOnOutOfMemoryError。

JVM调优工具实战

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.5 JVM调优工具实战

考察意图：能否独立的在生产环境排查问题，使用合适的工具定位根因。

回答样板：

Arthas——线上诊断神器：

阿里开源的Java诊断工具，零侵入，直接attach到运行中的Java进程，线上排查首选。

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


# 启动
java -jar arthas-boot.jar
# 选择目标Java进程即可

# 最常用命令
dashboard # 实时看板：线程/内存/GC/CPU
thread -n 5 # CPU最高的5个线程
thread -b # 找出死锁
jad com.xx.MyService # 反编译已加载的类，验证线上版本
watch com.xx.MyService myMethod "{params,returnObj,throwExp}" -x 3 # 监控方法入参/出参/异常
trace com.xx.MyService myMethod -n 5 # 追踪方法调用链路，找出哪个子步骤耗时最长
tt -t com.xx.MyService myMethod # 记录方法调用（TimeTunnel），支持重放
vmoption # 查看JVM参数
vmtool --action getInstances -c com.xx.MyClass --limit 10 # 获取堆中某类实例
monitor -c 5 com.xx.MyService myMethod # 监控方法调用次数/成功率/平均耗时

实际场景：一次线上接口变慢，用Arthas的trace一追踪，发现是下游规则引擎的Drools session创建占了80%耗时——KieSession没做池化每次new一个。加了KieSession对象池后恢复。

JDK自带工具——四件套：

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


# jps —— 列出Java进程
jps -lv # 列出所有Java进程，显示JVM参数和main类

# jstat —— JVM统计监控（实时看GC）
jstat -gcutil PID 1000 10 # 每秒打印一次GC统计，共10次
# 输出关键列：S0/S1(Eden+Survivor使用率), E(eden), O(old), M(metaspace), YGC/YGCT(youngGC次数/耗时), FGC/FGCT(fullGC)
# 解读：FGC频繁 + FGCT高 → 老年代不足或内存泄漏
# E接近100%然后骤降 → 正常Minor GC
# O持续增长不降 → 内存泄漏信号

# jmap —— 堆内存分析
jmap -heap PID # 堆内存概览（各区域大小和使用率）
jmap -histo:live PID | head -20 # 堆中存活对象统计（top 20，强制执行一次Full GC）
jmap -dump:format=b,file=heap.hprof PID # 堆dump（生产慎用，会STW）

# jstack —— 线程堆栈分析
jstack PID > thread.log # 打印线程堆栈
jstack -l PID # 额外打印锁信息
# grep查找：BLOCKED（锁等待）/ WAITING（等待唤醒）/ TIMED_WAITING（超时等待）/ RUNNABLE（正在执行）
# 看线程名：如果全是http-nio-xxx-WAITING → 数据库或下游服务慢

MAT（Memory Analyzer Tool）——堆dump分析：

1
2
3
4
5
6


# 先用 jmap dump 堆快照，然后用MAT打开分析
# MAT直接点"Leak Suspects Report" → 自动分析内存泄漏嫌疑
# 核心操作：
# 1. Histogram：按类统计对象数量和内存占用，找大对象
# 2. Dominator Tree：支配树——最大的内存持有者
# 3. Path to GC Roots：某个对象为什么没被回收（引用链追溯到GC Root）

实际场景：OOM排查，MAT打开dump→ Dominator Tree发现HashMap占3.2GB→ Path to GC Roots找到是定时任务的全量缓存→改成分页+本地缓存解决。

jinfo——查看/修改JVM运行时参数：

1
2


jinfo -flags PID # 查看所有参数（包括默认值）
jinfo -flag +PrintGC PID # 运行时动态开启GC日志（部分参数支持动态修改）

生产环境排查最佳路径：

遇到CPU飙升 → Arthas dashboard + thread -n 5 → 定位到具体线程 → jad反编译验证 → 改代码
遇到内存泄漏 → jstat -gcutil观察O区持续增长 → jmap -dump → MAT分析Dominator Tree → Path to GC Roots → 改代码
遇到死锁 → jstack -l → 搜DEADLOCK → 或Arthas thread -b
遇到接口变慢 → Arthas trace → 定位最耗时的子调用 → 深入分析

陷阱提示：只会用jps/jstat但说不清每列含义；线上 jmap -dump不提醒STW风险；不知道Arthas的attach机制（VirtualMachine.attach不需要Agent）。

JVM调优实战案例

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.6 JVM调优实战案例

考察意图：验证完整的排查→定位→解决→验证闭环能力。

案例一：定时任务导致Full GC：

危废平台上线后，每周固定时间接口响应从200ms飙升到5秒以上。排查：jstat -gcutil看发现老年代每周末凌晨突增 → jmap -dump堆内存用MAT分析 → Dominator Tree发现HashMap缓了几百万条危废联单数据 → 根因是定时任务没做分页，一次load全量数据。解决方案不是调JVM参数，而是改代码——Caffeine本地缓存（最大条目+过期时间），定时任务改分批。改完后Full GC停顿从1.2秒降到100ms以内。教训：JVM调优很多时候改代码比改参数更有效。

案例二：Metaspace溢出：

生产环境切流量后运行12小时左右突然 OOM: Metaspace。排查：jstat -gcutil看MU（Metaspace使用率）接近100% → jmap -clstats看加载的类数量异常高（正常几千，它几百万）→ Arthas vmtool查看发现大量 com.sun.proxy.$ProxyXXX类 → 定位到Groovy脚本引擎每次执行规则都 new GroovyClassLoader()但没关 → ClassLoader泄漏导致反复加载同类→ Metaspace撑爆。解决：GroovyClassLoader改单例复用，加 -XX:MaxMetaspaceSize=256m兜底限流。

案例三：G1停顿时间优化：

G1 GC后P99延迟偶尔飙到800ms。排查GC日志发现Mixed GC的Cleanup阶段耗时400ms——老年代Region中大对象过多。-XX:G1HeapRegionSize从2MB调到4MB（让大对象进Humongous Region而非普通Old Region），加上 -XX:+ParallelRefProcEnabled并行处理Reference对象，-XX:MaxGCPauseMillis=100让G1自动收紧回收范围。优化后P99压到300ms以内。

陷阱提示：只讲成功案例不讲失败教训；编造数据（面试官可能现场让你画内存布局图）。

JVM类型对比（HotSpot / OpenJ9 / GraalVM）

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.7 JVM类型对比（HotSpot / OpenJ9 / GraalVM）

考察意图：是否了解JVM生态的多样性，能根据场景推荐合适的JVM实现。

回答样板：

主流JVM实现有三个阵营：

HotSpot VM——Oracle/OpenJDK默认，绝对主流

市场份额：Java服务端90%+在用
核心优势：**C2编译器（Server Compiler）**做了二十多年极致优化，逃逸分析、内联、循环优化极其成熟；G1/ZGC等现代回收器最先落地；生态最完整
JDK 8起HotSpot与JRockit合并，吸收了JRockit的Mission Control、Flight Recorder（JFR）等运维工具
劣势：启动慢、内存占用高——Spring Boot应用空跑也要200MB+堆。不适合短生命周期场景（Serverless、FaaS）

OpenJ9（Eclipse OpenJ9）——IBM捐献，低内存场景

前身是IBM J9 VM，2017年捐给Eclipse基金会
核心优势：极低内存占用——同等应用比HotSpot少30-50%内存；启动速度快；Shared Classes Cache（SCC）——AOT编译缓存，多次启动复用编译结果
垃圾回收：GenCon（分代并发，类似G1）+ Balanced（针对大堆）+ Metronome（实时GC，可配置停顿上限）
劣势：生态和工具链不如HotSpot完善，部分框架兼容性问题；G1/ZGC等效方案不如HotSpot成熟
适用场景：云原生/Serverless（启动快、内存省）、微服务容器化部署（每个Pod省200MB很可观）、嵌入式设备

GraalVM——多语言+AOT编译

Oracle实验室项目，定位是"通用虚拟机"——不止跑Java，还能跑JavaScript、Python、Ruby、R、WASM
两大杀手级特性：
- Native Image（AOT编译）：将Java应用编译为独立二进制，毫秒级启动、内存占用几十MB，非常适合Serverless和容器化。Spring Boot 3.0+官方支持GraalVM Native Image
- Truffle框架：多语言互调用，Java代码直接调Python/JS函数，零JNI开销
两种模式：Community Edition（免费，Native Image支持有限）+ Enterprise Edition（收费，Native Image+PGO优化+多语言商业支持）
劣势：AOT编译限制——限制反射/动态代理/动态类加载（需要配置 reflect-config.json等元数据）；编译时间长（小项目几分钟，大项目几十分钟）；闭包分析可能漏掉运行时动态行为导致编译失败
适用场景：Serverless/FaaS（毫秒级冷启动）、CLI工具、嵌入式、微服务容器镜像瘦身

场景选型速览：

场景	推荐JVM	原因
传统服务端/企业应用	HotSpot	生态成熟、性能最稳定、GC方案最丰富
云原生/容器化微服务	OpenJ9 或 GraalVM	内存省、启动快、镜像小
Serverless/FaaS	GraalVM Native Image	毫秒启动、极低内存
多语言混合项目	GraalVM Truffle	Java+Python/JS/R互调
嵌入式/IoT	OpenJ9	内存占用可控
实时响应（金融/交易）	HotSpot + ZGC	亚毫秒停顿

陷阱提示：只知道HotSpot不知道有其他JVM实现；把GraalVM说成"就是编译成二进制的"忽略了多语言和Truffle；不知道GraalVM Native Image的限制（反射配置、编译时间）。

JVM内存模型

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.1 JVM内存模型

考察意图：是否理解各内存区域的职责、存储内容、以及OOM的发生场景。

回答样板：

JVM运行时数据区分为线程私有和线程共享两大类，共5个核心区域：

区域	共享性	存储内容	OOM场景
程序计数器	线程私有	当前线程执行的字节码行号指示器	唯一不会OOM的区域
虚拟机栈	线程私有	栈帧（局部变量表+操作数栈+动态链接+返回地址）	线程过多或递归过深：StackOverflowError
本地方法栈	线程私有	Native方法的栈帧	与虚拟机栈类似
堆（Heap）	线程共享	对象实例、数组	对象过多且GC无法回收：java.lang.OutOfMemoryError: Java heap space
方法区（元空间）	线程共享	类元数据、静态变量、常量池、JIT编译缓存	动态生成类过多或常量池溢出：OOM: Metaspace

JDK 8关键变化——永久代→元空间：

JDK 7及之前，方法区用永久代（PermGen）实现，属于JVM堆内存的一部分，受-XX:MaxPermSize限制。JDK 8移除了永久代，改用本地内存中的元空间（Metaspace），默认只受物理内存限制。好处：之前永久代大小难以预估（加载的类数量不确定），经常导致OOM: PermGen space。改用元空间后，类元数据放在堆外的本地内存，容量弹性更大。但风险是——如果不设-XX:MaxMetaspaceSize，动态类加载失控会吃光物理内存。

堆内存分代结构：

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


┌───────────────────────────────────────────┐
│ 堆 (Heap) │
├─────────────────┬─────────────────────────┤
│ 新生代(Young) │ 老年代(Old) │
│ ┌────┬────┬───┐│ │
│ │Eden│ S0 │ S1││ │
│ │ 8 │ 1 │ 1 ││ │
│ └────┴────┴───┘│ │
│ 默认比例 8:1:1 │ │
├─────────────────┴─────────────────────────┤
│ 新生代:老年代 ≈ 1:2 (默认 NewRatio=2) │
└───────────────────────────────────────────┘

新生代：新创建的对象。Eden区（80%）+ Survivor 0（10%）+ Survivor 1（10%）
老年代：长期存活对象。经历多次Minor GC仍存活的对象晋升至此
对象晋升流程：Eden分配 → 首次Minor GC存活进S区 → 每次Minor GC存活Age+1 → Age达到MaxTenuringThreshold（默认15）→ 晋升老年代。动态年龄判定：S区中同龄对象总大小超过S区50%时，该年龄及以上对象直接晋升

为什么需要两个Survivor区？ 解决内存碎片化——每次Minor GC，将Eden+From Survivor存活对象copy到To Survivor，然后清空Eden和From，From和To角色互换。始终保持一块Survivor为空，避免碎片化。这就是复制算法在新生代的落地。

陷阱提示：说不清各个区域存什么；把方法区和元空间等同（元空间是实现，方法区是规范）；不知道永久代→元空间的JDK 8变化。

synchronized vs Lock

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.1 synchronized vs Lock

考察意图：能否理解synchronized和Lock的原理差异和选型依据。

回答样板：

synchronized是JVM内置锁，由monitorenter/monitorexit字节码指令实现，自动释放锁，非公平锁，适合简单同步场景。

Lock（ReentrantLock）是JDK API级别的锁，通过AQS（AbstractQueuedSynchronizer）实现，必须手动释放（finally中unlock），支持公平锁、可中断获取锁、尝试获取锁超时、多条件变量（Condition），适合复杂同步场景。

JDK 6以后synchronized做了锁升级优化——偏向锁 → 轻量级锁 → 重量级锁，单线程竞争场景下性能差距不大。

追问预判：

追问：“synchronized的锁升级过程具体是怎样的？”

无锁状态 → 偏向锁：Mark Word存储线程ID，同一线程重入不走CAS，直接判断线程ID一致 → 轻量级锁：多个线程交替竞争时，自旋CAS尝试获取锁，Mark Word存锁记录指针 → 重量级锁：自旋超过阈值（默认10次或自适应），升级为OS互斥量，线程阻塞挂起。本质是空间换时间——偏向锁和轻量级锁尽力减少内核态切换，重量级锁是兜底方案。

陷阱提示：说不清锁升级过程；以为synchronized一直是重量级锁。

ThreadLocal原理与内存泄漏

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.3 ThreadLocal原理与内存泄漏

考察意图：是否理解ThreadLocal的实现原理、内存泄漏成因及规避方式。

回答样板：

每个Thread内部维护一个ThreadLocalMap，key是ThreadLocal实例的弱引用（WeakReference），value是线程持有的值。

内存泄漏原因：在线程池场景下线程复用，ThreadLocal使用完没有调用remove()时——key（ThreadLocal实例）会被GC回收（弱引用特点），但value的强引用链依然存在（Thread → ThreadLocalMap → Entry → value），导致value无法被回收，造成内存泄漏。

规范：ThreadLocal使用完必须在finally块中调用remove()。

1
2
3
4
5
6
7


ThreadLocal<Object> tl = new ThreadLocal<>();
try {
 tl.set(value);
 // 业务逻辑
} finally {
 tl.remove();
}

追问预判：

追问：“为什么ThreadLocalMap的key要设计成弱引用？”

设计为弱引用的目的是：当ThreadLocal对象不再被外部强引用时（即使用方不再需要它了），GC可以回收ThreadLocal实例，使得对应的Entry（key=null）成为无效条目。下次ThreadLocalMap调用set/get/remove时会主动清理这些key为null的Entry。如果没有这一层弱引用设计，即使外部不再使用ThreadLocal，Entry和value也会一直存活，导致更严重的内存泄漏。

陷阱提示：答不出弱引用设计意图；只知道"用ThreadLocal存用户信息"但说不清泄漏原理。

volatile深入

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.2 volatile深入

考察意图：volatile是面试高频基础题。初级答"保证可见性+禁止重排序"，中极答内存屏障语义，高级能讲出实际项目中用它解决过什么并发bug。

一、volatile的两个核心作用（基础层，必须熟练）

保证可见性：一个线程修改volatile变量后，其他线程立即可见。底层通过lock前缀指令触发缓存一致性协议（MESI），写变量时强制将缓存行写回主存并使其他CPU核的缓存行失效，其他核读时必须从主存重新加载。
禁止指令重排序：通过内存屏障限制编译器和CPU的指令重排。

不保证原子性：volatile int i; i++不是原子操作（读→改→写三步），多线程并发自增仍然会丢失更新。

二、内存屏障详解（深度层，拉开分差）

内存屏障是一条CPU指令，强制在其前后的内存操作满足特定的执行顺序。Java的volatile通过JMM定义的四类屏障保证了Happens-Before语义：

屏障类型	指令	作用
LoadLoad	`Load1; LoadLoad; Load2`	保证Load1在Load2之前完成（防止读操作重排到前面的读之前）
StoreStore	`Store1; StoreStore; Store2`	保证Store1在Store2之前完成（防止写操作重排到前面的写之前）
LoadStore	`Load1; LoadStore; Store2`	保证Load1在Store2之前完成（防止写操作重排到前面的读之前）
StoreLoad	`Store1; StoreLoad; Load2`	保证Store1在Load2之前完成（防止读操作重排到前面的写之前）最重的一类屏障，同时具备其他三种效果，通常由 `mfence`或 `lock addl`指令实现

volatile的内存屏障插入策略（JMM规范）：

1
2
3
4
5
6
7
8
9


// volatile 写之前
StoreStore屏障 ← 保证volatile写之前的普通写操作对volatile写可见
// volatile 写
StoreLoad屏障 ← 保证volatile写之后的读操作不会被重排到volatile写之前

// volatile 读
LoadLoad屏障 ← 保证volatile读之后的普通读不会被重排到volatile读之前
// volatile 读
LoadStore屏障 ← 保证volatile读之后的普通写不会被重排到volatile读之前

为什么StoreLoad屏障最重？ 它要求在执行StoreLoad之后的任何Load指令前，Store缓冲区中的所有数据必须全部刷新到主存（或者至少对其他处理器可见）。在x86平台上，StoreLoad通常由 mfence（全屏障）或带lock前缀的指令实现，开销是普通指令的几十到上百倍。而LoadLoad、StoreStore、LoadStore在x86上通常无需额外指令——x86本身就是强内存模型（TSO），只允许Store-Load重排，其他重排在硬件层面已被禁止。所以在x86上，volatile的实际开销主要来自StoreLoad屏障。

三、volatile实用场景（实战层，证明你真正用过）

场景1：DCL（双重检查锁定）单例中的volatile（经典面试题）：

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


public class DeviceConfigManager {
 private static volatile DeviceConfigManager instance;

 public static DeviceConfigManager getInstance() {
 if (instance == null) { // ①第一次判空
 synchronized (DeviceConfigManager.class) {
 if (instance == null) { // ②第二次判空
 instance = new DeviceConfigManager(); // ③危险操作
 }
 }
 }
 return instance;
 }
}

为什么 instance必须用volatile？ 关键在第③行 new DeviceConfigManager()，这行代码在JVM层面分三步：

1
2
3


1. memory = allocate() // 分配内存空间
2. ctorInstance(memory) // 初始化对象（执行构造方法）
3. instance = memory // 将引用指向分配的内存地址

如果不用volatile，步骤2和3可能被重排成1→3→2。线程A执行 new指令时刚好走到"分配内存→赋值引用"但构造方法还没执行完（对象是半成品），线程B走到第①行 if (instance == null)发现instance非空，直接返回了一个没有初始化完成的对象——后续使用时NullPointerException或数据错乱。volatile的StoreStore屏障保证了步骤2一定在步骤3之前完成（写前插入StoreStore：ctorInstance; StoreStore; instance=memory），线程B读instance时LoadLoad屏障保证读到的对象一定是初始化完毕的。

场景2：线程安全的状态标志位（实战项目）：

安全生产平台，定位计算引擎需要定期从配置文件刷新定位参数（基站坐标、校准因子）。这个开关被多个工作线程读取、被定时任务线程修改：

 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


public class PositionEngine {
 // 不用volatile——reload线程改了flag，worker线程可能永远看不到
 // private boolean configChanged = true;

 // 用volatile——reload线程一改，所有worker线程下次循环立即感知
 private volatile boolean configChanged = true;
 private PositionConfig config; // 注意：config本身不是volatile

 // 定时任务线程每5分钟刷新一次
 public void reloadConfig() {
 PositionConfig newConfig = loadFromRemote(); // ①先加载完整新配置
 this.config = newConfig; // ②再赋值给config
 this.configChanged = false; // ③最后改标记
 // volatile写前的StoreStore屏障保证①②③不会重排——
 // 所以configChanged变为false时，config一定是新值
 }

 // 几十个工作线程每秒调用数千次
 public Position calcPosition(Device device) {
 if (configChanged) {
 // volatile读后的LoadLoad屏障保证——
 // 读到configChanged=true时，config一定已经是最新赋值
 updateLocalConfig(this.config);
 configChanged = false;
 }
 // ... 定位计算，用本地缓存的config，不走volatile，零开销
 }
}

这个场景volatile的妙处：配置变量 config本身不需要volatile修饰。volatile只用于 configChanged这个"开关变量"，利用volatile写前StoreStore屏障保证"先赋值config、再改标记"的写入顺序，利用volatile读后LoadLoad屏障保证"先读标记确认、再读config内容"的读取顺序。这种"volatile变量守卫普通变量"的模式比把所有变量都标volatile高效得多。

场景3：安全发布（Safe Publication）：

在物联平台设备接入时，每个设备连接对应的Handler需要持有设备基础信息。这个信息在主线程初始化，被NIO的Worker线程读取：

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


public class DeviceHandler {
 private volatile DeviceInfo deviceInfo; // 必须volatile

 // 主线程启动时调用一次
 public void init(String deviceId) {
 DeviceInfo info = new DeviceInfo(deviceId); // ①构造完整对象
 info.setProtocol("modbus"); // ②设置所有属性
 info.setLocation("井下一区");
 this.deviceInfo = info; // ③发布——volatile写
 // StoreStore屏障：保证①②所有初始化在③赋值之前被所有线程可见
 }

 // Netty Worker线程读取
 public void onData(byte[] data) {
 DeviceInfo info = this.deviceInfo;
 if (info != null) {
 // LoadLoad屏障：读到的info对象一定是完整初始化的
 String protocol = info.getProtocol(); // 必然返回"modbus"，不会是null
 }
 }
}

如果没有volatile，Worker线程可能看到 deviceInfo非空（引用已赋值），但 info对象的内部属性还是初始值（构造函数未完整执行被重排），导致 getProtocol()返回null而NPE。

陷阱提示：说"volatile能保证原子性"——致命错误（i++反例）；说"所有共享变量都需要volatile"——过于暴力，性能代价大；知道四种屏障名字但说不出各自阻止什么重排；不知道DCL单例为什么必须volatile（JDK 5之前volatile语义不够强，DCL有bug）；不知道x86只需要StoreLoad屏障（LoadLoad/StoreStore/StoreLoad在x86上硬件已保证，伪共享除外）。

各JDK版本垃圾回收器

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.3 各JDK版本垃圾回收器

考察意图：了解不同回收器的设计目标、适用场景和演进历史，能根据业务场景推荐合适的回收器。

回答样板：

JDK发展史就是"降低GC停顿时间"的演进史——从秒级到毫秒级到亚毫秒级：

回收器	作用区域	算法	停顿特点	适用场景	JDK版本
Serial	新生代	标记-复制	单线程STW，几十~几百ms	单核、Client模式、几百MB堆	1.3+
Serial Old	老年代	标记-整理	单线程STW	配合Serial	1.3+
Parallel Scavenge	新生代	标记-复制	多线程STW，吞吐量优先	批处理、科学计算	1.4+
Parallel Old	老年代	标记-整理	多线程STW	配合Parallel Scavenge	1.6+
CMS	老年代	标记-清除	并发低停顿，最耗时的并发标记和并发清除阶段与用户线程并发	互联网Web应用（响应时间优先）	1.5-14
G1	整堆	标记-整理+复制	可预测停顿，Region化	JDK 9默认、大堆(>4G)、对停顿有要求的服务端	7u4+
ZGC	整堆	染色指针+并发整理	亚毫秒级停顿(<1ms)	超大堆(>16G)、极致低延迟	11+(实验) / 15+(生产)
Shenandoah	整堆	并发复制+Brooks转发指针	低停顿	超大堆低延迟	12+(Red Hat主导)

CMS（Concurrent Mark Sweep）——并发低停顿的先驱：

四个阶段：①初始标记（STW，扫描GC Roots直接引用，极快）→ ②并发标记（与用户线程并发，从GC Roots遍历整个对象图，最耗时）→ ③重新标记（STW，处理并发标记期间变动的引用，修正标记结果）→ ④并发清除（与用户线程并发）。

CMS的致命缺陷：

内存碎片——标记-清除不整理，碎片严重时触发Serial Old全堆整理（单线程，停顿秒级）
浮动垃圾——并发标记和清除期间用户线程产生的垃圾，只能等下次GC处理。需预留老年代空间给这些浮动垃圾，否则触发Concurrent Mode Failure，降级为Serial Old
JDK 14已废弃，JDK 15移除

G1（Garbage First）——JDK 9+默认，划时代的分区回收器：

核心创新——将堆划分为等大小的Region（默认2048个，每个1~32MB），不再按物理分代。Region分为Eden、Survivor、Old、Humongous四种类型。

G1的混合GC（Mixed GC）：不止回收新生代，还回收部分收益最高的老年代Region——每次回收"垃圾最多的Region"，这也是Garbage First名字的来源。

关键机制：

SATB（Snapshot At The Beginning）：并发标记开始时的对象图快照，保证标记正确性
RSet（Remembered Set）：每个Region维护其他Region指向本Region的引用，避免全堆扫描
可预测停顿：-XX:MaxGCPauseMillis设定目标（默认200ms），G1自动调整回收Region数量
Humongous对象：超过Region大小50%的对象放入Humongous Region。大量短命大对象会引发频繁GC——需要调整Region大小或优化应用代码

G1 vs CMS直观对比：

G1无内存碎片（标记-复制+整理），CMS有碎片问题
G1停顿可预测可控，CMS的不确定性大
G1的吞吐量略低于CMS（RSet维护开销），但换来更稳定的延迟

ZGC（Z Garbage Collector）——亚毫秒级停顿的终极方案：

核心创新——染色指针（Colored Pointer）：在64位指针中嵌入GC状态信息（共4位：Finalizable/Remapped/Marked 1/Marked 0），标记阶段不修改对象头，只修改指针颜色。结合读屏障（Load Barrier）实现并发整理——应用线程读对象时发现指针颜色不对，触发地址修正，在访问过程中完成GC。

关键特性：

停顿时间不随堆大小增长——16MB堆<1ms，16TB堆也是<1ms
支持TB级堆、毫秒级回收、JDK 15生产可用
限制：仅Linux x64；吞吐量比G1低约5-10%（读屏障开销）

JDK版本与默认回收器对照速查：

JDK版本	默认回收器
JDK 8	Parallel Scavenge + Parallel Old（吞吐量优先）
JDK 9-16	G1
JDK 17+	G1（LTS）
JDK 21	G1（新一代ZGC也在成熟，但G1仍是默认）

面试官可能会问"你们项目用的什么回收器，为什么？"：

项目部署在JDK 8上，默认Parallel Scavenge+Parallel Old。但我们实际指定了G1——原因：①堆内存配了4-8G，G1对这个区间的优化最好；②安全生产平台是面向客户的服务端应用，客户对接口响应时间敏感，G1的可预测停顿比Parallel的吞吐量优先更适合；③大量设备数据写入导致新生代对象产生速度快，Parallel的STW时间随堆增长接近1秒，G1的停顿控制在200ms以内。上了G1后加上 -XX:MaxGCPauseMillis=100调优，P99延迟从800ms降到了300ms。

陷阱提示：把G1说成简单的"分Region的CMS"；不知道CMS在JDK 14已废弃；不知道JDK 8默认是Parallel而非G1；说不出ZGC的核心创新（染色指针）；GC选型说不出业务场景理由。

垃圾回收算法

Tue, 06 Mar 2018 00:00:00 +0000

§2.1.2 垃圾回收算法

考察意图：理解各算法的原理、优缺点和适用分代，能结合业务场景说明选型理由。

回答样板：

四种基础算法，JVM根据分代特性组合使用：

1. 标记-清除（Mark-Sweep）——最基础

流程：标记阶段遍历GC Roots标记存活对象 → 清除阶段回收未标记对象
优点：算法简单，不移动对象
缺点：内存碎片化——清除后产生大量不连续的空闲内存。碎片严重时，即使总空闲内存足够，也可能无法分配大对象，触发Full GC
适用：老年代的基础算法（CMS的标记-清除阶段）

2. 标记-复制（Mark-Copy）——新生代首选

流程：将存活对象复制到另一块空白区域 → 原区域整块清空
优点：无内存碎片，整块清空效率极高，只需移动存活对象
缺点：浪费50%空间（需要一块空白区域做副本）。不过新生代对象98%朝生夕死，实际只需要很小的Survivor空间
适用：新生代Minor GC。8:1:1的Eden:Survivor比例就是基于这个假设——Survivor只需要留新生代10%的空间。如果Survivor不够放存活对象，通过分配担保机制直接晋升老年代

3. 标记-整理（Mark-Compact）——老年代兜底

流程：标记存活对象 → 将所有存活对象移到内存一端 → 清理边界外的内存
优点：无内存碎片，不需要浪费额外空间
缺点：移动对象需要STW，且需要更新所有指向被移动对象的引用——停顿时间与堆中存活对象数量成正比
适用：老年代（Serial Old、Parallel Old）

4. 分代收集（Generational Collection）——JVM的顶层策略

不是独立算法，而是"不同分代用不同算法"的策略组合
核心假设：弱分代假说——绝大多数对象朝生夕死（新生代用复制算法）；强分代假说——熬过多次GC的对象一般不会轻易死亡（老年代用标记-清除/标记-整理）
几乎所有JVM垃圾回收器都基于分代假设设计

记忆集（Remembered Set）与卡表（Card Table）：

分代收集的致命问题：跨代引用。新生代对象被老年代引用时，Minor GC只扫新生代，无法通过GC Roots找到这个老年代引用，导致存活新生代对象被误清。解决方案：老年代维护一张卡表——将老年代内存按512字节分块（Card），有老年代引用指向新生代时，对应Card标记为"脏"。Minor GC扫描时除了GC Roots还扫描卡表中的脏Card，避免全堆扫描。CMS和G1都在写屏障（Write Barrier）中维护这张卡表，性能开销约5%-10%。

陷阱提示：四种算法的优缺点和应用分代背串；不知道跨代引用问题和卡表机制；以为复制算法就是新生代的全部。

线程池核心参数与执行流程

Tue, 06 Mar 2018 00:00:00 +0000

§2.2.4 线程池核心参数与执行流程

考察意图：能否根据业务场景做线程池选型与调参，理解拒绝策略的差异。

回答样板：

七个核心参数：

corePoolSize——常驻线程数
maximumPoolSize——最大线程数
keepAliveTime——空闲线程存活时间（超过corePoolSize的线程）
TimeUnit——时间单位
workQueue——阻塞队列（有界/无界）
threadFactory——线程工厂（自定义线程名、是否守护线程等）
handler——拒绝策略

执行流程：提交任务 → 当前线程数 < corePoolSize → 创建核心线程执行 → 当前线程数 >= corePoolSize → 入队列等待 → 队列满 → 创建非核心线程执行 → 当前线程数 >= maximumPoolSize → 触发拒绝策略

四种拒绝策略：

策略	行为	适用场景
AbortPolicy（默认）	抛RejectedExecutionException	必须感知任务丢失的场景
CallerRunsPolicy	调用者线程执行	反向压制动，降低任务提交速度
DiscardPolicy	直接丢弃，静默失败	不重要的日志/统计任务
DiscardOldestPolicy	丢弃队列最老的未处理任务	优先处理新任务的场景

项目实战：在物联平台用线程池处理设备数据批量写入。I/O密集型任务核心线程数设为CPU核数×2，队列用有界ArrayBlockingQueue防止内存溢出。自定义ThreadFactory设置线程名前缀方便排查。拒绝策略用CallerRunsPolicy做背压。

陷阱提示：背参数但说不清业务场景下怎么选型和调参。

ArrayList vs LinkedList

Thu, 06 Mar 2008 00:00:00 +0000

§2.3.3 ArrayList vs LinkedList

考察意图：是否理解List不同实现的性能差异及工程选型判断。

回答样板：

维度	ArrayList	LinkedList
底层结构	动态数组（Object[]）	双向链表（Node）
随机访问	O(1)	O(n)——需要遍历
尾部插入	O(1)均摊（扩容时O(n)）	O(1)
头/中间插入	O(n)（需要移动元素）	头O(1)，中间O(n)——定位+O(1)插入
内存开销	连续内存，数据紧凑	每个节点额外存储prev+next指针

工程实践：实际开发中ArrayList用得更多。原因是内存连续、CPU缓存友好（缓存行预读），大多数场景下遍历性能远超LinkedList。LinkedList的优势场景是频繁头尾插入删除（如队列、栈）。日常开发90%场景ArrayList够用。

ArrayList扩容：默认初始容量10，扩容时增长为原来的1.5倍（oldCapacity + (oldCapacity >> 1)），通过Arrays.copyOf拷贝数组。

陷阱提示：不知道ArrayList扩容机制细节；说"LinkedList插入快"不考虑定位开销。

HashMap原理

Tue, 06 Jun 2006 00:00:00 +0000

§2.3.1 HashMap原理

考察意图：是否理解HashMap的数据结构演进、put流程、扩容与树化等关键机制。

回答样板：

底层结构：JDK 7：数组+链表。JDK 8：数组+链表/红黑树。

put流程：

计算key的hash值（高16位异或低16位，降低hash冲突）
定位桶：(n - 1) & hash
无冲突 → 直接放入
有冲突 → 判断equals → 相同则覆盖，不同则尾插（JDK 7是头插，JDK 8改尾插避免死链）
链表长度 > 8 且数组长度 ≥ 64 → 树化为红黑树
容量超过 threshold（capacity × loadFactor）→ 扩容

扩容机制：2倍扩容，JDK 8做了rehash优化——原hash值与oldCap按位与，结果为0留在原位，为1移到"原位置+oldCap"，省去了每次rebuild hash表的开销。

负载因子0.75：时间和空间的折中。太低（如0.5）浪费内存；太高（如1）hash冲突增加，影响查询性能。

红黑树退化：resize时如果树的节点数 ≤ 6，退化为链表。

陷阱提示：说"HashMap线程安全"；不知道树化阈值是链表长度>8且数组长度≥64两个条件缺一不可。

ConcurrentHashMap原理

Thu, 06 Apr 2006 00:00:00 +0000

§2.3.2 ConcurrentHashMap原理

考察意图：是否理解ConcurrentHashMap在JDK 7/8的演进及JDK 8的改进要点。

回答样板：

JDK 7（分段锁）：

数据结构：Segment数组 + HashEntry数组 + 链表
Segment继承ReentrantLock，默认16个Segment
理论上支持16个线程并发写（每个Segment一把锁）
并发度固定不可动态调整

JDK 8（CAS + synchronized）：

数据结构：Node数组 + 链表/红黑树
put时CAS尝试插入空桶，CAS失败则synchronized锁桶头节点再插入
锁粒度从Segment级别（一锁锁一段）细化到桶级别（一锁锁一个桶），并发度更高
扩容支持多线程并发——transferIndex分段迁移，每个线程负责一段区域的rehash
JDK 8改synchronized而非ReentrantLock的原因：JDK 6后synchronized性能足够；省去Segment对象的内存开销；锁粒度更细带来的收益远超锁机制本身的微小差异

陷阱提示：仍停留在JDK 7分段锁的理解；不知道JDK 8为什么改CAS+synchronized。