在性能测试过程中，瓶颈犹如功能测试的bug，瓶颈的分析犹如bug的定位。性能测试工程师好比医生，看到病象，定位病因。性能瓶颈的定位更像庖丁解牛，层层解剖，最后定位问题之所在。下面分享一个内存泄漏的瓶颈分析。
病象：TPS波动非常大；狂打超时日志；偶尔有500错误。
看到这个现象，其实说明不了什么问题，就象人咳嗽，不一定是感冒，可能是上火，嗓子发炎。但是看到这个现象至少说明系统是有性能问题存在，我们就要进一步进行分析，看看问题到底在哪？用jconsole监控内存，发现内存使用如图1
<ignore_js_op>
图1
从图1中，我们可以很清晰的看到内存使用不正常，FGC非常频繁，差不多5分钟进行一次，而且内存回收不彻底，每次回收在1G左右徘徊。到这里我们已经可以定位是内存问题，导致了我们看到的TPS波动大，FGC频繁，超时严重等等一系列现象。
那么是谁吃了我的内存？？？
用简单的jstat命令查看系统GC情况，看到情况如图2所示
<ignore_js_op>
图2
在图2的绿色框标注，我们可以很清晰的看到进行一次FGC，内存只回收12%左右，回收很不彻底，而且FGC的时间持续5秒。内存回收不彻底，肯定是有些方法霸占了内存不释放，导致系统频繁FGC来进行回收。
那么谁是真正的凶手呢？？
用jmap 命令对内存使用进行分析，发现情况如图3所示
<ignore_js_op>
图3
通过FGC前后的内存使用进行比对，发现这三个方法快速占用内存从最少到最多，而且回收不掉，始终霸占着前几位。再通过其他工具分析，看看这三个是不是真正的凶手。
用MAT分析工具进行分析，图4所示
<ignore_js_op>
图4
这三个方法各占了内存使用的14%，那么问题就很清晰明朗了。这三个方法就是真正的凶手，调优就从这三个方法入手。
性能瓶颈的分析，犹如庖丁解牛，层层剖析。最终定位问题之所在。