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

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

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

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

例子

VM "intrinsification." ie CAS (Compare-And-Swap) used in Lock-Free Hash Tables eg:sun.misc.Unsafe.compareAndSwapInt it can make real JNI calls into native code that contains special instructions for CAS read more about CAS here http://en.wikipedia.org/wiki/Compare-and-swap The sun.misc.Unsafe functionality of the host VM can be used to allocate uninitialized objects and then interpret the constructor invocation as any other method call. One can track the data from the native address.It is possible to retrieve an object’s memory address using the java.lang.Unsafe class, and operate on its fields directly via unsafe get/put methods! Compile time optimizations for JVM. HIgh performance VM using "magic", requiring low-level operations. eg: http://en.wikipedia.org/wiki/Jikes_RVM Allocating memory, sun.misc.Unsafe.allocateMemory eg:- DirectByteBuffer constructor internally calls it when ByteBuffer.allocateDirect is invoked Tracing the call stack and replaying with values instantiated by sun.misc.Unsafe, useful for instrumentation sun.misc.Unsafe.arrayBaseOffset and arrayIndexScale can be used to develop arraylets,a technique for efficiently breaking up large arrays into smaller objects to limit the real-time cost of scan, update or move operations on large objects http://robaustin.wikidot.com/how-to-write-to-direct-memory-locations-in-java

更多的参考资料在这里- http://bytescrolls.blogspot.com/2011/04/interesting-uses-of-sunmiscunsafe.html

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

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

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.

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

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

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