最近不少人在群里讨论一个问题团队还是全员JDK 8要不要赶在年底前升到JDK 17或者干脆赌一把直接上21我干了十多年Java从JDK 5一路写到现在说实话JDK 8确实统治得太久了。一个版本用了快十年才被慢慢松绑这在其他语言生态里几乎不可想象。但JDK 21发布之后这个选择题的性质变了——它不光是版本号往前挪而是整个语言、虚拟机、并发模型和工具链都换了一代。这篇文章我就把JDK 8到JDK 21这段演进路线完整梳理一遍包含每个版本的核心特性、适合谁用、对比差异以及迁移时最容易踩的坑。无论你是准备面试、做技术选型还是在给老项目找升级理由应该都能从中找到需要的东西。1. JDK 8的统治时代为什么老将至今未退场1.1 Lambda与Stream改变了Java的手感JDK 8发布到现在已经快十年它最厉害的地方不是某一个特性而是它改变了写Java代码时的手感。Lambda表达式让Java第一次有了像样的函数式编程体验。拿最常见的排序来说JDK 8之前你要写匿名内部类Collections.sort(list, new ComparatorUser() { Override public int compare(User u1, User u2) { return u1.getAge().compareTo(u2.getAge()); } });JDK 8之后这段代码可以直接缩成一行list.sort(Comparator.comparing(User::getAge));配合方法引用和函数式接口集合操作从描述怎么做变成了描述要什么。接着Stream API又补上了关键的一环过滤、映射、去重、分组、归约这些操作终于有了标准化的表达方式。以前你需要手写循环、维护临时集合、处理null判断现在可以这样写MapString, ListString groupByCity userList.stream() .filter(u - u.getAge() 18) .map(User::getName) .collect(Collectors.groupingBy(User::getCity));这段代码的意图一目了然而且因为Stream是惰性求值多个操作可以合并遍历性能上并不比传统循环差多少。Optional、默认方法、CompletableFuture也都是这个版本带来的。CompletableFuture对异步编程的意义尤其大它让回调地狱有了替代方案也为后面JDK 21的虚拟线程埋下了伏笔。1.2 新日期时间API与其他被低估的改进JDK 8里最容易被人忽略但日常开发天天用的是新日期时间API。以前用java.util.Date配合Calendar做日期计算坑多到说不完月份从0开始、线程不安全、时间格式化还容易踩时区的坑。JDK 8带来的LocalDate、LocalDateTime、Instant、Duration、Period这套API完全是另一个世界的体验LocalDate today LocalDate.now(); LocalDate deadline today.plusDays(7).with(TemporalAdjusters.next(DayOfWeek.MONDAY)); System.out.println(deadline);非常直观而且是不可变对象天然线程安全。接口默认方法让集合API可以平滑地增加新方法而不破坏所有实现类Stream和Optional也依赖这套机制。另一个容易被忽略的是Metaspace取代了PermGen永久代内存溢出问题从此成为历史JVM参数也从-XX:PermSize变成了-XX:MetaspaceSize。1.3 JDK 8长期统治的深层原因JDK 8能统治这么久不只是因为它自身优秀。Spring Framework 4/5、MyBatis、大多数中间件都以Java 8为基准版本大量企业系统已经稳定运行多年没有业务动力去动运行时招聘市场里的面试题、学习路线、八股文也几乎全以JDK 8为默认语言版本。一套存量代码跑得好好的升级又看不到立竿见影的收益团队自然会选择不动。但技术债是攒下来的。JDK 8的并发模型仍然是一个请求一个OS线程面对高并发IO密集型场景线程创建和切换的开销非常大G1虽然在JDK 8里已经可用但要到JDK 9才成为默认收集器吞吐量和延迟的调优体验远不如后来的ZGC语法层面也缺少现代语言标配的不可变数据载体、模式匹配这些能力。这些问题在JDK 21里基本都得到了系统性解决后面我会逐个展开。2. 模块化风波JDK 9到JDK 11的过渡与LTS分水岭2.1 JPMS模块系统理想丰满现实骨感JDK 9最大的动作是Project Jigsaw也就是Java Platform Module System它给JDK自身和Java应用定义了模块化方案。这个设计初衷很好解决类路径混乱、缺少强封装、无法构建小型运行时的问题。模块化之后你可以在module-info.java里声明模块依赖和对外暴露的包module com.example.app { requires java.sql; requires com.example.common; exports com.example.app.service; }但说实话JPMS在普通企业项目里落地的比例并不高。原因很简单让一个已经有几十个模块的老项目改成模块化结构代价非常大而收益对多数业务系统来说感知很弱。很多第三方库当时也没有模块化导致module-info经常被直接写成开放式模块open module来绕过限制。JDK 9真正对开发体验有正向影响的反而是几个轻量特性JShell交互式REPL、集合工厂方法List.of/Set.of/Map.of、接口私有方法。var list List.of(a, b, c); var map Map.of(key1, val1, key2, val2);不用再写繁琐的匿名内部类去初始化一个集合这个特性几乎零成本就能提升代码整洁度。JDK 9还引入了jlink可以用来定制最小运行时镜像虽然企业环境用得不多但为以后云原生场景打下了基础。2.2 JDK 10与JDK 11从var到LTS分水岭JDK 10引入了局部变量类型推断也就是var。这个特性刚出来时争议不小有人觉得会让代码失去类型信息但实际用下来只要遵循从右侧一眼能看出类型就不写类型的规则代码会清爽很多var request new HttpRequest(); var userList userService.queryByStatus(1);var不是JavaScript里的var它在编译期就完成了类型推断运行时仍然是强类型。JDK 11才是这段时间真正的重头戏它是继JDK 8之后第一个长期支持版本。这个版本把JDK 9和JDK 10积累的特性做了一次大整合正式带来了标准化后的HttpClient曾经的HttpURLConnection可以退休了很多第三方HTTP库在某些场景下也可以替换掉了HttpClient client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(5)) .build(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(https://api.example.com/users)) .GET() .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString());String类也增加了不少日常用得到的方法isBlank、lines、repeat、strip。比如统计多行文本里的非空行以前要写循环分割现在直接一句long count text.lines().filter(s - !s.isBlank()).count();同版本的ZGC还是实验特性但Flight RecorderJFR已经开源并进入主线JFR对线上问题排查非常有用。Epsilon这种不做任何回收的No-Op GC也在这个版本出现主要用于短生命周期任务和性能测试。2.3 从8升到11最先遇见的几个坑JDK 9到11期间Oracle做了不少清理动作很多过时API和Java EE模块被移除。这导致从JDK 8直接升到11时最容易遇到几类编译错误第一JAXB、JAX-WS、JAF这些Java EE模块不再随JDK分发。以前项目里直接用javax.xml.bind.annotation来解析XML升级编译直接找不到类。解决方案是显式引入依赖例如JAXB API和实现jar。第二访问JDK内部API被逐步限制。很多底层库尤其是字节码操作、代理、反射框架会用到sun.misc.Unsafe和com.sun.*内部类在JDK 11里不加--add-opens或--add-exports参数会直接运行时报IllegalAccessError。第三字节码版本和编译目标不匹配。用高版本JDK编译出来的.class文件低版本JVM跑不了反过来低版本JDK编译的代码在高版本运行一般没问题但高版本javac默认target是当前版本这会在生产环境报UnsupportedClassVersionError。当时做升级方案时我习惯先用jdeps把项目依赖和内部API引用扫一遍把所有风险点列出来再动手后面第5章会展开讲。3. 中段爆发JDK 12到JDK 17的语言级革命3.1 Switch表达式从语句到表达式的跳跃JDK 12引入的Switch表达式是Java语法演进里非常关键的一次设计变化。以前的switch是个语句有fall-through陷阱、容易漏break、也不能作为值返回。JDK 12之后可以用箭头语法了String result switch (day) { case MONDAY, FRIDAY - Work; case SATURDAY, SUNDAY - Rest; default - Unknown; };这段代码不用再写break多个case用逗号合并整个表达式可以直接赋值给变量。如果case里需要更复杂的逻辑可以配合yield返回值。这个特性到JDK 14正式定稿后面JDK 21又把模式匹配能力接了进来让switch可以匹配类型、解构Record这是后话。这个改动看起来不大但它体现了Java正在从只求稳向提升表达力转变。类似的还有JDK 13引入、JDK 15正式定稿的文本块特性。以前写多行SQL或者JSON字符串要么用一堆加号和转义符要么把整个字符串挤成一行根本没法看。用了文本块之后String sql SELECT id, name, email FROM user WHERE status ACTIVE ORDER BY created_at DESC ;不用再担心转义代码即所见。3.2 Record与密封类告别样板代码JDK 14预览、JDK 16正式定稿的Record是我个人最喜欢的JDK 17特性之一。以前写一个POJO要手动写getter、setter、equals、hashCode、toStringIDE生成一大片代码看着都累。Record直接把就是装数据这个意图变成语言关键字public record User(Long id, String name, String email) {}这一行就同时得到了不可变字段、构造方法、访问器和正确的equals/hashCode/toString。对于REST API的DTO、领域层值对象来说Record让代码量直接砍半。它和Lombok的区别在于Record是语言原生支持语义更清晰天然不可变不会有类库版本不匹配问题而且能被模式匹配直接解构。JDK 15预览、JDK 17正式定稿的密封类也很实用。它解决了继承权限失控的问题以前class默认是开放的谁都能继承现在你用sealed修饰明确告诉编译器这个类型只能被这几个类实现public sealed interface Shape permits Circle, Rectangle, Triangle {} public record Circle(double radius) implements Shape {} public record Rectangle(double width, double height) implements Shape {}配合switch表达式和instanceof模式匹配可以写出非常安全的穷尽性分支public double area(Shape shape) { return switch (shape) { case Circle c - Math.PI * c.radius() * c.radius(); case Rectangle r - r.width() * r.height(); case Triangle t - t.base() * t.height() / 2; }; }编译器会在分支不完整时报错避免漏处理。3.3 再聊JDK 17第一个值得无脑升的LTSJDK 17发布之前很多团队从JDK 8升到11感觉语言层面变化不大。但JDK 17带来的变化是一串的组合拳Record、密封类、instanceof模式匹配、Switch表达式、文本块全部就位ZGC和Shenandoah这两个低延迟垃圾收集器也从实验变成正式特性。我把JDK 8到JDK 21的特性演进整理成了下面这张表方便对照版本发布时间核心特性是否LTSJDK 82014.03Lambda、Stream、新日期API、Metaspace是JDK 92017.09JPMS模块系统、JShell、集合工厂方法否JDK 102018.03var局部变量类型推断否JDK 112018.09HttpClient标准化、ZGC实验、Flight Recorder是JDK 122019.03Switch表达式预览、Shenandoah实验否JDK 132019.09文本块预览、Switch表达式增强否JDK 142020.03Record预览、instanceof模式匹配预览、友好NPE否JDK 152020.09密封类预览、ZGC转正、Hidden Classes否JDK 162021.03Record正式、instanceof模式匹配正式、打包工具否JDK 172021.09密封类正式、LTS、强封装JDK内部API是JDK 182022.03默认UTF-8、简单Web服务器否JDK 192022.09虚拟线程预览、结构化并发孵化否JDK 202023.03虚拟线程第二次预览、作用域值孵化否JDK 212023.09虚拟线程正式、模式匹配for switch正式、分代ZGC是JDK 17成为LTS后Spring Framework 6和Spring Boot 3直接把基线提到Java 17这成了推动大量团队升级的核心动力。如果你还在JDK 8没有历史包袱的新项目完全没有理由不用JDK 17。这个版本还顺便清理了一些历史包袱RMI Activation被移除SecurityManager被标记为弃用JDK内部API实现强封装。4. 虚拟线程JDK 19到JDK 21的并发模型重塑4.1 传统线程在高并发IO下的瓶颈要说JDK 21最值得升级的理由虚拟线程肯定排第一。先理解传统线程的问题出在哪。JDK 8及此前所有版本的线程模型都是一个Java线程对应一个操作系统平台线程。创建一个线程的成本不低内存占用默认1MB栈空间线程量一旦上万光是栈内存就能把堆外空间吃光。更麻烦的是阻塞IO场景线程发一个网络请求然后阻塞在那里等响应这段时间里线程什么也不干白白占用资源。所以传统做法是用线程池限制并发数比如Tomcat默认200个线程。一旦同时有500个请求剩下300个只能排队。于是大家开始用WebFlux这类响应式编程模型用少量线程配合事件循环来扛高并发但代价是代码风格变成链路式回调学习和排查门槛都很高。虚拟线程要解决的就是这个问题让并发模型回归一个任务一个线程的直觉写法同时不浪费系统资源。4.2 虚拟线程的使用方式与工作原理虚拟线程从JDK 19开始预览到JDK 21正式落地。用法非常直观和普通线程几乎一样Thread vThread Thread.ofVirtual() .name(order-, 0) .start(() - processOrder()); ExecutorService executor Executors.newVirtualThreadPerTaskExecutor(); executor.submit(() - processOrder());为什么虚拟线程能扛得住大量并发核心在于它不再是一对一绑定OS线程。虚拟线程由JVM调度到少量的平台线程也就是Carrier Thread上执行。当虚拟线程里发生阻塞式IO时JVM会自动让出平台线程去跑其他虚拟线程这个挂起和恢复的过程JVM自己完成不涉及重量级的操作系统上下文切换。用大白话说虚拟线程是用户态线程平台线程是工人虚拟线程是任务工人空闲时会自动换下一个任务而不用每个任务都分配一个工人。我实际压测过一个模拟IO密集的REST服务同样的Tomcat配置从平台线程切换到虚拟线程后吞吐量提升接近一个数量级而代码本身几乎没改。但要注意虚拟线程不是让所有代码都变快。CPU密集型的计算任务虚拟线程收益有限在synchronized块里执行长期阻塞操作也会影响载体线程的调度需要改用ReentrantLock。这也是JDK 21官方在文档里明确提醒过的点。4.3 结构化并发与作用域值配套的并发工具虚拟线程解决了并发量大的问题但没解决任务生命周期管理。JDK 19开始孵化的结构化并发是要让并发代码像单线程代码一样容易理解。以前你ThreadPoolExecutor提交多个子任务各跑各的出了异常很难统一处理结构化并发的核心思路是子任务的生命周期必须限定在父任务的作用域内要么全部成功要么统一失败。try (var scope new StructuredTaskScope.ShutdownOnFailure()) { FutureString user scope.fork(() - fetchUser()); FutureString order scope.fork(() - fetchOrder()); scope.join(); scope.throwIfFailed(); // 组合结果 }这段代码里user和order两个子任务在同一个scope里并发跑任何一个出现异常或超时scope会自动关闭未完成的任务不需要你手动去做future.cancel()。还有一个配套的作用域值Scoped Values那是对ThreadLocal的替代方案解决了ThreadLocal在虚拟线程环境下的内存泄漏和值传递问题。这些特性在JDK 21还在持续孵化我建议业务代码可以先不急着用但要密切关注下一两个版本很可能成为标准能力。4.4 JDK 21的其他看点JDK 21是2023年9月发布的距离JDK 17正好两年也是Oracle新节奏下的又一LTS。这个版本除了虚拟线程轉正还正式落地了模式匹配for switch和Record模式第一次用的时候确实有现代语言的感觉Object obj parse(); if (obj instanceof User(String name, String email) u) { System.out.println(name : email); }switch里的模式匹配也能解构RecordString info switch (shape) { case Circle(double r) - radius r; case Rectangle(double w, double h) - area (w * h); default - unknown; };分代ZGC正式转正是在JDK 21Generational ZGC它把ZGC的吞吐量提升了一截同时对大堆场景更友好目前是超低延迟场景下的最佳选择。字符串模板预览特性也在这个版本以后拼接动态SQL和日志会更自然。Sequenced Collections则解决了集合取第一个/最后一个元素时API不一致的问题。5. 从JDK 8跳到JDK 21的迁移实战与避坑指南5.1 迁移项目的类型判断与风险拆解升级JDK其实80%的风险不在JDK本身而在依赖生态。动手之前先花半天把你项目的依赖树理一遍这是最值得的时间投入。我的做法是把项目分成三类来看第一类是纯Spring Boot MyBatis/JPA的标准业务系统这类项目升级难度最低。只要Spring Boot版本跟上比如Spring Boot 3要求Java 17其他组件跟着升级版本代码改动一般集中在少量API弃用上。第二类是用了大量字节码操作工具的项目比如CGLIB、ASM、ByteBuddy、Mockito、Lombok。这些工具对JDK内部API的依赖很深升级后很容易出现InaccessibleObjectException。这种项目升级前要重点检查工具库版本Lombok在JDK 17上至少用1.18.24JDK 21上建议1.18.30以上否则会直接编译失败或者运行期行为异常。第三类是老旧的Java EE应用还在使用JAXB、JAX-WS、JTA之类的Java EE标准这部分API在JDK 11之后就不再被内置升级前必须确认新版本中间件是否还兼容如果整个Web容器都比较老可能需要连同容器一起换。5.2 迁移路线图与工具选型我强烈推荐8到11到17到21的渐进式路线而不是一次从8直接飞到21。虽然理论上可以但一次升级会同时叠加语法变化、GC变化、内部API封装变化、第三方依赖大版本变化出了问题很难定位。每到一个LTS版本至少停一到两周让测试用例和线上观察给出结论再迈下一步。具体执行可以按这个顺序来切换JDK版本前先升级Maven/Gradle到支持对应JDK的版本。Maven 3.8对JDK 17没问题Gradle建议用7.3以上。使用jdeps扫描依赖和二进制代码的内部API引用jdeps --multi-release 17 --ignore-missing-deps -s target/classes/逐个检查编译错误优先处理第三方库版本问题再处理业务代码。配置好--add-opens和--add-exports参数针对运行时报错的模块精准放开。把IDE、CI、生产环境的JAVA_HOME统一更新这一步看起来简单但很多人栽在这里。我见过多次本地代码能跑CI编译失败原因就是CI节点还指着原JDK路径环境变量配置失败的问题绝大多数是JAVA_HOME路径写错或者没reload配置导致的。本地用sdkman管理多个JDK版本是一个相对省心的方案sdk list java sdk install java 21-tem sdk use java 21-tem发行版选型方面生产环境我推荐TemurinEclipse Adoptium或Amazon Corretto两者都提供长期免费更新红帽系环境还可以选Microsoft Build of OpenJDK。不建议在生产直接用Oracle JDK除非你已经清楚它的商业授权条款。5.3 典型兼容性问题与排查案例举一个真实排查案例。有个老项目从JDK 8升到JDK 17编译全过但一启动就报java.lang.reflect.InaccessibleObjectException: Unable to make field private java.lang.ClassLoader原因是项目里某个缓存组件通过反射访问了ClassLoader的内部字段JDK 17强封装之后被拦住了。解决思路是不要上来就加--add-opens把整个模块打开先用堆栈把具体是哪个库、访问了哪个包定位清楚再去评估这个依赖有没有新版本。那次最后是升级了CGLIB版本彻底绕开对内部字段的反射访问而不是给JVM参数打补丁这样后续升级才不会继续踩。另一个高频问题是可以预判的就是前面提到的UnsupportedClassVersionError。很多团队的CI有个毛病开发环境用新JDK生产JVM还是旧的导致编译出来的class版本在生产跑不了。这个问题的根因不是版本高而是编译目标没有固定。推荐所有项目显式设置编译参数比如Maven编译器插件里统一指定properties maven.compiler.release17/maven.compiler.release /propertiesrelease参数会自动限制编译目标为JDK 17的API避免误用了更高版本API还不自知。还有个小坑JDK 18起默认字符集改成了UTF-8JDK 8默认字符集是跟随系统环境的。如果你的服务部署在Windows或某些非UTF-8环境日志和文件读写出现乱码很可能是这个变化造成的别一开始就怀疑代码写错了。5.4 迁移后的收益量化与面试考点迁移这件事如果只是喊口号新版本更好很难说服团队和领导。最好把收益量化下来。我建议至少采集三个维度的数据GC停顿时间尤其是延迟敏感的网关类服务、高并发场景下单机的支撑请求量、以及同样业务场景下的平均响应时间。JDK 17配ZGC相比JDK 8配G1在很多IO密集和低延迟场景下停顿时间可以降低80%以上JDK 21虚拟线程跑IO密集型任务时吞吐量提升几倍是常见情况。有这些数字后续申请升级预算就顺畅多了。面试角度来说Java版本演进几乎是必考题。常见的比如JDK 8到JDK 17有哪些新特性虚拟线程和线程池的区别Record和Lombok怎么选为什么JDK 17是LTS而JDK 18不是。回答这些问题的核心不是背八股而是把特性性能和版本节奏讲清楚Oracle从JDK 9之后改成每六个月一个feature版本每两年出一个LTSJDK 8、11、17、21就是这套节奏里的长期支持版本虚拟线程解决的是IO密集型并发扩展问题Record解决的是不可变数据载体样板代码问题。把这些说清楚比单独背几十个特性名称更能体现真实理解。最后再分享一个个人经验。之前帮一个老项目从JDK 8迁到JDK 17真正花在业务代码上的改动其实很少大头全在依赖升级和构建配置上。提前用jdeps全量扫描配合精准的--add-opens参数整个流程比想象中顺。JDK 21发布之后新项目我基本会直接选它老项目我个人建议先迁到17等依赖和生产环境都验证过一轮再逐步推进21。虚拟线程确实香但前提是你得真的理解阻塞与非阻塞的区别以及哪些资源是必须保持作用域封闭的否则一样会翻车。版本号说到底只是一个数字背后是运行时、工具链和写代码习惯的一次整体升级这一步早迈比晚迈轻松。
最近不少人在群里讨论一个问题团队还是全员JDK 8要不要赶在年底前升到JDK 17或者干脆赌一把直接上21我干了十多年Java从JDK 5一路写到现在说实话JDK 8确实统治得太久了。一个版本用了快十年才被慢慢松绑这在其他语言生态里几乎不可想象。但JDK 21发布之后这个选择题的性质变了——它不光是版本号往前挪而是整个语言、虚拟机、并发模型和工具链都换了一代。这篇文章我就把JDK 8到JDK 21这段演进路线完整梳理一遍包含每个版本的核心特性、适合谁用、对比差异以及迁移时最容易踩的坑。无论你是准备面试、做技术选型还是在给老项目找升级理由应该都能从中找到需要的东西。1. JDK 8的统治时代为什么老将至今未退场1.1 Lambda与Stream改变了Java的手感JDK 8发布到现在已经快十年它最厉害的地方不是某一个特性而是它改变了写Java代码时的手感。Lambda表达式让Java第一次有了像样的函数式编程体验。拿最常见的排序来说JDK 8之前你要写匿名内部类Collections.sort(list, new ComparatorUser() { Override public int compare(User u1, User u2) { return u1.getAge().compareTo(u2.getAge()); } });JDK 8之后这段代码可以直接缩成一行list.sort(Comparator.comparing(User::getAge));配合方法引用和函数式接口集合操作从描述怎么做变成了描述要什么。接着Stream API又补上了关键的一环过滤、映射、去重、分组、归约这些操作终于有了标准化的表达方式。以前你需要手写循环、维护临时集合、处理null判断现在可以这样写MapString, ListString groupByCity userList.stream() .filter(u - u.getAge() 18) .map(User::getName) .collect(Collectors.groupingBy(User::getCity));这段代码的意图一目了然而且因为Stream是惰性求值多个操作可以合并遍历性能上并不比传统循环差多少。Optional、默认方法、CompletableFuture也都是这个版本带来的。CompletableFuture对异步编程的意义尤其大它让回调地狱有了替代方案也为后面JDK 21的虚拟线程埋下了伏笔。1.2 新日期时间API与其他被低估的改进JDK 8里最容易被人忽略但日常开发天天用的是新日期时间API。以前用java.util.Date配合Calendar做日期计算坑多到说不完月份从0开始、线程不安全、时间格式化还容易踩时区的坑。JDK 8带来的LocalDate、LocalDateTime、Instant、Duration、Period这套API完全是另一个世界的体验LocalDate today LocalDate.now(); LocalDate deadline today.plusDays(7).with(TemporalAdjusters.next(DayOfWeek.MONDAY)); System.out.println(deadline);非常直观而且是不可变对象天然线程安全。接口默认方法让集合API可以平滑地增加新方法而不破坏所有实现类Stream和Optional也依赖这套机制。另一个容易被忽略的是Metaspace取代了PermGen永久代内存溢出问题从此成为历史JVM参数也从-XX:PermSize变成了-XX:MetaspaceSize。1.3 JDK 8长期统治的深层原因JDK 8能统治这么久不只是因为它自身优秀。Spring Framework 4/5、MyBatis、大多数中间件都以Java 8为基准版本大量企业系统已经稳定运行多年没有业务动力去动运行时招聘市场里的面试题、学习路线、八股文也几乎全以JDK 8为默认语言版本。一套存量代码跑得好好的升级又看不到立竿见影的收益团队自然会选择不动。但技术债是攒下来的。JDK 8的并发模型仍然是一个请求一个OS线程面对高并发IO密集型场景线程创建和切换的开销非常大G1虽然在JDK 8里已经可用但要到JDK 9才成为默认收集器吞吐量和延迟的调优体验远不如后来的ZGC语法层面也缺少现代语言标配的不可变数据载体、模式匹配这些能力。这些问题在JDK 21里基本都得到了系统性解决后面我会逐个展开。2. 模块化风波JDK 9到JDK 11的过渡与LTS分水岭2.1 JPMS模块系统理想丰满现实骨感JDK 9最大的动作是Project Jigsaw也就是Java Platform Module System它给JDK自身和Java应用定义了模块化方案。这个设计初衷很好解决类路径混乱、缺少强封装、无法构建小型运行时的问题。模块化之后你可以在module-info.java里声明模块依赖和对外暴露的包module com.example.app { requires java.sql; requires com.example.common; exports com.example.app.service; }但说实话JPMS在普通企业项目里落地的比例并不高。原因很简单让一个已经有几十个模块的老项目改成模块化结构代价非常大而收益对多数业务系统来说感知很弱。很多第三方库当时也没有模块化导致module-info经常被直接写成开放式模块open module来绕过限制。JDK 9真正对开发体验有正向影响的反而是几个轻量特性JShell交互式REPL、集合工厂方法List.of/Set.of/Map.of、接口私有方法。var list List.of(a, b, c); var map Map.of(key1, val1, key2, val2);不用再写繁琐的匿名内部类去初始化一个集合这个特性几乎零成本就能提升代码整洁度。JDK 9还引入了jlink可以用来定制最小运行时镜像虽然企业环境用得不多但为以后云原生场景打下了基础。2.2 JDK 10与JDK 11从var到LTS分水岭JDK 10引入了局部变量类型推断也就是var。这个特性刚出来时争议不小有人觉得会让代码失去类型信息但实际用下来只要遵循从右侧一眼能看出类型就不写类型的规则代码会清爽很多var request new HttpRequest(); var userList userService.queryByStatus(1);var不是JavaScript里的var它在编译期就完成了类型推断运行时仍然是强类型。JDK 11才是这段时间真正的重头戏它是继JDK 8之后第一个长期支持版本。这个版本把JDK 9和JDK 10积累的特性做了一次大整合正式带来了标准化后的HttpClient曾经的HttpURLConnection可以退休了很多第三方HTTP库在某些场景下也可以替换掉了HttpClient client HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(5)) .build(); HttpRequest request HttpRequest.newBuilder() .uri(URI.create(https://api.example.com/users)) .GET() .build(); HttpResponseString response client.send(request, HttpResponse.BodyHandlers.ofString());String类也增加了不少日常用得到的方法isBlank、lines、repeat、strip。比如统计多行文本里的非空行以前要写循环分割现在直接一句long count text.lines().filter(s - !s.isBlank()).count();同版本的ZGC还是实验特性但Flight RecorderJFR已经开源并进入主线JFR对线上问题排查非常有用。Epsilon这种不做任何回收的No-Op GC也在这个版本出现主要用于短生命周期任务和性能测试。2.3 从8升到11最先遇见的几个坑JDK 9到11期间Oracle做了不少清理动作很多过时API和Java EE模块被移除。这导致从JDK 8直接升到11时最容易遇到几类编译错误第一JAXB、JAX-WS、JAF这些Java EE模块不再随JDK分发。以前项目里直接用javax.xml.bind.annotation来解析XML升级编译直接找不到类。解决方案是显式引入依赖例如JAXB API和实现jar。第二访问JDK内部API被逐步限制。很多底层库尤其是字节码操作、代理、反射框架会用到sun.misc.Unsafe和com.sun.*内部类在JDK 11里不加--add-opens或--add-exports参数会直接运行时报IllegalAccessError。第三字节码版本和编译目标不匹配。用高版本JDK编译出来的.class文件低版本JVM跑不了反过来低版本JDK编译的代码在高版本运行一般没问题但高版本javac默认target是当前版本这会在生产环境报UnsupportedClassVersionError。当时做升级方案时我习惯先用jdeps把项目依赖和内部API引用扫一遍把所有风险点列出来再动手后面第5章会展开讲。3. 中段爆发JDK 12到JDK 17的语言级革命3.1 Switch表达式从语句到表达式的跳跃JDK 12引入的Switch表达式是Java语法演进里非常关键的一次设计变化。以前的switch是个语句有fall-through陷阱、容易漏break、也不能作为值返回。JDK 12之后可以用箭头语法了String result switch (day) { case MONDAY, FRIDAY - Work; case SATURDAY, SUNDAY - Rest; default - Unknown; };这段代码不用再写break多个case用逗号合并整个表达式可以直接赋值给变量。如果case里需要更复杂的逻辑可以配合yield返回值。这个特性到JDK 14正式定稿后面JDK 21又把模式匹配能力接了进来让switch可以匹配类型、解构Record这是后话。这个改动看起来不大但它体现了Java正在从只求稳向提升表达力转变。类似的还有JDK 13引入、JDK 15正式定稿的文本块特性。以前写多行SQL或者JSON字符串要么用一堆加号和转义符要么把整个字符串挤成一行根本没法看。用了文本块之后String sql SELECT id, name, email FROM user WHERE status ACTIVE ORDER BY created_at DESC ;不用再担心转义代码即所见。3.2 Record与密封类告别样板代码JDK 14预览、JDK 16正式定稿的Record是我个人最喜欢的JDK 17特性之一。以前写一个POJO要手动写getter、setter、equals、hashCode、toStringIDE生成一大片代码看着都累。Record直接把就是装数据这个意图变成语言关键字public record User(Long id, String name, String email) {}这一行就同时得到了不可变字段、构造方法、访问器和正确的equals/hashCode/toString。对于REST API的DTO、领域层值对象来说Record让代码量直接砍半。它和Lombok的区别在于Record是语言原生支持语义更清晰天然不可变不会有类库版本不匹配问题而且能被模式匹配直接解构。JDK 15预览、JDK 17正式定稿的密封类也很实用。它解决了继承权限失控的问题以前class默认是开放的谁都能继承现在你用sealed修饰明确告诉编译器这个类型只能被这几个类实现public sealed interface Shape permits Circle, Rectangle, Triangle {} public record Circle(double radius) implements Shape {} public record Rectangle(double width, double height) implements Shape {}配合switch表达式和instanceof模式匹配可以写出非常安全的穷尽性分支public double area(Shape shape) { return switch (shape) { case Circle c - Math.PI * c.radius() * c.radius(); case Rectangle r - r.width() * r.height(); case Triangle t - t.base() * t.height() / 2; }; }编译器会在分支不完整时报错避免漏处理。3.3 再聊JDK 17第一个值得无脑升的LTSJDK 17发布之前很多团队从JDK 8升到11感觉语言层面变化不大。但JDK 17带来的变化是一串的组合拳Record、密封类、instanceof模式匹配、Switch表达式、文本块全部就位ZGC和Shenandoah这两个低延迟垃圾收集器也从实验变成正式特性。我把JDK 8到JDK 21的特性演进整理成了下面这张表方便对照版本发布时间核心特性是否LTSJDK 82014.03Lambda、Stream、新日期API、Metaspace是JDK 92017.09JPMS模块系统、JShell、集合工厂方法否JDK 102018.03var局部变量类型推断否JDK 112018.09HttpClient标准化、ZGC实验、Flight Recorder是JDK 122019.03Switch表达式预览、Shenandoah实验否JDK 132019.09文本块预览、Switch表达式增强否JDK 142020.03Record预览、instanceof模式匹配预览、友好NPE否JDK 152020.09密封类预览、ZGC转正、Hidden Classes否JDK 162021.03Record正式、instanceof模式匹配正式、打包工具否JDK 172021.09密封类正式、LTS、强封装JDK内部API是JDK 182022.03默认UTF-8、简单Web服务器否JDK 192022.09虚拟线程预览、结构化并发孵化否JDK 202023.03虚拟线程第二次预览、作用域值孵化否JDK 212023.09虚拟线程正式、模式匹配for switch正式、分代ZGC是JDK 17成为LTS后Spring Framework 6和Spring Boot 3直接把基线提到Java 17这成了推动大量团队升级的核心动力。如果你还在JDK 8没有历史包袱的新项目完全没有理由不用JDK 17。这个版本还顺便清理了一些历史包袱RMI Activation被移除SecurityManager被标记为弃用JDK内部API实现强封装。4. 虚拟线程JDK 19到JDK 21的并发模型重塑4.1 传统线程在高并发IO下的瓶颈要说JDK 21最值得升级的理由虚拟线程肯定排第一。先理解传统线程的问题出在哪。JDK 8及此前所有版本的线程模型都是一个Java线程对应一个操作系统平台线程。创建一个线程的成本不低内存占用默认1MB栈空间线程量一旦上万光是栈内存就能把堆外空间吃光。更麻烦的是阻塞IO场景线程发一个网络请求然后阻塞在那里等响应这段时间里线程什么也不干白白占用资源。所以传统做法是用线程池限制并发数比如Tomcat默认200个线程。一旦同时有500个请求剩下300个只能排队。于是大家开始用WebFlux这类响应式编程模型用少量线程配合事件循环来扛高并发但代价是代码风格变成链路式回调学习和排查门槛都很高。虚拟线程要解决的就是这个问题让并发模型回归一个任务一个线程的直觉写法同时不浪费系统资源。4.2 虚拟线程的使用方式与工作原理虚拟线程从JDK 19开始预览到JDK 21正式落地。用法非常直观和普通线程几乎一样Thread vThread Thread.ofVirtual() .name(order-, 0) .start(() - processOrder()); ExecutorService executor Executors.newVirtualThreadPerTaskExecutor(); executor.submit(() - processOrder());为什么虚拟线程能扛得住大量并发核心在于它不再是一对一绑定OS线程。虚拟线程由JVM调度到少量的平台线程也就是Carrier Thread上执行。当虚拟线程里发生阻塞式IO时JVM会自动让出平台线程去跑其他虚拟线程这个挂起和恢复的过程JVM自己完成不涉及重量级的操作系统上下文切换。用大白话说虚拟线程是用户态线程平台线程是工人虚拟线程是任务工人空闲时会自动换下一个任务而不用每个任务都分配一个工人。我实际压测过一个模拟IO密集的REST服务同样的Tomcat配置从平台线程切换到虚拟线程后吞吐量提升接近一个数量级而代码本身几乎没改。但要注意虚拟线程不是让所有代码都变快。CPU密集型的计算任务虚拟线程收益有限在synchronized块里执行长期阻塞操作也会影响载体线程的调度需要改用ReentrantLock。这也是JDK 21官方在文档里明确提醒过的点。4.3 结构化并发与作用域值配套的并发工具虚拟线程解决了并发量大的问题但没解决任务生命周期管理。JDK 19开始孵化的结构化并发是要让并发代码像单线程代码一样容易理解。以前你ThreadPoolExecutor提交多个子任务各跑各的出了异常很难统一处理结构化并发的核心思路是子任务的生命周期必须限定在父任务的作用域内要么全部成功要么统一失败。try (var scope new StructuredTaskScope.ShutdownOnFailure()) { FutureString user scope.fork(() - fetchUser()); FutureString order scope.fork(() - fetchOrder()); scope.join(); scope.throwIfFailed(); // 组合结果 }这段代码里user和order两个子任务在同一个scope里并发跑任何一个出现异常或超时scope会自动关闭未完成的任务不需要你手动去做future.cancel()。还有一个配套的作用域值Scoped Values那是对ThreadLocal的替代方案解决了ThreadLocal在虚拟线程环境下的内存泄漏和值传递问题。这些特性在JDK 21还在持续孵化我建议业务代码可以先不急着用但要密切关注下一两个版本很可能成为标准能力。4.4 JDK 21的其他看点JDK 21是2023年9月发布的距离JDK 17正好两年也是Oracle新节奏下的又一LTS。这个版本除了虚拟线程轉正还正式落地了模式匹配for switch和Record模式第一次用的时候确实有现代语言的感觉Object obj parse(); if (obj instanceof User(String name, String email) u) { System.out.println(name : email); }switch里的模式匹配也能解构RecordString info switch (shape) { case Circle(double r) - radius r; case Rectangle(double w, double h) - area (w * h); default - unknown; };分代ZGC正式转正是在JDK 21Generational ZGC它把ZGC的吞吐量提升了一截同时对大堆场景更友好目前是超低延迟场景下的最佳选择。字符串模板预览特性也在这个版本以后拼接动态SQL和日志会更自然。Sequenced Collections则解决了集合取第一个/最后一个元素时API不一致的问题。5. 从JDK 8跳到JDK 21的迁移实战与避坑指南5.1 迁移项目的类型判断与风险拆解升级JDK其实80%的风险不在JDK本身而在依赖生态。动手之前先花半天把你项目的依赖树理一遍这是最值得的时间投入。我的做法是把项目分成三类来看第一类是纯Spring Boot MyBatis/JPA的标准业务系统这类项目升级难度最低。只要Spring Boot版本跟上比如Spring Boot 3要求Java 17其他组件跟着升级版本代码改动一般集中在少量API弃用上。第二类是用了大量字节码操作工具的项目比如CGLIB、ASM、ByteBuddy、Mockito、Lombok。这些工具对JDK内部API的依赖很深升级后很容易出现InaccessibleObjectException。这种项目升级前要重点检查工具库版本Lombok在JDK 17上至少用1.18.24JDK 21上建议1.18.30以上否则会直接编译失败或者运行期行为异常。第三类是老旧的Java EE应用还在使用JAXB、JAX-WS、JTA之类的Java EE标准这部分API在JDK 11之后就不再被内置升级前必须确认新版本中间件是否还兼容如果整个Web容器都比较老可能需要连同容器一起换。5.2 迁移路线图与工具选型我强烈推荐8到11到17到21的渐进式路线而不是一次从8直接飞到21。虽然理论上可以但一次升级会同时叠加语法变化、GC变化、内部API封装变化、第三方依赖大版本变化出了问题很难定位。每到一个LTS版本至少停一到两周让测试用例和线上观察给出结论再迈下一步。具体执行可以按这个顺序来切换JDK版本前先升级Maven/Gradle到支持对应JDK的版本。Maven 3.8对JDK 17没问题Gradle建议用7.3以上。使用jdeps扫描依赖和二进制代码的内部API引用jdeps --multi-release 17 --ignore-missing-deps -s target/classes/逐个检查编译错误优先处理第三方库版本问题再处理业务代码。配置好--add-opens和--add-exports参数针对运行时报错的模块精准放开。把IDE、CI、生产环境的JAVA_HOME统一更新这一步看起来简单但很多人栽在这里。我见过多次本地代码能跑CI编译失败原因就是CI节点还指着原JDK路径环境变量配置失败的问题绝大多数是JAVA_HOME路径写错或者没reload配置导致的。本地用sdkman管理多个JDK版本是一个相对省心的方案sdk list java sdk install java 21-tem sdk use java 21-tem发行版选型方面生产环境我推荐TemurinEclipse Adoptium或Amazon Corretto两者都提供长期免费更新红帽系环境还可以选Microsoft Build of OpenJDK。不建议在生产直接用Oracle JDK除非你已经清楚它的商业授权条款。5.3 典型兼容性问题与排查案例举一个真实排查案例。有个老项目从JDK 8升到JDK 17编译全过但一启动就报java.lang.reflect.InaccessibleObjectException: Unable to make field private java.lang.ClassLoader原因是项目里某个缓存组件通过反射访问了ClassLoader的内部字段JDK 17强封装之后被拦住了。解决思路是不要上来就加--add-opens把整个模块打开先用堆栈把具体是哪个库、访问了哪个包定位清楚再去评估这个依赖有没有新版本。那次最后是升级了CGLIB版本彻底绕开对内部字段的反射访问而不是给JVM参数打补丁这样后续升级才不会继续踩。另一个高频问题是可以预判的就是前面提到的UnsupportedClassVersionError。很多团队的CI有个毛病开发环境用新JDK生产JVM还是旧的导致编译出来的class版本在生产跑不了。这个问题的根因不是版本高而是编译目标没有固定。推荐所有项目显式设置编译参数比如Maven编译器插件里统一指定properties maven.compiler.release17/maven.compiler.release /propertiesrelease参数会自动限制编译目标为JDK 17的API避免误用了更高版本API还不自知。还有个小坑JDK 18起默认字符集改成了UTF-8JDK 8默认字符集是跟随系统环境的。如果你的服务部署在Windows或某些非UTF-8环境日志和文件读写出现乱码很可能是这个变化造成的别一开始就怀疑代码写错了。5.4 迁移后的收益量化与面试考点迁移这件事如果只是喊口号新版本更好很难说服团队和领导。最好把收益量化下来。我建议至少采集三个维度的数据GC停顿时间尤其是延迟敏感的网关类服务、高并发场景下单机的支撑请求量、以及同样业务场景下的平均响应时间。JDK 17配ZGC相比JDK 8配G1在很多IO密集和低延迟场景下停顿时间可以降低80%以上JDK 21虚拟线程跑IO密集型任务时吞吐量提升几倍是常见情况。有这些数字后续申请升级预算就顺畅多了。面试角度来说Java版本演进几乎是必考题。常见的比如JDK 8到JDK 17有哪些新特性虚拟线程和线程池的区别Record和Lombok怎么选为什么JDK 17是LTS而JDK 18不是。回答这些问题的核心不是背八股而是把特性性能和版本节奏讲清楚Oracle从JDK 9之后改成每六个月一个feature版本每两年出一个LTSJDK 8、11、17、21就是这套节奏里的长期支持版本虚拟线程解决的是IO密集型并发扩展问题Record解决的是不可变数据载体样板代码问题。把这些说清楚比单独背几十个特性名称更能体现真实理解。最后再分享一个个人经验。之前帮一个老项目从JDK 8迁到JDK 17真正花在业务代码上的改动其实很少大头全在依赖升级和构建配置上。提前用jdeps全量扫描配合精准的--add-opens参数整个流程比想象中顺。JDK 21发布之后新项目我基本会直接选它老项目我个人建议先迁到17等依赖和生产环境都验证过一轮再逐步推进21。虚拟线程确实香但前提是你得真的理解阻塞与非阻塞的区别以及哪些资源是必须保持作用域封闭的否则一样会翻车。版本号说到底只是一个数字背后是运行时、工具链和写代码习惯的一次整体升级这一步早迈比晚迈轻松。
