sun.misc.Unsafe的未来将如何发展？

随着2015年即将结束，我们认为这将是对Java社区过去一年中最热门辩论之一进行尸检的好机会。 通过查看标题，您中的大多数人可能已经开始在口腔中产生酸味并在肠道中产生愤怒的感觉，但是如果您错过了该操作，让我们来回顾一下所有引起大惊小怪的事情。

最重要的是：sun.misc.Unsafe不会走到任何地方

整个辩论始于7月，当时Oracle正在考虑删除许多开发人员所依赖的作为JVM关键API之一的Unsafe库。 该提案建议，在Java 9发行时，Unsafe将被完全封装，尽管该Java版本的发行日程仍遥遥无期，但仅此宣布就在开发人员社区引起了轩然大波。

我们看到Reddit，Twitter和多个博客对此举表示了批评，许多开发人员感到甲骨文“背叛了”，原因有以下三个主要原因：

1. Unsafe提供了对有助于开发许多工具的低级功能的访问。
2. 这些相同的功能在内部JVM库之外没有任何其他选择。
3. 许多开发人员担心sun.misc.Unsafe的封装会产生负面影响，甚至将许多工具减少到无法使用的状态。

暂时存在一个折衷方案，这是Java平台组首席架构师Mark Reinhold建议的三步解决方案 。 该解决方案概述了封装内部API（例如Unsafe）的所需过程：

1. 如果它在JDK 8中具有受支持的替代品，那么它将被封装在JDK 9中
2. 如果它在JDK 8中没有受支持的替代品，则它将不会封装在JDK 9中，因此外部代码仍然可以访问它； 并进一步，
3. 如果它在JDK 9中具有受支持的替代产品，那么它将不推荐使用，并将其封装在JDK 9中，甚至可能在JDK 10中将其删除。

所以现在的问题是：Oracle为什么要寻求消除不安全并从头开始这场风暴？ 要了解，我们可能应该在做出任何判断之前以一种或另一种方式客观地看待事物。

如何变得不安全

我们唯一可以启动检查此类火灾原因的过程的地方就是Unsafe库本身。 许多开发人员已经开始依靠其独特的功能来完成各种任务，但是，请不要忘记，Unsafe库实际上并不意味着内部开发团队之外的任何人都可以访问。 它曾经是而且仍然是一种不规则，巧合，各种错误。

当然，这是一次非常有用和快乐的巧合，但它根本就不会发生。 多年以来，各种不安全的用途已成为实际上的标准，但是这些用途中的任何一种的起源仍源于错误。 因此，期望Oracle无限期地保留过时的Sun *库有点不合逻辑。毕竟，如果我们中有人发现了自己代码中的错误，我们是否会努力消除它？

社区的反应–一场灾难

随着Unsafe风暴席卷整个Java开发人员社区，有两个主要问题不断出现。 第一个是先前讨论的背叛感（是否合理，取决于您的观点）。 第二个，也许稍微更合理-出于合理的担心，封装Unsafe将有史以来第一次违反Java的一项主要承诺-向后兼容性。

一些开发人员一直在发布有关消除或限制访问Unsafe的可能结果的世界末日帖子，称许多工具，库和基础结构软件直接或在可见代码下方使用该库，其中包括Hazelcast，Cassandra，Spring等。其他。

如果要完全实现Oracle的封装计划，那么使用一个或多个这些工具的任何开发人员都会遇到严重的困难。

甲骨文的立场–

该库的名称应表明该库存在使用风险，并且Oracle所做的一切实际上都是在试图最大程度地降低任何潜在风险。 在任何地方使用标题为“不安全”的库有点像看到雷区，成功穿越它，然后邀请所有朋友也穿越它，因为它“为您工作”。 那只会导致一个结果：

多年来，Oracle一直在解释说，尽管他们赞赏所有社区使用Unsafe库在开发方面所做的努力，但是访问这样低级的库应该被视为有使用风险。 不负责任地使用未记录的库可能会在使用该库的任何平台上导致各种内存问题和其他处理过载。 就Oracle而言，这就是“不太理想的结果”的确切定义。 可能需要注意的是，并不是所有Java中的“弃用”在发生时都被认为是不好的，有些人，例如删除PermGen最终被称赞为“ 非常积极” 。

最后的想法

看起来，尽管Java平台团队看到了抗议的蔓延（他们很可能知道抗议即将来临）并最终找到了解决该问题的合理解决方案，或者至少可以与开发人员社区一起生活。

距离Java 9的实际发布版本还有1年多的时间，无论是否以任何形式或形式存在Unsafe库，而且其他更改和声明可能很快就会到来。 您可以访问我们的倒计时站点java9countdown.xyz并注册新闻通讯，以获取有关Java 9所有相关问题的最新信息。

翻译自: https://www.javacodegeeks.com/2016/01/still-unsafe-major-bug-java-6-turned-java-9-feature.html