Java
FFM 和虚拟线程作为新特性虽然已经正式推出，但它们的发展之路还远未结束。JDK 官方在采访中提到，目前每 6 个月发布一个新版本的节奏非常快。经过多个 preview 版本收集开发者的反馈后，确定了整体 API 的范围，并将其作为最终特性发布。但这并不意味着功能已经完全成熟，后续还需要进行大量的优化工作。以虚拟线程为例，尽管它已经被正式推出，但同步（Synchronize）相关的问题尚未解决。官方认为，这仍是一个积极的信号，表明虚拟线程已经可以投入使用，鼓励开发者尽快尝试，以便发现问题并进一步优化。实际上，虚拟线程目前还缺乏结构化并发、scoped value 和更加灵活的调度策略等一系列基础功能，这些都需要在未来逐步完善。再来看 FFM，我在自己的项目中已经使用了一段时间。FFM 功能确实强大，但由于 JDK 22 并非 LTS 版本，愿意冒险用它替换 JNI 的大型开源项目可能并不多，大多数团队可能仍处于试用阶段。FFM 的 upcall 性能相比 JNI 提升显著，但 downcall 的表现却不如 JNI，主要原因是存在边界检查等问题。针对这一情况，JDK 官方计划通过优化 JIT 编译器，尽量让 Panama 的调用开销与 JNI 持平甚至更优。这需要对 C2 和 Graal 编译器进行大量强化。例如，对于原始类型的循环展开，JVM 已经能够很好地实现自动向量化，但在处理 MemorySegment 操作时稳定性较差，尤其是在使用 Graal 的情况下。此外，在高频 Native 操作的
Java 应用中，当前的 MemorySegment 还存在一个问题：由于 Valhalla 项目尚未完成，MemorySegment 并不是真正的值类型，依赖逃逸分析的技术还不够稳定。相比之下，Unsafe 操作的大多是原始类型，可以非常稳定地实现栈上分配。因此，像 QuestDB 这类应用短期内不会将 Unsafe 替换为 Panama。展望未来，JDK 团队的工作重心可能会更多地转向 Valhalla 项目的实现。这将是一项革命性的重构工程，其复杂程度极高，甚至在
Java 25 开始 preview 都可能面临困难。我们期待在
Java 29 中看到它的正式发布！
