没有sun.misc.Unsafe的Java 9：灾难吗？

在关于过渡到G1垃圾收集器的辩论之后，社区出现了另一个有争议的问题。 显然，默认情况下，在Java 9中将删除或禁用sun.misc.UnsafeAPI。DripStat 博客称其为“制造灾难”。

问题出在哪里？

sun.misc.Unsafe是一个私有且不受官方支持的API，许多供应商和框架仍在使用该API，以实现与操作系统，内存或其他硬件功能之类的高性能，低级交互。 Spring，Hazelcast，Cassandra，Grails，Akka和Hadoop使用sun.misc.Unsafe等 。

从对OpenJDK邮件列表的讨论中可以明显看出，由于模块化的限制，关于私有API在JDK 9中不可用的说法正在酝酿着一些不确定性。 尽管“明确需要此类的功能”，但默认情况下将禁用sun.misc.Unsafe 。

DripStat博客对这一变化进一步感叹。 缺少Unsafe类（以及启用它的默认标志）不仅会破坏诸如C​​assandra和Zookeeper之类的传统基础架构软件，而且会破坏大量主流应用程序，因为许多内部使用该类的库。

此后，启用Unsafe的标志将成为启动JVM的默认标志，因为如果没有它，您的Java应用程序将在没有通知的情况下中断。 由于大多数环境默认情况下不会在JVM参数中添加此标志，因此在系统上升级Java时，其软件将损坏。

它画在墙上：两层Java应用程序图片，显示了它们在Java 9之前和之后的使用。 向后兼容性将被破坏，Java 9的接受和分发也将受到干扰。

因此，采用Java 9将减慢爬行速度，这将影响整个Java生态系统。 这种情况类似于Python 2和3。

解决方案在眼前？

为了同时减轻潜在的问题，开发人员聚集在一起，从他们的角度准备了一份建议书 。 将建立一个特殊的工作组来保护sun.misc.Unsafe的某些部分，以便在OpenJDK项目下重新实现它。 甚至Java性能专家Kirk Pepperdine在原则上也同意此过程，他在InfoQ采访中说 ：

我们需要摆脱不安全吗，是的！ 我们需要保持不安全吗？ 是。 我们如何调和这些看似矛盾的立场？ 好了，我们需要规划一条迁移路径，以将我们现在知道如何实现的东西从Unsafe移到JDK适当的地方。

考虑到该计划旨在节省sun.misc.Unsafe的时机已晚 ，必须注意Java 9 有望在2016年9月22日投入使用。我们必须拭目以待，看看最终的解决方案是什么将需要。

翻译自: https://jaxenter.com/java-9-without-sun-misc-unsafe-119026.html