案例

一个网站为了实现客户端实时从服务端接收数据，使用了 CometD 1.1.1 作为服务端推送框架，服务器是 Jetty7.1.4，CPU i5，内存 4G，操作系统 32位Windows。

服务端常常抛出内存溢出异常，管理员把堆开到最大(32位系统最多到1.6G)，但问题依旧。

开着 jstat 观察，GC并不频繁，eden、survivor、老年代、永久代的内存都很正常，没有压力。

查看日志中有异常信息：

...

java.lang.OutOfMemoryError:null

...

at java.nio.DirectByteBuffer ...

原因

这是由 Direct Memory 不足引起的。

操作系统对每个进程能管理的内存是有限制的，32位windows的限制是2G，其中1.6G给了Java堆，但 Direct Memory 是不计入这 1.6G的，因此 Direct Memory 最大就是 0.4G。

垃圾回收时，虽然会对 Direct Memory 进行回收，但不像新生代、老年代那样，发现空间不足时就触发回收，只能等老年代满了之后 full gc 时，随便把 Direct Memory 清理一下，否则只能等抛出异常后进行catch，调用 System.gc()。

这个案例中使用了 CometD，有大量的 NIO 使用 Direct Memory，所以产生了这个问题。

总结

我们平时对堆比较关注，但一定要记得，除了堆之外，下面这些区域也会占用较多的内存，需要注意：

Direct Memory

可以通过 -XX:MaxDirectMemorySize调整大小，内存不足时抛出 OutOfMemoryError或者OutOfMemoryError:Direct buffer memory

线程堆栈

可通过 -Xss调整大小，内存不足时抛出 StackOverflowError(纵向无法分配，即无法分配新的栈帧)或者OutOfMemoryError:unable to create new native thread(横向无法分配，即无法建立新的线程)

Socket 缓存区

每个socket连接都有 receive 和 send 两个缓存区，分别占大约 37K 和 25K，连接多时占用的内存也很可观，如果无法分配，抛出异常 IOException: Too many open files 。