我有一个8GB RAM的Linux机器上运行4个tomcat服务器。 其中一个设置为3000MB内存（jvm -Xms和-Xmx设置），其他设置为1500MB。 交换分区也被设置为8Gigs。 当我启动这些服务器时，交换文件的使用率很低。 但是在一段时间内，在某个/所有服务器处于高峰期的特定时间，交换使用率开始增加。 这是一个典型的萨尔输出。
kbmemfree kbmemused％memused kbbuffers kbcached kbswpfree kbswpused ％swpused kbswpcad
48260 8125832 99.41 196440 2761852 7197688 1190912 14.20 316044
75504 8098588 99.08 198032 2399460 7197688 1190912 14.20 316032
它显示目前使用14.2％的交换。 有趣的是这个％从来没有减less 。 它继续增加，达到30-40％ 。 我们每周重新启动服务器。
我会假设％swpused在高峰期间增加，在低活动期间下降。或者至less保持不变。 这看起来像交换空间永远不会被操作系统回收..
free：free -m使用空闲共享缓冲区的cachingmem：7982 7937 45 0 32 2088 – / + buffers / cache：5816 2166 Swap：8191 1163 7028
所以至less有2克免费的拉姆。 所以问题是为什么交换空间继续增加而不被操作系统回收？ 或者如何debugging这个弄清楚什么是hapenning ..
如果将信息换出到光盘，然后再回读到内存中，则通常会在交换区域中保留信息，直到交换空间不足。 这意味着，如果稍后需要将相同的信息换出并且没有改变，则操作系统可以从分配的RAM中删除页面，而不需要写入任何节省光盘的时间。
分配给已经被读回内存的东西的交换也将被释放
在/proc/meminfo查找一个名为“SwapCached”的行。 此条目统计在RAM和交换分区中find的页面。 例如，随机挑选一个小型虚拟机，我的一个虚拟机/proc/meminfo虚拟文件显示：
SwapTotal: 698816 kB SwapFree: 624520 kB SwapCached: 17232 kB
表明已经分配了74268K的交换空间，但是那些17232K的页面当前也被映射到了RAM中（如果空间被别的东西需要的话，可以立即从swap中取消分配）。
毫无疑问，这些页面会被放置在很久以前被换掉的地方，从此以后再也没有被使用过。 内核将不会从交换中重新加载页面，只是因为有一些空闲的RAM将其读回，因为空闲的RAM可能会更好地用于caching或缓冲区 – 写入交换的页面通常只有在下次需要时才会被重新读取。
如果你想清除什么是交换，只要你有足够的免费和/或可释放的（即免费+caching+缓冲区（减less那些部分的C + B计数是不可自由的RightThisInstant）），只要把它closures，然后再次用swapoff -a && swapon -a 。
当然，你也可能在某处发生内存泄漏，但这不是你所看到的行为的唯一解释。
基本上，你不需要关心这个。 重要的是要知道有多lessIO进入交换（查看“vmstat”命令）。 有更多的东西在交换没有任何成本。 唯一的成本是把东西放在交换（页面中）或把它拿出（页面输出）。 所以操作系统让交换增长是完全合理的。
只要你有可用的交换空间，就不需要os来释放交换空间。 当没有剩余空间时它将被释放。 当你遇到这种情况时，你肯定有问题。
没有办法确定这是否会最终成为一个问题，除非您运行一个服务器足够长的时间来查看是否成为问题。
基本上，操作系统将交换不被使用的东西，随时保持一些内存空闲，以防一个新的程序开始。 交换空间在需要之前不会被释放，这意味着您可以使用100％交换空间并且没有性能问题。 要担心的是如果这是由内存泄漏造成的。 这不一定是内存泄漏，但可能是。
Java不容易出现内存泄漏，但特别是在复杂的应用程序中可能会发生这种情况。