Jdk on Liangweidong's blog

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线程）。

各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选型说不出业务场景理由。