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