一个java程序的virtual memory 和 resident memory

最近吃了virtual memory的苦头，一直接到报告说我们的产品时不时会重启，并且报告说是“使用的memory超过了5G”。

重启是我们产品的机制，我们会监控内存，超过一定限度会进行GC并重启应用，可是超过5G这也太夸张了，而且报告出状况的环境都没有多大的负载。这个问题一直被认为是内存泄露，苦于无法重现一直无法解决，最近忽然在一个客户的环境中重现了，赶紧研究！

最终发现我们的监控机制是有问题的：代码是这样判断的, 当 virtual memory > 5 * Xmx（java option） 就会重启, 看起来没错， 但是在使用free命令查看应用运行前后的内存size却发现实际使用的内存并不多，并且剩余内存一直保持在一个比较稳定的数字，并没有持续下降的情况。这样看来内存泄露实际上不存在。那是什么原因导致应用启动时 virtual memory 的使用有那么大的数值呢？

无奈之后我开始关注virtual memory 这个值得意义，哇，问题出在这里，它的意义并不是我们想当然的那样，大相径庭！

virtual memory 在top命令的manpage是这样解释的：

o: VIRT  --  Virtual Image (kb)      The  total  amount  of  virtual  memory  used  by the task.  It      includes all code, data and shared libraries  plus  pages  that      have been swapped out.      VIRT = SWAP + RES.

就是说 virtual memory 不但是包括了代码数据还包括了共享库（对于java来说就是jar文件了），共享库不但包括正在使用的还包括了已经在SWAP中的。已经在SWAP中的其实就不是在内存中了，什么意思呢，就是说virtual memory 叫做虚拟内存，其实这个数值的一部分并不是physic的内存，而是磁盘空间。

更近一步解释：virtual memory 是所有处在virtual memory map 中的数据容量之和，一般来说没什么意义。

举个例子说吧：比如一个程序classpath中引用了10M的jar包，在程序中用到了十个10M的文件那么这个程序启动的时候 virtual memory会是多少呢？

程序本身的code + 程序本身的data + 10m(jars) + 10*10m(文件) + jre占用的空间， 这已经是个很大的数字了，但是实际上在程序启动时并不会将所有的都加载，即便加载了也很快会被swap出去， virtual memory 的数值其实就是个数字，实际中的耗费跟它没有任何关系。

所以在监控程序中使用virtual memory没有任何意义是错误的，那哪个数值表示实际使用的内存呢？

resident memory： the number of pages that are currently resident in RAM

它才是比较靠谱的内存使用值。

介绍一片文章，讲这个讲的太透了：

什么是virtual memory