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

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

使用它来有效地访问和分配大量的内存，例如在您自己的体素引擎中!(例如《我的世界》风格的游戏。)

In my experience, the JVM is often unable to eliminate bounds-checking in place you truly need it. For example, if you're iterating over a large array, but the actual memory access is tucked underneath a non-virtual* method call in the loop, the JVM may still perform a bounds check with each array access, rather than once just before the loop. Thus, for potentially large performance gains, you can eliminate JVM bounds-checking inside the loop via a method which employs sun.misc.Unsafe to access the memory directly, making sure to do any bounds-checking yourself at the correct places. (You are gonna bounds check at some level, right?) *by non-virtual, I mean the JVM shouldn't have to dynamically resolve whatever your particular method is, because you've correctly guaranteed that class/method/instance are some combination of static/final/what-have-you.

对于我自己开发的体素引擎来说，这在块生成和序列化期间(在我同时读取/写入整个数组的低位置)带来了显著的性能提升。结果可能会有所不同，但如果缺乏界限消除是您的问题，那么这将解决它。

There are some potentially major problems with this: specifically, when you provide the ability to access memory without bounds-checking to clients of your interface, they will probably abuse it. (Don't forget that hackers can also be clients of your interface... especially in the case of a voxel engine written in Java.) Thus, you should either design your interface in a way such that memory access cannot be abused, or you should be extremely careful to validate user-data before it can ever, ever mingle with your dangerous interface. Considering the catastrophic things a hacker can do with unchecked memory access, it's probably best to take both approaches.

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

堆外集合对于分配大量内存并在使用后立即释放内存而不受GC干扰可能很有用。我基于sun.misc.Unsafe编写了一个用于处理堆外数组/列表的库。

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

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

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