CMS GC会不会回收Direct ByteBuffer的内存

微信上有同窗（也是同事）发消息问我这个问题，回答是：Oracle JDK 6u32前的版本不会。

Direct ByteBuffer是在Java Heap外分配内存，NIO等东西里使用的比较多，但Direct ByteBuffer分配出去的内存其实也是由GC负责回收的，而不像以前一篇文章里的Unsafe是彻底自行管理的，Hotspot在GC时会扫描Direct ByteBuffer对象是否有引用，如没有则同时也会回收其占用的堆外内存，但不幸的是在6u32前的版本里，CMS GC有bug会致使可能回收不掉，具体的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模块等这些是须要占用堆外空间的。