Java移除sun.misc.Unsafe相关兼容性及迁移问题咨询

是否需要为应用提供移除前后两个版本？ #

不需要刻意维护两个独立版本，这会大幅增加后续维护成本。更合理的做法是：

• 若为自研应用，逐步将sun.misc.Unsafe的调用替换为官方FFM API，发布兼容新旧Java版本的过渡版本；
• 若为第三方应用，可先通过临时兼容方案（见下文）在新Java版本上运行，同时等待厂商推出适配版本。

为什么不保留Unsafe让社区自行迁移？ #

sun.misc.Unsafe从设计之初就是未公开的内部API，从未纳入Java官方兼容性承诺范畴。移除它的核心原因包括：

1. 安全与稳定性风险：Unsafe允许绕过Java安全模型直接操作内存、调用底层方法，极易引发内存泄漏、崩溃等难以排查的问题；
2. 标准化替代方案成熟：FFM API（Foreign Function & Memory API）是官方推出的标准化底层访问方案，提供了更安全、可控的内存操作和外部函数调用能力，可完全替代Unsafe的大部分使用场景；
3. 推动生态进化：保留Unsafe会让社区长期依赖非标准API，阻碍Java生态向更规范、安全的方向发展。

社区计划如何应对？Java历史上有过类似变更吗？ #

社区的核心应对方式是提前适配：

• 主流开源框架（如Netty、Guava、Spring等）已在新版本中逐步替换Unsafe调用为FFM API或其他官方替代方案；
• 部分第三方工具会提供兼容层，将Unsafe调用转发到FFM实现，帮助旧代码平稳过渡。

Java历史上并非首次移除内部API：

• Java 9模块化后，移除了com.sun.image.codec.jpeg.JPEGImageEncoder等一批未公开API；
• Java 11移除了sun.misc.BASE64Encoder/Decoder，官方推荐使用java.util.Base64替代；
• 类似的内部API清理在多个大版本中都有发生，核心目的是推动生态向标准化API靠拢。

有没有第三种选择？ #

除了“不升级新JVM”和“等待厂商新版本”，还有几种可行的过渡方案：

• 临时兼容参数：启动应用时添加--add-exports java.base/sun.misc=ALL-UNNAMED参数，暂时允许访问Unsafe。但这只是临时 workaround，后续版本可能彻底失效，不建议长期使用；
• 字节码增强：使用ASM、ByteBuddy等字节码工具，在运行时将Unsafe调用替换为FFM API的实现；
• 自研兼容层：若为自研应用，可封装一层兼容逻辑，在旧Java版本使用Unsafe，新版本自动切换到FFM API；
• 第三方兼容库：部分社区库会提供Unsafe的兼容包装类，底层根据Java版本自动适配FFM或原生Unsafe。

内容的提问来源于stack exchange，提问作者user19401035