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

我自己没有使用过它，但我认为如果你有一个变量，只是偶尔被多个线程读取(所以你真的不想让它volatile)，你可以在主线程中写入它时使用putObjectVolatile，在从其他线程中进行罕见的读取时使用readObjectVolatile。

如果您需要替换当前使用它的某个类所提供的功能，则需要使用它。

这可以是自定义/更快/更紧凑的序列化/反序列化，一个更快/更大的缓冲区/可调整大小的ByteBuffer版本，或者添加一个原子变量，例如当前不支持的。

我曾经用它来处理所有这些问题。

它使用的一个例子是random方法，该方法调用不安全的方法来更改种子。

这个网站也有它的一些用途。

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

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

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