JDK 6u32前的版本 Direct ByteBuffer 的bug

Oracle JDK 6u32前的版本不会。

Direct ByteBuffer是在Java Heap外分配内存，NIO等东西里使用的比较多，但Direct ByteBuffer分配出去的内存其实也是由GC负责回收的，而不像之前一篇文章里的Unsafe是完全自行管理的，Hotspot在GC时会扫描Direct ByteBuffer对象是否有引用，如没有则同时也会回收其占用的堆外内存，但不幸的是在6u32前的版本里，CMS GC有bug会导致可能回收不掉，具体的bug id为 7112034，http://bugs.sun.com/view_bug.do?bug_id=7112034 ，在链接的Backport信息里，可以看到这个bug是在hotspot 20.7的版本里修复的（hotspot的版本号通过java -version的最后一行Java Hotspot Version之类的可以看到），6u32带的就是这个版本，所以6u32是会回收的。

回收不掉的情况下会造成的问题是明明已经不用了，但堆外内存仍然被消耗掉，悲惨的情况下可能会导致堆外内存耗光。

Direct ByteBuffer除了上面这个bug可能造成堆外内存耗光外，还有一种场景也可能会造成堆外内存耗光，如Direct ByteBuffer对象晋升到了Old区，那这个时候就只能等Full GC触发（CMS GC的情况下等CMS GC），因此在Direct ByteBuffer使用较多，存活时间较长的情况下，有可能会导致堆外内存耗光（因为Direct ByteBuffer本身对象所占用的空间是很小的）。

对于上面这种类型的应用，最好是在启动参数上增加-XX:MaxDirectMemorySize=x[m|g]，例如-XX:MaxDirectMemorySize=500m

这个参数默认的大小是-Xmx的值（在没设置MaxDirectMemorySize参数的情况下，用jinfo -flag等方式会看到默认值是-1，但VM.maxDirectMemory这个方法里发现是-1，则会以-Xmx作为默认值），此参数的含义是当Direct ByteBuffer分配的堆外内存到达指定大小后，即触发Full GC（这段逻辑请见Bits.reserveMemory的代码），如Full GC后仍然分配不出Direct ByteBuffer需要的空间，则会报OOM错误：
java.lang.OutOfMemoryError: Direct buffer memory

因为上面所说的状况，如碰到堆外内存占用较多的场景，可以尝试强制执行Full GC（强制的方法为执行jmap -histo:live）看看，多执行一两次，如堆外内存下降的话，很有可能就是Direct ByteBuffer造成的，对于这种情况，通常加上上面的启动参数就可解决。

很多情况下，我们会看到Java进程占用的内存超过-Xmx的大小，原因就是类似Direct ByteBuffer、Unsafe、GC、编译、自己写的JNI模块等这些是需要占用堆外空间的。