去年用 JDK 21 虚拟线程接重构一个 HTTP 聚合服务,压测时吞吐死活上不去。翻 JFR 发现大量"虚拟线程被 pin 在载体线程上"的事件——罪魁是代码里随处可见的 synchronized。JDK 22/23 的改进,正好把这块骨头啃了下来。 Pin 是什么,为什么是性能杀手 虚拟线程的精
起因:升级 JDK 11 之后堆少了 500 MB 前面那篇迁移记录里提过,订单服务从 JDK 8 升到 11 之后,稳定态堆占用从 2.6 GB 降到 2.1 GB。我当时只当是 GC 改进的附带效果,直到有同事问"为什么少了这么多",我才认真去查了一下。 答案主要来自 JEP 254:紧凑字符串
运维问我们:服务器上装的 JDK 要不要交钱 11 月底,运维在群里发了张截图,是某篇公众号文章的标题:"Oracle JDK 开始收费,你们公司准备好被起诉了吗"。他问我们的服务器要不要处理。 我把许可协议翻了一遍,发现事情没那么吓人,但确实得做个决定。这篇是整理出来的结论。 到底改了什么 201