JDK 13 是 2019 年 9 月发布的版本放在 Java 整个演进史里算不上主角——它不是 LTS生命周期只有半年左右很多人甚至直接跳过了它。但如果你把视野稍微拉长一点会发现 JDK 13 其实是 Java 语法变革里非常关键的一站文本块第一次以官方特性形式出现switch 表达式的最终形态也是在这一版里定型的。换句话说你可以没在生产环境用过 JDK 13但只要你弄懂了 JDK 13再回头去看 17、21 里那些现代写法会特别有亲切感。这篇文章我就按实际使用的角度把 JDK 13 的几个核心新特性逐个拆开讲一遍。内容包括五个 JEP 分别解决了什么问题、具体怎么用、有哪些隐藏的坑以及我实际验证过程中踩过的典型问题。适合正在做版本升级评估的人也适合那些想系统梳理 Java 语法演进、准备技术面试的开发者。先说明一点JDK 13 不是 LTS我个人的态度是生产环境没必要追但它的语言特性值得认真看。1. 先盘一盘JDK13的发布背景与整体定位1.1 版本演进中的位置与节奏Java 从 9 开始改成半年一个版本的节奏之后就是 9、10、11、12、13 这么一路往下走LTS 版本大约隔三年出一个8 是 2014 年11 是 2018 年17 是 2021 年21 是 2023 年。JDK 13 正好落在 11 和 17 中间属于典型的非 LTS 中间版本。中间版本的意义不在于让大家立刻升级而在于把一些新特性提前放到开发者面前试用。JDK 13 里的文本块和 switch 表达式在发布时都是 Preview 状态需要手动打开开关才能用。这种机制带来的好处是语法可以先收集反馈再在后续版本里定型。比如文本块在 13 第一次出现到 15 才转正switch 表达式在 12 就开始预览14 才正式落地。如果你直接看 17 或 21 的语法看到的都是结果而看 13你能看到这些语法最初的设计意图。1.2 JDK13的五个JEP构成JDK 13 的正式特性可以浓缩成一张表JEP 编号特性名称类型状态JEP 350动态 CDS 存档性能/平台正式JEP 351ZGC 取消未使用内存性能/GC正式JEP 353重新实现传统 Socket API平台/网络正式JEP 354Switch 表达式语言语法预览JEP 355文本块语言语法预览这五个特性里真正每天写代码会碰到的就是后两个。CDS、ZGC、Socket 重构更多是平台层面的增强普通业务开发大概率感知不到但它们在特定场景下的价值很大。比如容器化部署越来越普及之后启动速度和内存占用直接关系到成本和扩容效率动态 CDS 和 ZGC 的内存回收都是往这个方向使劲的。学习顺序上我建议先把文本块和 switch 表达式彻底搞明白再研究 CDS 和 ZGC 的适用场景最后了解一下 Socket 重构的存在意义。这样既照顾了日常开发需求又不会漏掉平台能力层面的重点。2. 文本块多行字符串的体验升级2.1 老写法到底痛点在哪在文本块出现之前Java 里写多行字符串是一件非常折磨人的事。比如一段 JSONString json {\n \name\: \example\,\n \version\: \1.0\\n };代码里全是\n加号拼接和反斜杠转义数据内容被字符串语法搅得面目全非。更麻烦的是 SQL、HTML 这类对格式有要求的文本一旦要改其中一个字段你得在转义和拼接里反复横跳稍不留神就多一个或少一个引号。我见过不少线上问题就是这种拼接字符串时漏了空格或者换行导致的。文本块要解决的就是这个核心痛点让代码里的字符串字面量能直接以所见即所得的方式书写不需要为了语言语法而牺牲可读性。2.2 基本语法与缩进规则JDK 13 里文本块的写法是用三个双引号作为定界符直接换行书写内容String json { name: example, version: 1.0 } ;注意几个硬性规则起始的三个双引号后面必须紧跟换行不能在同一行写内容。文本内容里可以直接写双引号不需要转义所以上面 JSON 里的name能原样出现。结束的三个双引号可以单独占一行也可以放在最后一行的结尾。文本块的缩进规则是新手最容易搞混的地方。编译器会统计所有非空行的公共最小缩进然后统一去掉这个缩进量。举个例子String sql SELECT * FROM users WHERE name John ;上面这段每行内容前都有 4 个空格结束分隔符前面也有 4 个空格编译器会把这 4 个空格作为公共缩进去掉。所以最终输出是SELECT * FROM users WHERE name John这里有个小细节结束分隔符的位置会影响缩进计算。如果你把结束分隔符放在最左侧不缩进String sql SELECT * FROM users ;那公共缩进量就不是 4 个空格了因为结束分隔符这一行的前导空白是 0编译器按它来计算内容行的缩进就会原样保留。实操中我建议统一把结束分隔符和内容行对齐这样行为最可预期。2.3 配套的String新方法配合文本块JDK 13 里也给 String 增加了一些方法其中日常最常用的是formatted。它本质上就是String.format的实例方法版本String template Hello, %s! Your score is %d. ; String message template.formatted(小明, 99);以前的写法是String.format(template, ...)现在可以直接在模板字符串后面调formatted读起来顺很多。另外还有stripIndent()和translateEscapes()两个方法分别用来去掉公共缩进和把转义序列翻译成实际字符。不过在 JDK 13 里文本块是预览特性这几个方法的使用场景基本都围绕文本块展开等文本块在后续版本转正后它们也跟着成了正式 API。有一点需要提醒JDK 13 的文本块只支持原有的转义序列比如\n、\t。后来版本里新增的\s空格和行尾\续行在 13 里还没有不要拿着新习惯往老版本代码里套。2.4 实际使用中的注意事项文本块最适合写 JSON、SQL、HTML、XML 这类自带格式的文本。我自己在项目里最常用它写 SQL 模板和测试数据确实清爽很多。但有几个坑必须注意第一文本块末尾会保留一个换行符。因为开始分隔符之后的内容是一个完整行结束分隔符前面的最后一个换行会被保留。如果你不想要末尾换行可以像前面例子那样把结束分隔符放在最后一行内容的后面;。第二IDE 的自动格式化可能破坏缩进计算。文本块里每行的前导空格是在字符串语义里的IDE 如果按代码缩进重新对齐输出内容就会变。后来版本里编译器的规则更精细但 13 上还是得自己多留个心眼。第三文本块是预览特性编译和运行都必须加开关javac --release 13 --enable-preview App.java java --enable-preview App如果只编译不加运行开关运行阶段会直接报错反过来如果编译时没开预览源码直接编译不过。这个开关问题我用过几次之后已经形成肌肉记忆了先加--enable-preview再跑。3. Switch表达式从语句到表达式的关键一步3.1 老Switch的三大问题老版 switch 语句是被吐槽最多的地方之一。第一个问题是容易漏写break导致意外贯穿。Java 的 switch 默认是 fall-through 行为一旦某个 case 匹配后没有break后续所有 case 都会执行。这个设计跟大多数现代语言相反也是很多 bug 的来源。第二个问题是每个 case 共享作用域。在 switch 里声明变量如果多个 case 分支都想用同一个变量名就得额外加大括号否则编译不过代码非常啰嗦switch (mode) { case a: int x 1; break; case b: int x 2; // 编译错误 break; }第三个问题是 switch 只能“执行”不能“返回”。实际开发里我们经常是根据某个值做映射得到一个结果老写法只能在外面声明一个变量在分支里赋值绕一圈才能拿到最终值。3.2 箭头语法与yieldJDK 12 给 switch 引入了箭头-语法JDK 13 在此基础上加了yield关键字让 switch 能以“表达式”的身份直接产生值。先看一个最简单的版本String label switch (day) { case MONDAY, FRIDAY - 工作日; case SATURDAY, SUNDAY - 休息日; default - 中间; };箭头后面接的是一个表达式或语句块不需要break也不会贯穿多个 case 值可以直接用逗号并列。如果分支需要做多步计算可以用花括号加yield返回结果int result switch (mode) { case a - 1; case b - { int temp compute(); yield temp * 2; } default - 0; };这里的yield和return不一样return是结束整个方法yield只是给 switch 表达式产生一个值。JDK 12 的预览版本里块级分支用的是break value这种写法到了 JDK 13 改成了yield语义更清晰。所以如果你在网上看到用break 返回值的代码那是 12 预览版的写法在 13 上已经不好使了。3.3 语句与表达式的对比维度传统 switch 语句switch 表达式JDK13返回值不能直接返回表达式整体可以赋值贯穿默认贯穿容易漏 break箭头语法天然不贯穿分支格式只能 case 冒号支持箭头和 yield穷尽性不强制必须覆盖所有情况或提供 default作用域分支间共享箭头分支各自独立穷尽性这一点特别值得注意。switch 表达式要求所有可能的值都有对应分支否则编译器直接报错。比如枚举类型如果枚举新增了一个常量而 switch 表达式没有处理它就编译不过。从好的方面想这是编译器在帮你做完整性检查从坏的方面想如果枚举经常变化每次都要记得补分支。我的习惯是对枚举做 switch 表达式时永远保留一个default避免一改枚举就编译失败。3.4 实战场景与搭配技巧我实际用得最多的是状态映射和策略选择。比如把一个状态码转成可读描述或者根据类型取不同的处理策略boolean canProcess switch (state) { case PENDING, PROCESSING - true; case DONE, FAILED - false; default - throw new IllegalArgumentException(未知状态: state); };另一个实用技巧是箭头分支右边接的是表达式所以可以直接调用返回同类型的方法。比如String result switch (type) { case admin - buildAdminLabel(); case user - buildUserLabel(); default - unknown; };代码比原来的 if-else 链干净很多。JDK 14 之后 switch 表达式转正就不需要预览开关了。如果你现在写的是 17 或 21语法基本一致只是不用再加--enable-preview。4. 动态CDS存档与ZGC内存增强4.1 CDS到底在做什么CDSClass Data Sharing类数据共享是一种启动优化技术。它的原理很简单JVM 启动时需要加载大量类把类元数据放到堆里这个过程既耗 CPU 也占内存。CDS 允许把类元数据预先处理成一个共享存档文件下次启动时直接映射这个存档省去类加载的解析和初始化工作。在 JDK 13 之前使用 CDS 需要手动生成类列表过程大概是用一个诊断参数运行应用把加载过的类记录到文本文件再用另一个参数配合类列表生成 CDS 存档最后启动时指定存档文件。这套操作对普通开发来说太繁琐所以大部分人根本不会碰。JEP 350 的目标就是把这个过程自动化应用退出时自动生成存档不需要你手工维护类列表。实际操作很简单。第一次运行java -XX:ArchiveClassesAtExitapp.jsa -cp app.jar com.example.Main应用正常退出后当前目录就生成了app.jsa。第二次启动时指定存档java -XX:SharedArchiveFileapp.jsa -cp app.jar com.example.Main如果不想分两次操作JDK 13 还提供了一个-XX:AutoCreateSharedArchive参数启动时指定存档路径JVM 发现存档不存在就自动生成下次启动自动使用java -XX:SharedArchiveFileapp.jsa -XX:AutoCreateSharedArchive -cp app.jar com.example.Main实测下来对小应用启动时间可能只有几百毫秒的差异但类数量大的应用收益明显。不过 CDS 存档有很强的环境绑定JDK 版本变了、类路径变了、甚至平台不同存档都可能失效。JVM 检测到不匹配时会忽略存档或者报警告应用本身不会挂但优化效果就没了。在容器环境里我建议在构建镜像的时候就生成好存档而不是让每个容器启动时现场生成。4.2 ZGC现在可以把内存还给系统ZGC 是 JDK 11 引入的一款低延迟垃圾回收器设计目标是把 GC 停顿时间控制在毫秒级面向大堆内存场景。不过最初版本的 ZGC 有个毛病已经向操作系统申请的内存在堆空闲之后不会归还。长时间运行的 JVM 哪怕实际使用率很低也会一直占着内存不放手。这在传统物理机部署时代问题不大但在容器和按内存计费的云环境里就是实打实的浪费。JEP 351 给 ZGC 加上了取消未使用内存的能力。核心参数是-XX:ZUncommitDelay单位秒默认 300 秒。意思是当堆内存出现空闲并且这种空闲持续超过 300 秒JVM 才会真正把内存还给操作系统。试想一下应用早上迎来一波高峰期内存申请到 8GB中午低谷期实际只用 2GB没有这个特性的话 8GB 一直被占用有了它空闲部分会在延迟时间后被释放。用法示例java -XX:UnlockExperimentalVMOptions -XX:UseZGC -XX:ZUncommitDelay120 -jar app.jar有一点需要明白延迟时间不是越小越好。如果应用的内存使用有周期性波动比如每分钟都有一次小高峰你把延迟设成 60 秒内存还回去之后马上又要重新申请频繁的归还和重新提交反而会带来额外开销。我个人的建议是容器内存受限或按内存计费的场景可以适当调低到 120 秒左右普通场景保持默认就很好。另外ZGC 在 JDK 13 里仍然是实验性特性需要配合-XX:UnlockExperimentalVMOptions -XX:UseZGC开启。后续版本逐渐成熟到低延迟场景里已经是很稳的选择但这些参数在 13 上是必须加的。4.3 Socket API底层重构JEP 353 重构了java.net.Socket和java.net.ServerSocket的底层实现。老实现是很多年前用本地 C 代码写的从 Java 1.0 时代一路留到现在维护成本高而且跟现代并发模型配合得不好。新实现基于 NIO 通道用纯 Java 代码完成结构清晰易维护也更适应高并发场景。对业务开发来说这个重构几乎是透明的Socket、ServerSocket的公共 API 完全没变你不需要修改调用代码。但底层变了总会有一些微妙差异需要留意。如果你的项目里有比较底层的网络通信模块升级到 JDK 13 之后建议做一轮压测特别是长连接多、并发量高的场景。万一压测发现异常可以用一个系统属性切回老实现排查java -Djdk.net.usePlainSocketImpltrue -jar app.jar这个开关很有用定位问题时先确认是不是新实现导致的行为变化。如果切回老实现后问题消失基本可以确定是新 Socket 实现的兼容性问题如果两边行为一致那就跟这次重构无关应该从代码层面找原因。5. 容易被忽略的几个更新5.1 Unicode 12.1支持JDK 13 同步升级了对 Unicode 12.1 的支持。对于绝大多数业务开发来说这个更新是无感的因为常规的字符处理不会立刻受影响。但如果你做的是国际化、字符分析、文本处理这类工作升级后某些字符的判断结果和编码转换行为可能发生变化。比如新增的字符、脚本或表情符号在旧版本里可能被当作普通符号处理新版本里会有更细的分类。范围比较窄但属于那种不查文档就容易踩坑的隐性变更。5.2 预览特性的开启与关闭JDK 13 里文本块和 switch 表达式都是预览特性这意味着即使你的源码用了 13 的新语法编译和运行也得同时加--enable-preview。这里有个非常容易踩的坑很多人在 IDE 里编译通过了但命令行运行时报UnsupportedClassVersionError或者preview features are not enabled就是因为编译时开了预览、运行时没开或者反过来。推荐的命令行组合是这样的javac --release 13 --enable-preview -d out src/com/example/App.java java --enable-preview -cp out com.example.App注意编译时最好加上--release 13否则编译器可能按当前默认版本处理导致二进制版本号不对。如果用的是 IDE也需要在编译选项里把语言级别设置成 13并且勾选预览选项。不同 IDE 的配置路径不一样但核心就是这两个开关要同时打开。5.3 非LTS版本的升级决策JDK 13 的生命周期很短过期之后官方不再提供免费更新。所以我不建议任何生产环境长期停留在 13。如果你所在的项目已经在用 11想升级到 17 或更后面的版本完全可以跳过 13如果你想体验文本块和 switch 表达式的新语法直接用 17 或 21 更好因为这些特性已经转正不用再忍受预览开关的各种麻烦。那学 JDK 13 还有什么意义我的理解是它是一份很好的“语法演进史教材”。看 17 的文本块你不会知道为什么缩进规则长这样看了 13 最初的实现你就知道哪些设计是后来根据反馈改的。对技术面试来说能把“这个特性在预览阶段长什么样、后来为什么改”讲清楚比单纯背特性列表要加分得多。6. 实际踩坑记录与排查速查表6.1 文本块缩进被“吃掉”的现场我之前写一个日志模板代码是这样的String log request received begin handle ;看起来一切正常但输出的时候发现每行前面的空格比预期少了很多。排查下来发现是我编辑器自动缩进把结束分隔符顶到了行首导致公共缩进量计算变成了 0内容行原有的缩进被原样保留于是模板的层级结构全乱了。这个问题在文本块转正后依然存在因为缩进计算的核心逻辑没变。我的解决办法是拿到输出后先打印一遍确认肉眼可见的内容正确再进代码不要凭编辑器里的显示判断最终效果。6.2 Switch表达式漏分支的编译错误有一次我在代码里用 switch 表达式处理一个枚举当时只写了几个具体分支和default后来枚举加了一个新值项目编译直接失败。错误信息指向 switch 表达式分支不完整。如果你是刚接触这个概念可能会觉得莫名其妙我用default兜底了怎么还报错原因在于当 switch 作为表达式时编译器要求所有输入值都有对应分支这是一种穷尽性检查。如果分支包含了default编译器认为默认情况已经覆盖所以不会报错但如果你想着靠枚举当前的值数量来保证穷尽一旦枚举扩展就会编译失败。我的建议很简单对枚举做 switch 表达式时要么显式写出所有值要么永远挂一个default否则就是给自己埋雷。6.3 CDS存档失效的排查动态 CDS 用起来很顺手但它有一个隐蔽的问题如果应用的 jar 包更新了而存档文件还是旧的JVM 可能不会报错而是直接悄悄忽略存档。你以为还在享受启动优化实际上已经退化成了普通启动。排查方法是加参数看日志java -Xlog:cds -XX:SharedArchiveFileapp.jsa -cp app.jar com.example.Main日志里会输出 CDS 存档是否成功映射。如果显示类似存档不匹配的信息就说明需要重新生成。在持续集成环境里我习惯把存档生成放进构建脚本确保每次发布都会基于最新的 jar 重新生成 CDS 存档避免手工维护导致过期。6.4 ZGC内存不释放的确认方法有朋友问过我为什么我开了 ZGC 的内存回收内存还是一直居高不下这里需要明确一点ZGC 归还内存是有条件的既要堆内存空闲比例达到一定要求也要空闲时间超过ZUncommitDelay的阈值。应用如果一直有合理的内存使用量那内存当然不会还回来。确认是否生效可以用 GC 日志java -Xlog:gc* -Xlog:gcheapdebug -XX:UnlockExperimentalVMOptions -XX:UseZGC -jar app.jar日志里会显示堆容量调整和内存提交的记录。如果完全没有任何归还迹象再把-XX:ZUncommitDelay调小一点试试。注意别调到 30 秒这种极端值要根据应用的实际内存曲线来定。6.5 常见问题速查表问题可能原因解决办法文本块编译失败没有加--enable-preview编译和运行都加开关运行时提示预览特性未启用只有编译加了开关运行也加java --enable-preview文本块输出缩进不对结束分隔符位置影响缩进计算结束分隔符与内容行对齐switch 表达式编译报分支不全枚举新增值或没有 default补全分支或加 defaultCDS 启动优化没生效存档过期或不匹配重建存档并查看-Xlog:cdsZGC 内存不归还未满足空闲时间/比例条件调整-XX:ZUncommitDelay并查日志我在 JDK 13 上验证这些特性时最深的体会是中间版本的预览特性确实能让人提前看到 Java 的未来但代价是要花不少时间去跟编译开关和缩进规则较劲。好在这些积累不会白费等你在新版本里再用同样的语法时基本就是零成本切换。如果你手里有闲余环境装一个 13 跑一跑这些例子感受一下语法演进的过程比单纯看资料要直观得多。如果是为了生产升级我建议还是直接看 17 或 21那些才是当前真正值得长期停留的版本。
JDK 13 是 2019 年 9 月发布的版本放在 Java 整个演进史里算不上主角——它不是 LTS生命周期只有半年左右很多人甚至直接跳过了它。但如果你把视野稍微拉长一点会发现 JDK 13 其实是 Java 语法变革里非常关键的一站文本块第一次以官方特性形式出现switch 表达式的最终形态也是在这一版里定型的。换句话说你可以没在生产环境用过 JDK 13但只要你弄懂了 JDK 13再回头去看 17、21 里那些现代写法会特别有亲切感。这篇文章我就按实际使用的角度把 JDK 13 的几个核心新特性逐个拆开讲一遍。内容包括五个 JEP 分别解决了什么问题、具体怎么用、有哪些隐藏的坑以及我实际验证过程中踩过的典型问题。适合正在做版本升级评估的人也适合那些想系统梳理 Java 语法演进、准备技术面试的开发者。先说明一点JDK 13 不是 LTS我个人的态度是生产环境没必要追但它的语言特性值得认真看。1. 先盘一盘JDK13的发布背景与整体定位1.1 版本演进中的位置与节奏Java 从 9 开始改成半年一个版本的节奏之后就是 9、10、11、12、13 这么一路往下走LTS 版本大约隔三年出一个8 是 2014 年11 是 2018 年17 是 2021 年21 是 2023 年。JDK 13 正好落在 11 和 17 中间属于典型的非 LTS 中间版本。中间版本的意义不在于让大家立刻升级而在于把一些新特性提前放到开发者面前试用。JDK 13 里的文本块和 switch 表达式在发布时都是 Preview 状态需要手动打开开关才能用。这种机制带来的好处是语法可以先收集反馈再在后续版本里定型。比如文本块在 13 第一次出现到 15 才转正switch 表达式在 12 就开始预览14 才正式落地。如果你直接看 17 或 21 的语法看到的都是结果而看 13你能看到这些语法最初的设计意图。1.2 JDK13的五个JEP构成JDK 13 的正式特性可以浓缩成一张表JEP 编号特性名称类型状态JEP 350动态 CDS 存档性能/平台正式JEP 351ZGC 取消未使用内存性能/GC正式JEP 353重新实现传统 Socket API平台/网络正式JEP 354Switch 表达式语言语法预览JEP 355文本块语言语法预览这五个特性里真正每天写代码会碰到的就是后两个。CDS、ZGC、Socket 重构更多是平台层面的增强普通业务开发大概率感知不到但它们在特定场景下的价值很大。比如容器化部署越来越普及之后启动速度和内存占用直接关系到成本和扩容效率动态 CDS 和 ZGC 的内存回收都是往这个方向使劲的。学习顺序上我建议先把文本块和 switch 表达式彻底搞明白再研究 CDS 和 ZGC 的适用场景最后了解一下 Socket 重构的存在意义。这样既照顾了日常开发需求又不会漏掉平台能力层面的重点。2. 文本块多行字符串的体验升级2.1 老写法到底痛点在哪在文本块出现之前Java 里写多行字符串是一件非常折磨人的事。比如一段 JSONString json {\n \name\: \example\,\n \version\: \1.0\\n };代码里全是\n加号拼接和反斜杠转义数据内容被字符串语法搅得面目全非。更麻烦的是 SQL、HTML 这类对格式有要求的文本一旦要改其中一个字段你得在转义和拼接里反复横跳稍不留神就多一个或少一个引号。我见过不少线上问题就是这种拼接字符串时漏了空格或者换行导致的。文本块要解决的就是这个核心痛点让代码里的字符串字面量能直接以所见即所得的方式书写不需要为了语言语法而牺牲可读性。2.2 基本语法与缩进规则JDK 13 里文本块的写法是用三个双引号作为定界符直接换行书写内容String json { name: example, version: 1.0 } ;注意几个硬性规则起始的三个双引号后面必须紧跟换行不能在同一行写内容。文本内容里可以直接写双引号不需要转义所以上面 JSON 里的name能原样出现。结束的三个双引号可以单独占一行也可以放在最后一行的结尾。文本块的缩进规则是新手最容易搞混的地方。编译器会统计所有非空行的公共最小缩进然后统一去掉这个缩进量。举个例子String sql SELECT * FROM users WHERE name John ;上面这段每行内容前都有 4 个空格结束分隔符前面也有 4 个空格编译器会把这 4 个空格作为公共缩进去掉。所以最终输出是SELECT * FROM users WHERE name John这里有个小细节结束分隔符的位置会影响缩进计算。如果你把结束分隔符放在最左侧不缩进String sql SELECT * FROM users ;那公共缩进量就不是 4 个空格了因为结束分隔符这一行的前导空白是 0编译器按它来计算内容行的缩进就会原样保留。实操中我建议统一把结束分隔符和内容行对齐这样行为最可预期。2.3 配套的String新方法配合文本块JDK 13 里也给 String 增加了一些方法其中日常最常用的是formatted。它本质上就是String.format的实例方法版本String template Hello, %s! Your score is %d. ; String message template.formatted(小明, 99);以前的写法是String.format(template, ...)现在可以直接在模板字符串后面调formatted读起来顺很多。另外还有stripIndent()和translateEscapes()两个方法分别用来去掉公共缩进和把转义序列翻译成实际字符。不过在 JDK 13 里文本块是预览特性这几个方法的使用场景基本都围绕文本块展开等文本块在后续版本转正后它们也跟着成了正式 API。有一点需要提醒JDK 13 的文本块只支持原有的转义序列比如\n、\t。后来版本里新增的\s空格和行尾\续行在 13 里还没有不要拿着新习惯往老版本代码里套。2.4 实际使用中的注意事项文本块最适合写 JSON、SQL、HTML、XML 这类自带格式的文本。我自己在项目里最常用它写 SQL 模板和测试数据确实清爽很多。但有几个坑必须注意第一文本块末尾会保留一个换行符。因为开始分隔符之后的内容是一个完整行结束分隔符前面的最后一个换行会被保留。如果你不想要末尾换行可以像前面例子那样把结束分隔符放在最后一行内容的后面;。第二IDE 的自动格式化可能破坏缩进计算。文本块里每行的前导空格是在字符串语义里的IDE 如果按代码缩进重新对齐输出内容就会变。后来版本里编译器的规则更精细但 13 上还是得自己多留个心眼。第三文本块是预览特性编译和运行都必须加开关javac --release 13 --enable-preview App.java java --enable-preview App如果只编译不加运行开关运行阶段会直接报错反过来如果编译时没开预览源码直接编译不过。这个开关问题我用过几次之后已经形成肌肉记忆了先加--enable-preview再跑。3. Switch表达式从语句到表达式的关键一步3.1 老Switch的三大问题老版 switch 语句是被吐槽最多的地方之一。第一个问题是容易漏写break导致意外贯穿。Java 的 switch 默认是 fall-through 行为一旦某个 case 匹配后没有break后续所有 case 都会执行。这个设计跟大多数现代语言相反也是很多 bug 的来源。第二个问题是每个 case 共享作用域。在 switch 里声明变量如果多个 case 分支都想用同一个变量名就得额外加大括号否则编译不过代码非常啰嗦switch (mode) { case a: int x 1; break; case b: int x 2; // 编译错误 break; }第三个问题是 switch 只能“执行”不能“返回”。实际开发里我们经常是根据某个值做映射得到一个结果老写法只能在外面声明一个变量在分支里赋值绕一圈才能拿到最终值。3.2 箭头语法与yieldJDK 12 给 switch 引入了箭头-语法JDK 13 在此基础上加了yield关键字让 switch 能以“表达式”的身份直接产生值。先看一个最简单的版本String label switch (day) { case MONDAY, FRIDAY - 工作日; case SATURDAY, SUNDAY - 休息日; default - 中间; };箭头后面接的是一个表达式或语句块不需要break也不会贯穿多个 case 值可以直接用逗号并列。如果分支需要做多步计算可以用花括号加yield返回结果int result switch (mode) { case a - 1; case b - { int temp compute(); yield temp * 2; } default - 0; };这里的yield和return不一样return是结束整个方法yield只是给 switch 表达式产生一个值。JDK 12 的预览版本里块级分支用的是break value这种写法到了 JDK 13 改成了yield语义更清晰。所以如果你在网上看到用break 返回值的代码那是 12 预览版的写法在 13 上已经不好使了。3.3 语句与表达式的对比维度传统 switch 语句switch 表达式JDK13返回值不能直接返回表达式整体可以赋值贯穿默认贯穿容易漏 break箭头语法天然不贯穿分支格式只能 case 冒号支持箭头和 yield穷尽性不强制必须覆盖所有情况或提供 default作用域分支间共享箭头分支各自独立穷尽性这一点特别值得注意。switch 表达式要求所有可能的值都有对应分支否则编译器直接报错。比如枚举类型如果枚举新增了一个常量而 switch 表达式没有处理它就编译不过。从好的方面想这是编译器在帮你做完整性检查从坏的方面想如果枚举经常变化每次都要记得补分支。我的习惯是对枚举做 switch 表达式时永远保留一个default避免一改枚举就编译失败。3.4 实战场景与搭配技巧我实际用得最多的是状态映射和策略选择。比如把一个状态码转成可读描述或者根据类型取不同的处理策略boolean canProcess switch (state) { case PENDING, PROCESSING - true; case DONE, FAILED - false; default - throw new IllegalArgumentException(未知状态: state); };另一个实用技巧是箭头分支右边接的是表达式所以可以直接调用返回同类型的方法。比如String result switch (type) { case admin - buildAdminLabel(); case user - buildUserLabel(); default - unknown; };代码比原来的 if-else 链干净很多。JDK 14 之后 switch 表达式转正就不需要预览开关了。如果你现在写的是 17 或 21语法基本一致只是不用再加--enable-preview。4. 动态CDS存档与ZGC内存增强4.1 CDS到底在做什么CDSClass Data Sharing类数据共享是一种启动优化技术。它的原理很简单JVM 启动时需要加载大量类把类元数据放到堆里这个过程既耗 CPU 也占内存。CDS 允许把类元数据预先处理成一个共享存档文件下次启动时直接映射这个存档省去类加载的解析和初始化工作。在 JDK 13 之前使用 CDS 需要手动生成类列表过程大概是用一个诊断参数运行应用把加载过的类记录到文本文件再用另一个参数配合类列表生成 CDS 存档最后启动时指定存档文件。这套操作对普通开发来说太繁琐所以大部分人根本不会碰。JEP 350 的目标就是把这个过程自动化应用退出时自动生成存档不需要你手工维护类列表。实际操作很简单。第一次运行java -XX:ArchiveClassesAtExitapp.jsa -cp app.jar com.example.Main应用正常退出后当前目录就生成了app.jsa。第二次启动时指定存档java -XX:SharedArchiveFileapp.jsa -cp app.jar com.example.Main如果不想分两次操作JDK 13 还提供了一个-XX:AutoCreateSharedArchive参数启动时指定存档路径JVM 发现存档不存在就自动生成下次启动自动使用java -XX:SharedArchiveFileapp.jsa -XX:AutoCreateSharedArchive -cp app.jar com.example.Main实测下来对小应用启动时间可能只有几百毫秒的差异但类数量大的应用收益明显。不过 CDS 存档有很强的环境绑定JDK 版本变了、类路径变了、甚至平台不同存档都可能失效。JVM 检测到不匹配时会忽略存档或者报警告应用本身不会挂但优化效果就没了。在容器环境里我建议在构建镜像的时候就生成好存档而不是让每个容器启动时现场生成。4.2 ZGC现在可以把内存还给系统ZGC 是 JDK 11 引入的一款低延迟垃圾回收器设计目标是把 GC 停顿时间控制在毫秒级面向大堆内存场景。不过最初版本的 ZGC 有个毛病已经向操作系统申请的内存在堆空闲之后不会归还。长时间运行的 JVM 哪怕实际使用率很低也会一直占着内存不放手。这在传统物理机部署时代问题不大但在容器和按内存计费的云环境里就是实打实的浪费。JEP 351 给 ZGC 加上了取消未使用内存的能力。核心参数是-XX:ZUncommitDelay单位秒默认 300 秒。意思是当堆内存出现空闲并且这种空闲持续超过 300 秒JVM 才会真正把内存还给操作系统。试想一下应用早上迎来一波高峰期内存申请到 8GB中午低谷期实际只用 2GB没有这个特性的话 8GB 一直被占用有了它空闲部分会在延迟时间后被释放。用法示例java -XX:UnlockExperimentalVMOptions -XX:UseZGC -XX:ZUncommitDelay120 -jar app.jar有一点需要明白延迟时间不是越小越好。如果应用的内存使用有周期性波动比如每分钟都有一次小高峰你把延迟设成 60 秒内存还回去之后马上又要重新申请频繁的归还和重新提交反而会带来额外开销。我个人的建议是容器内存受限或按内存计费的场景可以适当调低到 120 秒左右普通场景保持默认就很好。另外ZGC 在 JDK 13 里仍然是实验性特性需要配合-XX:UnlockExperimentalVMOptions -XX:UseZGC开启。后续版本逐渐成熟到低延迟场景里已经是很稳的选择但这些参数在 13 上是必须加的。4.3 Socket API底层重构JEP 353 重构了java.net.Socket和java.net.ServerSocket的底层实现。老实现是很多年前用本地 C 代码写的从 Java 1.0 时代一路留到现在维护成本高而且跟现代并发模型配合得不好。新实现基于 NIO 通道用纯 Java 代码完成结构清晰易维护也更适应高并发场景。对业务开发来说这个重构几乎是透明的Socket、ServerSocket的公共 API 完全没变你不需要修改调用代码。但底层变了总会有一些微妙差异需要留意。如果你的项目里有比较底层的网络通信模块升级到 JDK 13 之后建议做一轮压测特别是长连接多、并发量高的场景。万一压测发现异常可以用一个系统属性切回老实现排查java -Djdk.net.usePlainSocketImpltrue -jar app.jar这个开关很有用定位问题时先确认是不是新实现导致的行为变化。如果切回老实现后问题消失基本可以确定是新 Socket 实现的兼容性问题如果两边行为一致那就跟这次重构无关应该从代码层面找原因。5. 容易被忽略的几个更新5.1 Unicode 12.1支持JDK 13 同步升级了对 Unicode 12.1 的支持。对于绝大多数业务开发来说这个更新是无感的因为常规的字符处理不会立刻受影响。但如果你做的是国际化、字符分析、文本处理这类工作升级后某些字符的判断结果和编码转换行为可能发生变化。比如新增的字符、脚本或表情符号在旧版本里可能被当作普通符号处理新版本里会有更细的分类。范围比较窄但属于那种不查文档就容易踩坑的隐性变更。5.2 预览特性的开启与关闭JDK 13 里文本块和 switch 表达式都是预览特性这意味着即使你的源码用了 13 的新语法编译和运行也得同时加--enable-preview。这里有个非常容易踩的坑很多人在 IDE 里编译通过了但命令行运行时报UnsupportedClassVersionError或者preview features are not enabled就是因为编译时开了预览、运行时没开或者反过来。推荐的命令行组合是这样的javac --release 13 --enable-preview -d out src/com/example/App.java java --enable-preview -cp out com.example.App注意编译时最好加上--release 13否则编译器可能按当前默认版本处理导致二进制版本号不对。如果用的是 IDE也需要在编译选项里把语言级别设置成 13并且勾选预览选项。不同 IDE 的配置路径不一样但核心就是这两个开关要同时打开。5.3 非LTS版本的升级决策JDK 13 的生命周期很短过期之后官方不再提供免费更新。所以我不建议任何生产环境长期停留在 13。如果你所在的项目已经在用 11想升级到 17 或更后面的版本完全可以跳过 13如果你想体验文本块和 switch 表达式的新语法直接用 17 或 21 更好因为这些特性已经转正不用再忍受预览开关的各种麻烦。那学 JDK 13 还有什么意义我的理解是它是一份很好的“语法演进史教材”。看 17 的文本块你不会知道为什么缩进规则长这样看了 13 最初的实现你就知道哪些设计是后来根据反馈改的。对技术面试来说能把“这个特性在预览阶段长什么样、后来为什么改”讲清楚比单纯背特性列表要加分得多。6. 实际踩坑记录与排查速查表6.1 文本块缩进被“吃掉”的现场我之前写一个日志模板代码是这样的String log request received begin handle ;看起来一切正常但输出的时候发现每行前面的空格比预期少了很多。排查下来发现是我编辑器自动缩进把结束分隔符顶到了行首导致公共缩进量计算变成了 0内容行原有的缩进被原样保留于是模板的层级结构全乱了。这个问题在文本块转正后依然存在因为缩进计算的核心逻辑没变。我的解决办法是拿到输出后先打印一遍确认肉眼可见的内容正确再进代码不要凭编辑器里的显示判断最终效果。6.2 Switch表达式漏分支的编译错误有一次我在代码里用 switch 表达式处理一个枚举当时只写了几个具体分支和default后来枚举加了一个新值项目编译直接失败。错误信息指向 switch 表达式分支不完整。如果你是刚接触这个概念可能会觉得莫名其妙我用default兜底了怎么还报错原因在于当 switch 作为表达式时编译器要求所有输入值都有对应分支这是一种穷尽性检查。如果分支包含了default编译器认为默认情况已经覆盖所以不会报错但如果你想着靠枚举当前的值数量来保证穷尽一旦枚举扩展就会编译失败。我的建议很简单对枚举做 switch 表达式时要么显式写出所有值要么永远挂一个default否则就是给自己埋雷。6.3 CDS存档失效的排查动态 CDS 用起来很顺手但它有一个隐蔽的问题如果应用的 jar 包更新了而存档文件还是旧的JVM 可能不会报错而是直接悄悄忽略存档。你以为还在享受启动优化实际上已经退化成了普通启动。排查方法是加参数看日志java -Xlog:cds -XX:SharedArchiveFileapp.jsa -cp app.jar com.example.Main日志里会输出 CDS 存档是否成功映射。如果显示类似存档不匹配的信息就说明需要重新生成。在持续集成环境里我习惯把存档生成放进构建脚本确保每次发布都会基于最新的 jar 重新生成 CDS 存档避免手工维护导致过期。6.4 ZGC内存不释放的确认方法有朋友问过我为什么我开了 ZGC 的内存回收内存还是一直居高不下这里需要明确一点ZGC 归还内存是有条件的既要堆内存空闲比例达到一定要求也要空闲时间超过ZUncommitDelay的阈值。应用如果一直有合理的内存使用量那内存当然不会还回来。确认是否生效可以用 GC 日志java -Xlog:gc* -Xlog:gcheapdebug -XX:UnlockExperimentalVMOptions -XX:UseZGC -jar app.jar日志里会显示堆容量调整和内存提交的记录。如果完全没有任何归还迹象再把-XX:ZUncommitDelay调小一点试试。注意别调到 30 秒这种极端值要根据应用的实际内存曲线来定。6.5 常见问题速查表问题可能原因解决办法文本块编译失败没有加--enable-preview编译和运行都加开关运行时提示预览特性未启用只有编译加了开关运行也加java --enable-preview文本块输出缩进不对结束分隔符位置影响缩进计算结束分隔符与内容行对齐switch 表达式编译报分支不全枚举新增值或没有 default补全分支或加 defaultCDS 启动优化没生效存档过期或不匹配重建存档并查看-Xlog:cdsZGC 内存不归还未满足空闲时间/比例条件调整-XX:ZUncommitDelay并查日志我在 JDK 13 上验证这些特性时最深的体会是中间版本的预览特性确实能让人提前看到 Java 的未来但代价是要花不少时间去跟编译开关和缩进规则较劲。好在这些积累不会白费等你在新版本里再用同样的语法时基本就是零成本切换。如果你手里有闲余环境装一个 13 跑一跑这些例子感受一下语法演进的过程比单纯看资料要直观得多。如果是为了生产升级我建议还是直接看 17 或 21那些才是当前真正值得长期停留的版本。
