最后一个服务切完是上周五晚上 我们 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
从 2023 年 9 月到今天，虚拟线程我们用了两年半 JDK 21 发布是 2023 年 9 月，我们当年 11 月就把一个内部服务切到了虚拟线程，算是比较早的一批。到今天两年半，虚拟线程跑在我们 14 个服务上，处理过峰值 4.7 万 QPS 的流量，也引发过两次 P2 故障。 这篇不写原理，只
年初做技术盘点：Java 的启动性能和 AOT，现在到哪一步了 每年一月我会花几天时间把 Java 生态的重点项目过一遍，看看有哪些东西从「观望」变成了「可以用」。今年重点看了三块：Leyden 的进展、AOT 生态的成熟度、以及启动性能的现状。 结论先说：JDK 25 这一代，启动性能有了不需要改
为什么我们决定在非 LTS 版本上跑生产 JDK 24 今年三月发布，是非 LTS 版本。我们公司原来的规矩是只用 LTS，所以 JDK 24 刚出来时没人提议升级。 改变想法是因为三个具体需求：AI 服务里的虚拟线程 pinning 问题、推理结果回写服务的大堆小对象内存压力、以及函数计算场景的冷
冷启动 4.2 秒，函数计算按毫秒计费 我们有一部分服务跑在函数计算上（内部 FaaS 平台），按实际运行时间计费。其中一个是文档解析入口，Spring Boot 3.5 应用，冷启动实测 4.2 秒——也就是说每次冷启动，用户先付 4.2 秒的钱，其中真正干活的只有不到 1 秒。 去年我们试过 G
我们有个 WebFlux 服务，没人愿意改它 我们有个网关服务是 2021 年用 WebFlux 写的，三个接口、两千多行，但组里除了我没人愿意碰它。原因很简单：那套 Mono/Flux 的链式调用，加上 .flatMap() 里嵌套 .zip() 的写法，改起来要花两倍时间，而且出错后堆栈完全看不
组里的实习生问我"Java 是不是没前途了" 2025 年春节后回来的第一周，组里新来的实习生私下问我："现在 AI 不都是 Python 写的吗，我学 Java 是不是选错方向了？" 这话我没法用一句"不会"糊弄过去，因为他说的是事实的一部分——过去两年所有模型层的创新确实都在 Python 生态
5 万条评测数据，从 80 分钟压到 9 分钟 今年 1 月要做一次大模型效果评测：5 万条标注问题，分别跑三个候选模型，记录每条的输出、耗时和 token 数。总共 15 万次调用。 第一版脚本用 200 线程的固定线程池，跑了 82 分钟还没跑完（因为触发限流重跑了一批）。我花了一天改成虚拟线程
JNI 那套胶水代码，我写了三年，写烦了 我们有个自研的向量检索库 libhnswwrap.so，C++ 写的，Java 侧通过 JNI 调用。三年来每次 C++ 侧改接口，我都要同步改三处：C 的胶水层、Java 的 native 方法声明、还有两边的结构体序列化代码。 上次升级的改动是增加了一个
