本文讲述了它在OpenHFT中的使用场景以及我希望在Java 9中看到哪些功能。如果希望访问大量内存的同时又不影响GC，就特别适合使用Unsafe。在进程间共享内存，同时又不希望引起显著的开销，在Java中就只有这么一种方法了。
分配及释放堆内存
public native long allocateMemory(); public native void freeMemory(long address);
你可以用这两个方法分配任何大小的堆内存。它不受Integer.MAX_VALUE字节的大小限制，返回给你的是原始内存，需要的话你可以进行边界检查。比如，Bytes.writeUTF(String)会计算编码的字符串的长度，检查是否容纳的下整个字符串，当然只做一次校验，不会每个字节都检查一遍。
java.lang里面也有一个类似的Cleaner类，DirectByteBuffer就用它来确保内存已经被释放了。不过这个类不太应该放到这么核心的地方。
访问原始内存
public native Xxx getXxx(Object, long offset); // intrinsic public native void putXxx(Object, long offset);// intrinsic
在这两组方法中，当访问的是堆外的内存时，Object是为空的，offset就是实际的地址。在把它们当作内部函数的JVM上，你可以只用一条机器指令就可以访问原始内存。这极大的提高了内存访问的效率。
这种访问方式的问题就是，你得自己去维护你数据结构里面各个字段的分布。java.lang库里的解决办法是，它让你定义getter和setter方法，然后它在运行时生成具体的实现。也就是说，不管对象是堆内还是堆外的，你就直接通过getter和setter来访问它们就好了。
线程安全地访问内存
public native Xxx getVolatileXxx(Object, long offset); // intrinsic public native void putOrderedXxx(Object, long offset); // intrinsic
有了这两组方法，你可以通过一个懒加载的集合来把一个字段模拟成volatile类型的。线程通过这个集合来设置值速度会更快，不过如果这个线程很快又读取值的话可能会读到旧的值。解决方法就是不要去读刚写完的值。
在进程中共享内存时，这两组方法尤其管用。
CAS操作
public native boolean compareAndSwapXxxx(Object, long offset, Xxx expected, Xxx setTo)
想创建一个堆外的锁，这组方法是少不了的。在进程间安全的共享数据的话，这也是最高效的一种方式。从我在Haswell处理器i7-4500上做的测试来看，同一机器上的两个进程间的通讯往返延迟的表现相当不错;
<table summary="日志级别">
<tbody>
<tr>
<td>TCP</td>
<td>- 9 micro-seconds.</td>
</tr>
<tr>
<td>FileLocks</td>
<td>- 5.5 micro-seconds.</td>
</tr>
<tr>
<td>CAS</td>
<td>- 0.12 micro-seconds.</td>
</tr>
<tr>
<td>Ordered write</td>
<td>- 0.02 micro-seconds.</td>
</tr>
</tbody>
</table>
堆对象的分配
public native Object allocateInstance(Class clazz);
当类反序列时，你当然希望类里面的值会恢复成序列前的样子。不过在现在的构造方法中，这个可能会有点小问题， JEP 187： Serialization 2.0中有提到过这个问题。一个解决方法就是彻底不使用构造方法来创建新对象。这说明你得充分信任你的数据正确性，好处就是它易于使用且不用关心到底用哪个构造方法来实例化对象。
结论
嵌入式的数据库由于没有额外的网络开销，在请求延迟方面是远优于分布式数据库的。我相信下一代低延迟的数据库不但能达到嵌入式数据库的性能，还能在进程间进行共享，同时它的更新和查询的响应时间都能在毫秒级以下。
Java没理由会不去实现它。对Java用户而言，本地接口的性能是最佳的，因为它不需要JNI，或者说是不需要进行Java和C之间的一层转化。
译者注：文章假定读者对Unsafe有一定的了解和认识，更详细的说明请关注 deepinmind或本博客的后续文章
文章同时发表于本人博客： deepinmind
更多文章请关注： Java译站