sun.misc.Unsafe，Spring和许多其他流行的库将会崩溃。然而，在Spring或Hibernate中没有对该类的静态引用。那么，这个说法是真的吗？Unsafe的引用，但是如果Oracle删除了该类，他们将更新所有引用，没有任何库会受到影响（除非他们直接使用Unsafe）。Mark Reinhold在JVM语言峰会2015上发表了一篇名为The Secret History and Tragic Fate of sun.misc.Unsafe的演讲。尽管这些演讲有很多免责声明，但您可以在10:23看到所提出的方法，这在JEP260中有描述。
总体思路是：
Unsafe API标记为过时以下是来自JEP260的相关文本（摘自2015年10月20日）：
在JDK 9中，我们提出以下措施：默认情况下封装所有非关键的内部API：定义它们的模块不会将其包导出供外部使用。（可以通过命令行标志在编译时和运行时访问这些API，除非这些API由于其他原因被修改或删除，否则只能作为最后的手段。）
以相同的方式和同样的最后手段封装具有支持替代品的JDK 8关键内部API。（支持替代品是指Java SE 8标准的一部分（即在java.*或javax.*包中），或者是JDK特定的，并用@jdk.Exported注释（通常在com.sun.*或jdk.*包中）。）
不封装JDK 8中不存在支持替代品的关键内部API，并弃用那些在JDK 9中存在支持替代品的API，目的是在JDK 10中对它们进行封装或甚至删除。
...
JDK 9中引入替代品的关键内部API将在JDK 9中被弃用，并在JDK 10中被封装或移除。
这个资源提供了对JDK 9及其功能的透彻理解。社区开始就Unsafe及其在Java未来中的地位展开讨论。给定的文档是社区应对JEP-260的努力，该提案建议隐藏一些内部API，但保留一些关键API，其中包括Unsafe。如从文档本身中提取的：
因此，总的来说，至少根据给定的 JEP，Unsafe 应该保留。建议在JDK 9中仍然可以访问的关键内部API是：
sun.misc.Cleaner
sun.misc.{Signal,SignalHandler}
sun.misc.Unsafe（现在此类中许多方法的功能可通过变量句柄（JEP 193）获得。）
sun.reflect.Reflection::getCallerClass（该方法的功能可能会以标准形式通过JEP 259提供。）
sun.reflect.ReflectionFactory
我尝试搜索了一下我目前正在工作的项目中Unsafe的使用情况，还有一些库可能会出现问题。Spring Framework (通过Objenesis，并提供备选方案)
Unsafe，但是Spring依赖于Objenesis，而Objenesis又依赖于Unsafe。Unsafe的依赖： https://github.com/easymock/objenesis/blob/master/main/src/main/java/org/objenesis/instantiator/sun/UnsafeFactoryInstantiator.javaUnsafe（通过Objenesis）来创建在未调用构造函数的情况下的类。