看完这篇文章你还敢说你懂JVM吗？

前三项加起来已经560m，因此可以断定Linux物理内存不够使用。

细心的人会发现，引言中给出两个服务器，一个SWAP最多占用了2.16g，另外一个SWAP最多占用了871m;但是，似乎我们的内存缺口没有那么大。事实上，这是由于SWAP和GC同时进行造成的，从下图可以看到，SWAP的使用和长时间的GC在同一时刻发生。

SWAP和GC同时发生会导致GC时间很长，JVM严重卡顿，极端的情况下会导致服务崩溃。原因如下：JVM进行GC时，时需要对相应堆分区的已用 内存进行遍历;假如GC的时候，有堆的一部分内容被交换到SWAP中，遍历到这部分的时候就需要将其交换回内存，同时由于内存空间不足，就需要把内存中堆 的另外一部分换到SWAP中去;于是在遍历堆分区的过程中，(极端情况下)会把整个堆分区轮流往SWAP写一遍。Linux对SWAP的回收是滞后的，我 们就会看到大量SWAP占用。

上述问题，可以通过减少堆大小，或者增加物理内存解决。

因此，我们得出一个结论：部署Java服务的Linux系统，在内存分配上，需要避免SWAP的使用;具体如何分配需要综合考虑不同场景下JVM对Java永久代 、Java堆(新生代和老年代)、线程栈、Java NIO所使用内存的需求。

2.内存泄漏问题

另一个案例是，8g内存的服务器，Linux使用800m，监控进程使用600m，堆大小设置4g;系统可用内存有2.5g左右，但是也发生了大量的SWAP占用。

分析这个问题如下：

(1)在这个场景中， Java永久代 、Java堆(新生代和老年代)、线程栈所用内存基本是固定的，因此，占用内存过多的原因就定位在Java NIO上。

(2)根据前面的模型，Java NIO使用的内存主要分布在Linux内核内存的System区和PageCache区。查看监控的记录，如下图，我们可以看到发生SWAP之前，也就是 物理内存不够使用的时候，PageCache急剧缩小。因此，可以定位在System区的Java NIO Buffer发生内存泄漏。

(3)由于NIO的DirectByteBuffer需要在GC的后期被回收，因此连续申请DirectByteBuffer的程序，通常需要调用 System.gc()，避免长时间不发生FullGC导致引用在old区的DirectByteBuffer内存泄漏。分析到此，可以推断有两种可能的 原因：第一，Java程序没有在必要的时候调用System.gc();第二，System.gc()被禁用。

(4)最后是要排查JVM启动参数和Java程序的DirectByteBuffer使用情况。在本例中，查看JVM启动参数，发现启用了-XX:+DisableExplicitGC导致System.gc()被禁用。

四、总结

本文详细分析了Linux与JVM的内存关系，比较了一般进程与JVM进程使用内存的异同点，理解这些特性将对Linux系统内存分配、JVM调优、Java程序优化有帮助。限于篇幅关系仅仅列举两个案例，希望起到抛砖引玉的作用。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!