如何判断内存是否泄露及何处泄露

开辟者大年夜赛路演 | 12月16日，技巧立异，北京不见不散

内存泄漏为什么不轻易断定

Data是已经初始化的全局和静态变量。

在机能问题琅绫擎，内存有没有泄漏？如不雅有泄漏，是哪里泄漏了？这两个问题是异常难断定和定位的。甚至有厂商对内存是否健康的评判就是：下次体系重启之前，应用能正常运行。换句话说，有内存泄漏找不出来也没紧要，按期重启一下办事器，并且在临盆情况，切实其实有些企业是这么干的。

CPU如不雅应用率异常，可以查哪个过程中的哪个函数占用CPU多，响应的，内存也可以查哪个过程占内存多。为什么内存问题不像CPU问题那么轻易定位？

内存泄漏是指应用内存完成后没有释放，内存增长并不克不及分辨增长出来的内存是过程真正要用的，照样过程泄漏出来的。而CPU的┞芳用是瞬时的、肯定的，不存在某个过程申请了CPU占着不消的情况。

在一个评论辩论组里，有人提问：对一个基于Java的Web体系进行压力测试，如不雅虚拟用户数大年夜峰值下滑的同时，内存占用率却保持在峰值不变，是否能得出Java法度榜样存在内存泄漏的问题？

答复是否定的，原因如下：

起首，内存占用率指的是什么内存的┞芳用率？

在不合的OS上有不合的内存治理机制，比如AIX上，我们最存眷是计算内存，但如不雅内存应用率指的是计算内存+非计算内存的话，即使内存占用率上升也解释不了太多问题。再比如Linux上，我们最存眷是active内存，如不雅内存应用率指的是active+buffer+cache，即使内存占用率上升也解释不了太多问题。

第二，其他过程的干扰

操作体系上运行的过程千切切，内存不降低，可能是其他应用/体系过程对内存的应用，应具体分辨是哪个过程占据了内存。是以考察是否有内存泄漏应存眷的是指定过程有没有内存增长，如许比较轻易清除干扰。不过，查看过程的Data Segment也只能查看这个过程应用的一部分内存，而这个过程应用的Shared Memory Segment则不在这个指标中，但同样须要存眷（内存是分段的（Segment），每个段都是自力的，有各自的度量读数）

第三，过程池的原因

假如只存眷计算内存（AIX），如不雅办事端的应用是一个100个过程的过程池，应用刚启动的时刻没有客户端的连接进来，是以没有启动任何过程，跟着客户连接的增多，100个过程一切启动，并常驻内存；再假如这些过程应用的内存是分派好不变的，那么内存占用率保持在峰值不变，是很正常的表示。

CICS琅绫擎也有过程常驻内存的概念。常驻内存后，过程不会掉落下去，是以没有创建、烧毁过程的开销。

第四，JVM内存治理的原因

如不雅不是Java法度榜样，内存不降低甚至内存上升，也有上述的多种原因，何况这是Java法度榜样，存在一个JVM内存治理机制的原因。

我们曾经碰到如许一个案例。对某Linux办事器上的某应用进行压力测试，在一周的测试过程中，发明内存赓续增长。尽管办事器上天天准时清理内存（如下），但总趋势仍然是内存增长。

备注：drop_caches是清理无用的cache，对于dirty状况的是不清理的，直到dirty的内存被写入磁盘。但如不雅用sync操作把dirty的内存flush稻磁逄中，后续的drop_caches将释放更多的内存。

后续我们就发明，这是JVM内存治理机制造成的内存泄漏假象。该体系在测试过程中Java full GC（全量垃圾收受接收）没有被调起，老年代的内存没法被释放。固然应用应用的内存并没有跨越JVM设定的heap大年夜小，但大年夜Linux内存监控的指标上看，active内存是赓续增长的。

为什么full GC没有被调起呢？这个场景下，老年代内存的增长会异常迟缓，几天内都不会达到触发full GC的标准，乃至出现内存应用量赓续增长不收受接收的现象。并且，这个Java应用是一个自力的Java法度榜样，并没有运行在应用中心件上，是以没有中心件帮它做合理的GC策略，而应用本身也没有去调起full GC。

后经调剂应用，主动调起full GC，内存增长问题获得解决。

第五，本应用其他逻辑的干扰

也许这个应用是个接收客户端数捷报送并进行ETL处理的法度榜样，办事端的应用在收到客户端的数据后，开端启动其他过程/线程/模块去做后续处理，后续处理须要分派内存。

持续最初的问题，回到那个基于Java的Web体系，如不雅虚拟用户数大年夜峰值下滑到0，内存占用率却持续上扬，是否能得出Java法度榜样存在内存泄漏的问题？

答复仍然是否，可能的原因照样膳绫擎那几条。

总而言之，内存泄漏是异常难断定的事，须要长时光的测试才能获得猜测性结论。

谁占用的内存多

起首找到哪个应用或哪个过程占用的内存多。

1、物理内存占用

Nmon sheet

例2：Nmon中的PgIn/PgOut、topas中的PageIn/PageOut是指对文件体系的换页，而vmstat中的pi/po是对Paging Space的换页，而topas P中过程的PAGE SPACE是指过程的Data Segment。

根据经验，nmon的top sheet- Memory by command最直不雅，也最轻易直接看出哪个过程消费的内存资本多。