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编程中不需要使用或担心它，因为重点是使其余的库足够快，从而不需要这种访问。

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

基于对使用eclipse进行引用跟踪的Java 1.6.12库的简要分析，似乎Unsafe的每个有用功能都以有用的方式公开了。

CAS操作通过Atomic*类公开。 内存操作函数通过DirectByteBuffer公开 同步指令(park,unpark)通过AbstractQueuedSynchronizer公开，而AbstractQueuedSynchronizer又由Lock实现使用。

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

类不安全 用于执行低级、不安全操作的方法的集合。虽然类和所有方法都是公共的，但该类的使用是有限的，因为只有可信代码才能获得它的实例。

它的一种用法是在java.util.concurrent.atomic类中:

AtomicIntegerArray AtomicLongArray

为了有效地复制内存(至少对于短块，复制速度比System.arraycopy()快);由Java LZF和Snappy编解码器使用。它们使用'getLong'和'putLong'，这比逐字节复制要快;在复制16/32/64字节块时尤其有效。