Oracle确定Unsafe类处理策略

近来，sun.misc.Unsafe这一Java库类成了一个备受争议的话题。上周，Oracle首席Java架构师和Jigsaw项目经理Mark Reinhold在博文中就该类的未来阐述了一些观点。

Reinhold将Oracle的处理策略简要描述为：

• 如果它[编者注：任何特定的sun.misc.Unsafe特性]在JDK 8中有一个受支持的替代选项，那么我们将在JDK 9中将其封装；
• 如果它在JDK 8中没有一个受支持的替代选项，那么我们将不会在JDK 9中将其封装，以便外部代码仍然可以使用它；而且，
• 如果它在JDK 9中有一个受支持的替代选项，那么我们将在JDK 9中弃用它，并且会在JDK 10中将其封装，甚或移除。

OpenJDK提案JEP 260已经被授权“封装大部分内部API”，它的创建反映了Oracle的策略。Jigsaw 项目已经严重拖期，Oracle试图用它模块化JDK，并提供Java模块化开发功能。

sun.misc.Unsafe是一个不受支持的Java类，它提供了底层“非安全”（按Java沙箱标准）操作的基本实现。传统上，自Java创建以来，Java创建者Sun Microsystems公司就不赞成使用“sun”包。

Unsafe并不是一个正统的Java类，它来自不受支持的sun.misc包。关于这个讨论中的问题，现在需要关注的是，它将来仅限于通过Jigsaw项目的JDK模块来访问。

Unsafe包含以下几类操作：

• 线程锁定
• 线程parking和unparking
• volatile访问
• native比较和交换
• 直接内存访问和分配
• 声明式异常

由于这些方法在很大程度上是Java中唯一可以访问这类特性的方法，所以该库广泛应用于JDK及许多第三方库中。

已经有一个名为Variable Handles的方案，可以提供部分内存访问和volatile访问特性，但目前为止，Unsafe的其它功能仍有待晋升为一等公民。

高性能社区似乎很高兴看到事情确定了下来。

Hazelcast的Christoph Engelbert告诉InfoQ：

对于新策略所涉及的、关于sun.misc.Unsafe及其它私有API的暴露、移除或弃用，我非常赞赏。对于由那些广泛应用的私有API所造成的不幸状况，Hazelcast和我本人，我们都认为这可能是最好的解决方案。

Ben Cotton是Mechanical Sympathy低延迟社区论坛的一名活跃分子，他告诉InfoQ：

对于编写本地“大数据”实现，如今的Java应用程序开发人员需要真正的补救措施。当前，Java虽然支持NIO库，但却没有提供一个比2gb（一次调用）更好的API用于本地内存分配。Java 9用一个受支持的API替换了sun.misc.Unsafe，而且该API还有助于大数据应用程序开发。对此，我非常高兴。

InfoQ曾试图联系Oracle进行确认，但他们拒绝置评。

查看英文原文：Oracle Carving Strategy for Unsafe Library