使用堆外内存

使用堆外内存

有时候对内存进行大对象的读写，会引起JVM长时间的停顿，有时候则是希望最大程度地提高JVM的效率，我们需要自己来管理内存（看起来很像是Java像C++祖宗的妥协吧）。据我所知，很多缓存框架都会使用它，比如我以前使用过的EhCache（给它包装了个酷一点的名字，叫BigMemory），以及现在项目中的Memcached。在nio以前，是没有光明正大的做法的，有一个work around的办法是直接访问Unsafe类。如果你使用Eclipse，默认是不允许访问sun.misc下面的类的，你需要稍微修改一下，给Type
Access Rules里面添加一条所有类都可以访问的规则：



在使用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.

于是，只能无耻地使用反射来做这件事；

其中，allocateMemory返回一个指针，并且其中的数据是未初始化的。如果要释放这部分内存的话，需要调用freeMemory或者reallocateMemory方法。Unsafe对象提供了一系列put/get方法，例如putByte，但是只能一个一个byte地put，我不知道这样会不会影响效率，为什么不提供一个putByteArray的方法呢？

从nio时代开始，可以使用ByteBuffer等类来操纵堆外内存了：

像Memcached等等很多缓存框架都会使用堆外内存，以提高效率，反复读写，去除它的GC的影响。可以通过指定JVM参数来确定堆外内存大小限制（有的VM默认是无限的，比如JRocket，JVM默认是64M）：

对于这种direct buffer内存不够的时候会抛出错误：

千万要注意的是，如果你要使用direct buffer，一定不要加上DisableExplicitGC这个参数，因为这个参数会把你的System.gc()视作空语句，最后很容易导致OOM。

对于heap的OOM我们可以通过执行jmap -heap来获取堆内内存情况，例如以下输出取自我上周定位的一个问题：

可见堆内存都是正常的，重新回到业务日志里寻找异常，发现出现在堆外内存的分配上：

对于这个参数分配过小的情况下造成OOM，不妨执行jmap -histo:live看看（也可以用JConsole之类的外部触发GC），因为它会强制一次full GC，如果堆外内存明显下降，很有可能就是堆外内存过大引起的OOM。

对于堆外内存的使用率，可以使用rednaxelafx做的一个工具来查看：链接。

BTW，如果在执行jmap命令时遇到：

这个算是JDK的一个bug（链接），只要是依赖于SA（Serviceability
Agent）的工具，比如jinfo/jstack/jmap都会存在这个问题，但是Oracle说了“won’t fix”……

Ubuntu 10.10 and newer has a new default security policy that affects Serviceability commands. This policy prevents a process from attaching to another process owned by the same UID if the target process is not a descendant of the attaching process.

不过它也是给了解决方案的，需要修改/etc/sysctl.d/10-ptrace.conf：

如果你的操作系统不是Ubuntu，可以升级一下JDK的版本试试，我在RedHat上遇到过这样的问题，升级JDK版本以后解决了。

堆外内存泄露的问题定位通常比较麻烦，可以借助google-perftools这个工具，它可以输出不同方法申请堆外内存的数量。当然，如果你是64位系统，你需要先安装libunwind库。

最后，JDK存在一些direct buffer的bug（比如这个和这个），可能引发OOM，所以也不妨升级JDK的版本看能否解决问题。

转自：http://www.raychase.net/1526