某天，报警系统提示某台机器上部署的一个服务突然无法访问。第一反应是登录机器查看日志，因为服务可能因内存溢出（oom）而崩溃。在机器的日志中发现了如下信息：
nio handle failed java.lang.OutOfMemoryError: Direct buffer memory at org.eclipse.jetty.io.nio.xxxxat org.eclipse.jetty.io.nio.xxxx at org.eclipse.jetty.io.nio.xxxx
这些日志表明确实发生了OOM，并且问题出在Direct buffer memory（直接内存或堆外内存）上。日志中还显示了一大堆与Jetty相关的调用栈。仅凭这些日志，我们可以分析OOM的原因。
Direct buffer memory是指JVM堆内存之外的一块内存空间，不是由JVM直接管理，但Java代码可以通过NIO使用这些内存。这些内存由操作系统直接管理。Jetty作为一个JVM进程，运行我们编写的系统流程：
这次的OOM是由Jetty在使用堆外内存时引起的。我们可以推测，Jetty可能一直在使用堆外内存，而当堆外内存空间不足时，无法再分配更多的堆外内存，从而导致OOM。
立即学习“Java免费学习笔记（深入）”；
Jetty不停使用堆外内存：
解决OOM的底层技术：Jetty是用Java编写的，那么它是如何通过Java代码申请堆外内存的？这些堆外内存空间又如何释放呢？这涉及到Java的NIO底层。
JVM的性能优化相对来说较为容易，但解决OOM问题，尤其是那些不是简单地由代码中不断创建对象引起的问题，需要扎实的技术。
堆外内存是如何申请和释放的？在Java代码中，要申请使用一块堆外内存空间，可以使用DirectByteBuffer类。通过这个类构建一个DirectByteBuffer对象，这个对象本身位于JVM堆内存中，但在构建这个对象的同时，会在堆外内存中划出一块与之关联的内存空间。
因此，分配堆外内存的基本思路就是这样的。
当你的DirectByteBuffer对象无人引用，成为垃圾后，就会在某次Young GC（YGC）或Full GC时被回收。只要回收一个DirectByteBuffer对象，就会释放其关联的堆外内存：
那么为什么还会出现堆外内存溢出？如果创建了很多DirectByteBuffer对象，占用了大量的堆外内存，而这些DirectByteBuffer对象又没有被GC线程回收，那么这些内存就不会被释放。当堆外内存都被大量的DirectByteBuffer对象占用时，再想使用额外的堆外内存就会导致OOM！
在高并发的情况下，创建过多的DirectByteBuffer对象，占用大量的堆外内存，再继续使用堆外内存时，就会OOM。但显然，该系统不是这种情况。
通过jstat观察线上系统的运行情况，结合日志查看一些请求的处理耗时，分析过往的GC日志，以及查看系统各个接口的调用耗时，我们得出了以下分析思路：
首先，查看接口调用耗时，系统的并发量不高，但每个请求的处理时间较长，平均每个请求需要1秒。
然后，通过jstat发现，随着系统的不断调用，会持续创建各种对象，包括Jetty本身不断创建DirectByteBuffer对象来申请堆外内存空间，直到Eden区满，就会触发YGC：
但在进行GC的一瞬间，可能有的请求还没有处理完，此时就有不少DirectByteBuffer对象处于存活状态，还没有被回收。当然，之前一些请求可能已经处理完毕，它们对应的DirectByteBuffer对象就可以被回收了。
此时，肯定会有一些DirectByteBuffer对象以及一些其他对象处于存活状态，需要转移到Survivor区。记得该系统上线时，内存分配极不合理，只给了年轻代一两百兆，而老年代却分配了七八百兆，导致年轻代中的Survivor区只有10兆。因此，往往在YGC后，一些存活的对象（包括了一些DirectByteBuffer）会超过10兆，无法放入Survivor区，直接进入Old区：
这样反复执行这个过程，导致一些DirectByteBuffer对象慢慢进入Old区，老年代中的DirectByteBuffer对象越来越多，而且这些DirectByteBuffer都关联了大量的堆外内存：
这些老年代中的DirectByteBuffer实际上很多都是可以回收的状态了，但因为老年代一直没有塞满，所以没有触发Full GC，也就自然不会回收老年代中的这些DirectByteBuffer。当然，老年代中这些没有被回收的DirectByteBuffer就一直关联占据了大量的堆外内存空间！
直到最后，当你想要继续使用堆外内存时，所有堆外内存都被老年代中大量的DirectByteBuffer给占用了，虽然它们可以被回收，但是因为始终没有触发老年代的Full GC，所以堆外内存也始终无法被回收掉。最终导致OOM！
有人可能会问，Java NIO怎么看起来这么笨拙？Java NIO难道没有考虑过会发生这种情况吗？
Java NIO确实考虑到了！它知道可能很多DirectByteBuffer对象可能没人用了，但因为未触发GC就导致它们一直占据堆外内存。Java NIO做了如下处理：每次分配新的堆外内存时，都会调用System.gc()，提醒JVM主动执行GC，去回收掉一些垃圾没人引用的DirectByteBuffer对象，释放堆外内存空间。
只要能触发GC去回收掉一些没人引用的DirectByteBuffer，就会释放一些堆外内存，自然就可以分配更多对象到堆外内存。但因为我们在JVM设置了：
-XX:+DisableExplicitGC
导致System.gc()不生效，因此导致OOM。
最终的优化方案如下：
- 合理分配内存，给年轻代更多内存，让Survivor区域有更大的空间。
- 移除-XX:+DisableExplicitGC这个限制，让System.gc()生效。
优化后，DirectByteBuffer一般就不会不断进入老年代了。只要它停留在年轻代，随着Young GC就会正常回收释放堆外内存。
只要移除-XX:+DisableExplicitGC限制，Java NIO发现堆外内存不足了，自然会通过System.gc()提醒JVM去主动垃圾回收，回收掉一些DirectByteBuffer，进而释放堆外内存。
