性能测试之内存泄漏
关于内存泄漏，相信大家都不陌生，压力测试中经常会出现，本人近在做一个压力测试中着实体会了一下，上来分享分享。
内存泄露是指程序中间动态分配了内存，但是在程序结束时没有释放这部分内存，从而造成那一部分内存不可用的情况，重起计算机可以解决，但是也有可能再次发生内存泄露，内存泄露和硬件没有关系，它是由软件设计缺陷引起的。
以发生的方式来分类，内存泄漏可以分为4 类：
1.常发性内存泄漏。发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
2.偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境，偶发性的也许变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
3.一次性内存泄漏。发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块仅且一块内存发生泄漏。比如，在类的构造函数中分配内存，在析构函数中却没有释放该内存，所以内存泄漏只会发生一次。
4.隐式内存泄漏。程序在运行过程中不停的分配内存，但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏，因为终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天，几周甚至几个月，不及时释放内存也可能导致终耗尽系统的所有内存。所以，我们称这类内存泄漏为隐式内存泄漏。
本人近在对一个Http应用进行压力测试，发现被测试的对象进程在并发100 时内存占用达到20% ，当压力到达1000的时候，内存持续上升，达到60% ，后压力结束后，内存仍旧停留在60% 的使用率，然后重启了系统发现内存已经恢复了正常，于是在第二轮测试时再次不断加压，同时关注性能计数器中的如下指标：
Memory Available Bytes 是指剩余的可用物理内存，单位是兆字节（参考值：>=10% ）。表明进程当前可使用的内存字节数。
Memory Pages/sec 是表明由于硬件页面错误而从磁盘取出的页面数，或由于页面错误而写入磁盘以释放工作集空间的页面数。
ProcessPrivate Bytes 是指当前进程中运行的私有内存，如果此内存不断攀升，表示当前存在的内存泄漏，一般情况如果资源合理利用的话，该指标值波动比较平稳。
通过有效的监控以上计数器可以方便我们判断内存泄漏问题，同时需要开发人员配合进行内存查找，定位分析哪些程序存在内存泄漏。后通过开发人员的调试，问题很快定位了，确实有程序没有释放内存，后再次施压的结果是内存持续在一个值上下波动，一般参考值在20% 左右，不过这个根据具体的内存空间来定，当然如果可以更小好了，表明内存合理利用和分配。当然了，检测内存泄漏的方式很多，LoadRunner施压是可以结合响应时间的曲线图来监控也可。
从用户使用程序的角度来看，内存泄漏本身不会产生什么危害，作为一般的用户，根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积，这会终消耗尽系统所有的内存。从这个角度来说，一次性内存泄漏并没有什么危害，因为它不会堆积，而隐式内存泄漏危害性则非常大，因为较之于常发性和偶发性内存泄漏它更难被检测到。对于开发人员来说，熟悉java、C++ 等应该都了解，通常我们定义一些变量，或者实例化一些对象，比较常用是new 方法，然后通过delete方法进行销毁，如果定义的东西比较多了，也是想申请的内存空间多了，如果一旦没有合理的管理和消化，会忘记后做一些内存回收的处理，导致一些变量和实例对象没有处理掉，后在程序运行一段时间之后发现我们的内存不断在攀升，长时间下来积累了占用了大量的内存空间，导致其他进程无法获取到内存资源，无法去处理其他应用，后服务shut down ，等等之类情况都比较多见，不过这些也基本取决于开发人员的经验所致，在程序编写过程中合理的使用和管理内存是非常重要的，因为此类问题一般只有在性能测试中体现出来，功能测试是完全没有表现的迹象。
其实，内存泄漏问题多半在压力测试中出现也是源于程序编写过程中没有规范化管理所导致，开发人员需要结合内存监测工具来有效监控自己的程序，这样才会避免这些个低级的瓶颈出现，所以说性能测试只是为程序提供优化建议，而不应该成为帮助开发人员调试程序的一种手段。
