转:http://blog.csdn.net/zhouhl_cn/article/details/6573213
创建Buffer对象时,可以选择从JVM堆中分配内存,也可以OS本地内存中分配,由于本地缓冲区避免了缓冲区复制,在性能上相对堆缓冲区有一定优势,但同时也存在一些弊端。
两种缓冲区对应的API如下:
- JVM堆缓冲区:ByteBuffer.allocate(size)
- 本地缓冲区:ByteBuffer.allocateDirect(size)
从堆中分配的缓冲区为普通的Java对象,生命周期与普通的Java对象一样,当不再被引用 时,Buffer对象会被回收。而直接缓冲区(DirectBuffer)为本地内存,并不在Java堆中,也不能被JVM垃圾回收。由于直接缓冲区在 JVM里被包装进Java对象DirectByteBuffer中,当它的包装类被垃圾回收时,会调用相应的JNI方法释放本地内存,所以本地内存的释放 也依赖于JVM中DirectByteBuffer对象的回收。
由于垃圾回收本身成本较高,一般JVM在堆内存未耗尽时,不会进行垃圾回收操作。我们知道在32位机器上,每个进程的最大可用内存为4G,用户可用 内存在大概为3G左右,如果为堆分配过大的内存时,本地内存可用空间就会相应减少。当我们为堆分配较多的内存时,JVM可能会在相当长的时间内不会进行垃 圾回收操作,从而本地内存不断分配,无法释放,最终导致OutOfMemoryError。
由此可见,在使用直接缓冲区之前,需要做出权衡:
- 堆缓冲区的性能已经相当高,若无必要,使用堆缓冲区足矣。若确实有提升性能的必要时,再考虑使用本地缓冲区。
- 为JVM分配堆内存时,并不是越大越好,堆内存越大,本地内存就越小,根据具体情况决定,主要针对32位机器,64位机器上不存在该问题。
-------------------------------------------------
转:http://www.raychase.net/1526
使用堆外内存
有时候对内存进行大对象的读写,会引起JVM长时间的停顿,有时候则是希望最大程度地提高JVM的效率,我们需要自己来管理内存(看起来很像是 Java像C++祖宗的妥协吧)。据我所知,很多缓存框架都会使用它,比如我以前使用过的EhCache(给它包装了个酷一点的名字,叫 BigMemory),以及现在项目中的Memcached。在nio以前,是没有光明正大的做法的,有一个work around的办法是直接访问Unsafe类。如果你使用Eclipse,默认是不允许访问sun.misc下面的类的,你需要稍微修改一下,给Type Access Rules里面添加一条所有类都可以访问的规则:
在使用Unsafe类的时候:
1
|
Unsafe f = Unsafe.getUnsafe();
|
发现还是被拒绝了,抛出异常:
1
|
java.lang.SecurityException: Unsafe
|
正如Unsafe的类注释中写道:
Although the class and all methods are public, use of this class is limited because only trusted code can obtain instances of it.
于是,只能无耻地使用反射来做这件事;
1
2
3
4
|
Field f = Unsafe.
class
.getDeclaredField(
"theUnsafe"
);
f.setAccessible(
true
);
Unsafe us = (Unsafe) f.get(
null
);
long
id = us.allocateMemory(
1000
);
|
其中,allocateMemory返回一个指针,并且其中的数据是未初始化的。如果要释放这部分内存的话,需要调用freeMemory或者 reallocateMemory方法。Unsafe对象提供了一系列put/get方法,例如putByte,但是只能一个一个byte地put,我不 知道这样会不会影响效率,为什么不提供一个putByteArray的方法呢?
从nio时代开始,可以使用ByteBuffer等类来操纵堆外内存了:
1
|
ByteBuffer buffer = ByteBuffer.allocateDirect(numBytes);
|
像Memcached等等很多缓存框架都会使用堆外内存,以提高效率,反复读写,去除它的GC的影响。可以通过指定JVM参数来确定堆外内存大小限制(有的VM默认是无限的,比如JRocket,JVM默认是64M):