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