sun.misc.Unsafe是否在JDK9中公开？

我刚刚尝试了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); 

那么，使用Unsafe启动JDK9是否“安全”？ 它现在是公共官方API吗？

Answer 1

这是一个很好的解释：

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

如何处理Java 9中的sun.misc.Unsafe？ 一方面说，这只是一个糟糕的旧时代，应该被摆脱的可怕的黑客; 另一方面说，它的大量使用是造成Java在基础设施领域崛起的原因，而流行的工具仍然需要它。 问题是，双方都是对的。 …

Reinhold在OpenJDK邮件列表上写道，建议在定义和使用它们的模块中封装不受支持的内部API，包括sun.misc.Unsafe。 该提议现在是正式的Java增强提议（JEP）。 本周发布的JEP 260（“封装大多数内部API”）旨在“默认情况下使大多数JDK的内部API无法访问，但是可以访问一些关键的，广泛使用的内部API，直到所有或大多数人都支持替换。function“。

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

Answer 2

@ paulsm4的解释足以知道是否进一步使用它。

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

---

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

用处

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

---

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

分类

以上指定的JDK内部API分为两大类： –

• 非关键内部API ，似乎不是由JDK之外的代码使用，或者仅为了方便而被外部代码使用。

• 关键的内部API ，提供在JDK本身之外实现（例如， sun.misc.Unsafe ）很难（如果不是不可能的话）的关键function。

---

如果有人正在迁移已经使用Unsafe代码，但最终还是计划离开呢？

sun.misc.Unsafe

它是未在JDK 9中封装的那些关键内部API之一，因为在同时大多数其他API被封装或弃用以在将来的版本中被删除时，JDK 8中不存在受支持的替换。

sun.misc.Unsafe是否在JDK9中公开？

• 用法

  目前，为了访问关键的内部API，例如Unsafe ，需要在jdk.unsupported模块上定义一个依赖项，该模块专门为此目的定义：

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

➜ 尽管它可以回答你的问题，你甚至不会发现这个模块的记录 ，可能是为了限制消费者使用它，而且显然是避免让它“公开”的标志。

• 移民

  Unsafe类中的许多方法的function已通过Variable Handles _{JEP 193提供} 。