JDK9中sun.misc.Unsafe是否变为公共API？

Question

我刚试了一下JDK9，发现sun.misc.Unsafe不再包含本地方法，而是将它们委托给一些jdk.internal.misc.Unsafe，例如：

@ForceInline
public int getInt(Object o, long offset) {
    return theInternalUnsafe.getInt(o, offset);
}

最新版本看起来实际上像旧的sun.misc.Unsafe，但现在方法被注释了：

@HotSpotIntrinsicCandidate
public native void putObject(Object o, long offset, Object x);

那么，从JDK9开始使用Unsafe是“安全”的吗？它现在是公共官方API吗？

- Саша Данилин

Answer 1

@paulsm4的解释足以了解是否需要进一步使用。

长答案 ~ JEP 260：封装大多数内部API

---

为什么决定移除/弃用长期使用的API支持？

实用性

在模块化JDK_{JEP 200}中，通过利用模块系统_{JEP 261}限制访问JDK的非标准、不稳定和不受支持的API，这些API是JDK的内部实现细节，可以提高平台的完整性和安全性，因为许多这些内部API定义了特权、安全敏感操作。从长远来看，这个变化将减少JDK本身及其库和应用程序的维护者承担的成本，这些库和应用程序有意或无意地使用这些内部API。

---

是否计划封装所有内部API？

类别

JDK的上述内部API分为两个广泛的类别：

• 非关键内部API，它们似乎并未被用于JDK之外的代码中，或者仅被外部代码用于方便。

• 关键内部API，提供关键功能，如果不是在JDK本身内实现（例如sun.misc.Unsafe），则很难甚至不可能实现。

---

如果有人正在迁移已经使用Unsafe的代码，但最终计划摆脱它怎么办？

sun.misc.Unsafe

它是那些在JDK 9中未封装的关键内部API之一，因为在JDK 8中没有支持的替代品，同时大多数其他API都已封装或弃用以在未来版本中删除。

sun.misc.Unsafe在JDK9中变为公共API了吗？

• Usage

  Currently to access the critical internal API's such as Unsafe, one needs to define a dependency on the jdk.unsupported module which is defined specifically for the purpose:

  module jdk.unsupported {
      exports sun.misc;
      opens sun.misc;
      ...
  }
  

➜ 虽然这个模块可以回答您的问题，但您甚至无法找到此模块文档，很可能是为了限制消费者使用它，明显避免将其公开。

• 迁移

  Unsafe类中许多方法的功能已通过变量处理器 _{JEP 193}实现。

- Naman

Answer 2

这里有一个很好的解释：

https://adtmag.com/blogs/watersworks/2015/08/java-9-hack.aspx

对于Java 9中的sun.misc.Unsafe该怎么办呢？一方认为它只是来自早期的可怕黑客代码，应该被摒弃；另一方认为它广泛使用，是Java在基础设施空间和流行工具中崛起的功臣。问题在于，两边都是正确的。 ...

Reinhold在OpenJDK邮件列表上发文，建议将不支持的内部API（包括sun.misc.Unsafe）封装在定义和使用它们的模块中。该提议现已成为正式的Java Enhancement Proposals (JEP)。发布于本周的JEP 260（“Encapsulate Most Internal APIs”）旨在“默认情况下使大部分JDK的内部API不可访问，但保留一些关键、经常使用的内部API可访问，直到所有或大多数功能都有支持的替代品”。

简短的回答：不应该在任何新的应用程序开发中使用它。

- paulsm4

---

简短回答：你不应该使用它。 - user207421

不要故意使用它...但如果你偶然在其他代码中看到它，也不要惊慌失措 ;) - paulsm4