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

• 长回答~ JEP 260: Encapsulate Most Internal APIs *

为什么他们决定不再支持一个长期使用的API？
有用性
在 * The Modular JDKJEP 200 * 中，通过利用 * The Module SystemJEP 261 * 限制对 * 非标准、不稳定和不受支持的API（JDK* 的内部实现细节）* 的访问，可以提高平台的完整性和安全性，**因为许多这些内部API都定义了特权、安全敏感的操作。从长远来看，此更改将降低JDK本身以及库和应用程序维护人员承担的成本，无论这些库和应用程序是有意还是无意地使用这些内部API。
是否计划封装所有内部API？

类别

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

• • 非关键的内部API *，这些API似乎不被JDK外部的代码使用，或者被外部代码使用只是为了方便。
• • 关键的内部API *，这些API提供了在JDK本身之外很难（如果不是不可能）实现的关键功能（例如，sun.misc.Unsafe）。

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

它是JDK 9中未封装的关键内部API之一，因为JDK 8中不存在受支持的替换，而与此同时，大多数其他API都已封装或已弃用，将在未来的版本中删除。
Sun.Misc.Unsafe在JDK 9中公开了吗？

• • 用途 *

目前，要访问关键的内部API（如Unsafe），需要定义对jdk.unsupported模块的依赖关系，该依赖关系是专门为此目的定义的：

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

字符串

• 虽然它可以回答你的问题，但你不会发现这个模块甚至被记录下来，可能是为了限制消费者使用它，显然是为了避免它成为“公共”。*
  *迁移

Unsafe类中的许多方法的功能已通过 * Variable Handles JEP 193* 提供。

这里有一个很好的解释：
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）。（“封装大多数内部API”）旨在“使大多数JDK的内部API默认不可访问，但留下一些关键的，广泛使用的内部API可访问，直到其全部或大部分功能的支持替代品存在。
简短的回答：你不应该在你从头开始开发的任何新应用程序中使用它。