对象的可用性似乎低于Java代码通常允许的级别。如果您正在编写一个高级应用程序，那么JVM将内存处理和其他操作从代码级别抽象出来，因此更容易编程。通过使用不安全库，您可以有效地完成通常由您完成的低级操作。

正如woliveirajr所述，“random()”使用Unsafe来播种，就像许多其他操作将使用Unsafe中包含的allocateMemory()函数一样。

作为程序员，你可能永远不需要这个库，但严格控制底层元素确实很方便(这就是为什么在主要产品中仍然有汇编代码和(在较小程度上)C代码的原因)

通过在一些代码搜索引擎中运行搜索，我得到了以下示例:

Java对象符号——使用它来进行更有效的数组处理，引用javadoc

类来获取对{@link Unsafe}对象的访问。{@link安全} 为了允许对数组进行有效的CAS操作，*是必需的。注意 {@link java.util.concurrent中的版本。原子}，例如{@link java.util.concurrent.atomic。AtomicLongArray}，需要额外的内存排序 这些保证在这些算法中通常是不需要的 在大多数处理器上都很昂贵。

SoyLatte - java 6 for osx javadoc excerpt

/** sun.misc的基类基于静态的不安全的FieldAccessors 字段。据观察，只有9种类型的 从反射代码的角度看字段:八个原语 类型和对象。使用不安全类而不是生成类 字节码节省内存和加载时间 动态生成的FieldAccessors。* /

SpikeSource

／* 通过线路发送的FinalFields ..如何解编和重新创建对象上 接收方?我们不想调用构造函数，因为它将为 最后一个字段。我们必须重新创建与发送端完全相同的最终字段。 太阳，杂项，不安全为我们做了这些。 * /

还有很多其他的例子，只要按上面的链接…

not safe.park()和not safe.unpark()用于构建自定义并发控制结构和协作调度机制。

我们使用Unsafe实现了数组、HashMaps、TreeMaps等大型集合。为了避免/最小化碎片，我们使用dlmalloc over unsafe的概念实现内存分配器。这帮助我们获得了并发性方面的性能。

I was recently working on reimplementing the JVM and found that a surprising number of classes are implemented in terms of Unsafe. The class is mostly designed for the Java library implementers and contains features that are fundamentally unsafe but necessary for building fast primitives. For example, there are methods for getting and writing raw field offsets, using hardware-level synchronization, allocating and freeing memory, etc. It is not intended to be used by normal Java programmers; it's undocumented, implementation-specific, and inherently unsafe (hence the name!). Moreover, I think that the SecurityManager will disallow access to it in almost all cases.

简而言之，它的存在主要是为了允许库实现者访问底层机器，而不必在某些类(如AtomicInteger native)中声明每个方法。在常规Java编程中不需要使用或担心它，因为重点是使其余的库足够快，从而不需要这种访问。

有趣的是，我甚至从未听说过这个类(这可能是一件好事，真的)。

我想到的一件事是使用Unsafe#setMemory将包含敏感信息的缓冲区归零(密码、密钥等)。您甚至可以对“不可变”对象的字段执行此操作(然后，我再次假设普通的反射也可以在这里执行此操作)。但我不是安全专家，所以对此持保留态度。