最后一个服务切完是上周五晚上 我们 47 个 Java 服务，从 JDK 21 升到 25，前后六周。最后一个切完是 8 月 7 号晚上十一点半，切完我在群里发了句"收工"，然后第二天睡到中午。 JDK 25 从 GA 到现在十个月，这个时间点写"发布"有点晚。但好处是能用生产数据说话，而不是照着
从 JDK 21 切到 25，同样的服务堆占用降了 19% 我们一个文档问答服务在 JDK 21 上跑了快两年，堆峰值 4.8 GB，一直想降但找不到好办法——该做的代码优化都做了，GC 参数也调过了。 四月份我们把它切到了 JDK 25，只加了一个参数，堆峰值降到 3.9 GB。这个改动是 JEP
年初做技术盘点：Java 的启动性能和 AOT，现在到哪一步了 每年一月我会花几天时间把 Java 生态的重点项目过一遍，看看有哪些东西从「观望」变成了「可以用」。今年重点看了三块：Leyden 的进展、AOT 生态的成熟度、以及启动性能的现状。 结论先说：JDK 25 这一代，启动性能有了不需要改
从 3.3.5 升到 3.5.3，踩了四个坑 八月底我们把手上 11 个服务从 Spring Boot 3.3.5 升到了 3.5.3。原本计划两天搞定，实际花了九天，中间回滚了一次。这篇记录升级过程和四个值得说的坑。 先说结论：值得升，但别在业务高峰期前升。ServiceConnection 和结
为什么我们决定在非 LTS 版本上跑生产 JDK 24 今年三月发布，是非 LTS 版本。我们公司原来的规矩是只用 LTS，所以 JDK 24 刚出来时没人提议升级。 改变想法是因为三个具体需求：AI 服务里的虚拟线程 pinning 问题、推理结果回写服务的大堆小对象内存压力、以及函数计算场景的冷
语义缓存一直跑在 Redis Stack 上，Redis 8 说要合并进来 我们的语义缓存从 2024 年 9 月开始就跑在 Redis Stack 上（就是那个带 RediSearch 模块的发行版）。这套方案最大的别扭之处是：它跟官方主线版本是两套东西，运维要单独装，升级要跟 Stack 的节奏
JNI 那套胶水代码，我写了三年，写烦了 我们有个自研的向量检索库 libhnswwrap.so，C++ 写的，Java 侧通过 JNI 调用。三年来每次 C++ 侧改接口，我都要同步改三处：C 的胶水层、Java 的 native 方法声明、还有两边的结构体序列化代码。 上次升级的改动是增加了一个
网关从 3.2 升到 3.3，我把虚拟线程打开了 国庆前最后一周，我把内部 API 网关从 Spring Boot 3.2.5 升到了 3.3.4。这次升级的动机不是安全补丁，而是 3.3 里那几个终于能用的东西：虚拟线程的正式支持、CDS 启动优化，还有服务连接抽象。 网关是个典型的 IO 密集型
季度技术评审上被问：JDK 23 要不要跟 8 月底的季度技术评审，架构师抛了个问题：JDK 22 已经用了小半年，JDK 23 再过半个月就 GA，咱们是继续滚动跟版本，还是钉在 JDK 21 LTS 上不动。 当时线上三个集群：订单跑 JDK 17，网关和用户中心跑 JDK 21，还有个新做的
JDK 21 预览、JDK 22 二次预览的"字符串模板"（String Templates，JEP 430 / JEP 459），原本被寄望取代丑陋的 String.format 和拼接。结果后来被正式撤回。作为一个写了七年后端的人，我反而觉得这次"撤回"是语言演进里难得的清醒。 它想解决什么 传
