把线程池换成虚拟线程 我们有个网关聚合服务，每请求要并发调 5 个下游，原来用 200 个平台线程的池子，峰值打满就排队。用户多的时候，线程池耗尽，请求在队列里干等，RT 从 200ms 飙到 2 秒。听说 JDK 19 的虚拟线程能把"一个任务一个线程"做到近乎免费，就拿来做了对照实验，想看看是不
从一次支付状态建模说起 早些年写支付结果，我习惯用一个 enum 加一堆 if： enum PayStatus { SUCCESS, FAILED, PENDING, REFUNDED } void handle(PayStatus s) { if (s == SUCCESS) { ...
一段 SQL 在 Java 里换行，我存成了诡异的格式 前几天 Code Review，看到有人拼一条多行 SQL 用了老套路： String sql = "SELECT id, name, price FROM product " + "WHERE category = ? AND
为什么我们卡在 JDK 8，却决定直接跳 17 团队基础组件升级评审会上，有人提议"升到 JDK 11 过渡一下"。我投了反对票：既然要动，不如直接到 JDK 17——它是继 8 之后第二个长期支持版本（LTS），2021 年 9 月发布，生态已经足够成熟，而 11 到 17 之间没有第二个 LTS
「为什么这个 DTO 里的字段改不动了」 1 月底，一个新同事在群里问：他给订单查询的返回 DTO 加了个 @Data，然后用 Jackson 反序列化的时候报了一堆奇怪的错，改成 record 之后就好了，问我能不能把所有 DTO 都换成 record。 我当时的回答是：DTO 可以用，但不是所有
重构一段 140 行的 if-else 链 1 月初接手支付网关的回调处理模块，打开 NotifyDispatcher 一看，是一个 140 行的 if-else 链。我们新服务用的是 JDK 17（ZGC + G1 都在测），正好可以试试新的语法。 原始代码长这样 public NotifyRes
Code review 时那行 Arrays.asList 12 月底做代码评审，看到一个新同事写的状态判断： private static final List<String> PAID_STATUS = Collections.unmodifiableList( Arrays.a
起因：升级 JDK 11 之后堆少了 500 MB 前面那篇迁移记录里提过，订单服务从 JDK 8 升到 11 之后，稳定态堆占用从 2.6 GB 降到 2.1 GB。我当时只当是 GC 改进的附带效果，直到有同事问"为什么少了这么多"，我才认真去查了一下。 答案主要来自 JEP 254：紧凑字符串
起因：架构评审会上的一个提议 七月底的架构评审，有人提议"我们新服务要不要上 JPMS 模块化"。理由是能强封装、能裁剪 JRE 让镜像变小。当时我们正在做 JDK 11 迁移（见上一篇），正好顺手调研了一下。 我花了三天做了个 POC，结论是：服务端业务系统别上，工具类库可以考虑。过程和理由记一下
背景：一封邮件引发的升级 五月底基础架构组发了封邮件，说 Oracle JDK 8 从 8u211 起商业使用要收费，公司统一切 OpenJDK 11（下一个 LTS），老服务年底前迁完。我们组四个服务，清一色 Spring Boot 2.3.12 + JDK 8u282。我手上这个订单服务先动，Q
