起因：最近在跟踪产品的性能问题，期间主要问题体现在JVM的内存回收问题，使用MAT工具进行JVM内存分析（也可对android 的应用内存分析）
问题描述：
1、部分后端服务在运行一段时间后会突然年老代会变为100%
2、部分后端服务定期出现年轻代GC情况，耗时超过2S
问题1解决步骤：
利用jmap指令（jmap -dump:format=b,file=文件名 PID）生成内存快照文件。文件名支持相对路径和绝对路径，PID指Java应用的进程ID，可通过JPS指令获取，在有些时候该指令无法直接生成内存快照，需要额外补充-f，原因会在稍后的文章中说明。
在官网下载MAT独立包（推荐64位，并修改MemoryAnalyzer.ini文件中的-Xmx，确保其值大于你的内存快照文件大小，否则MAT打开内存文件会报内存溢出），打开之前保存的内存快照文件
打开后，直接选择leak suspects选项（该选项表示MAT会自动帮我们分析内存泄漏最可能的类），分析完后类比下图（图片来自网络）
一般来说，该报告会告诉我们最可能泄露的类和相关实例，我们点进打开后，对Retained Heap最大的实例再点击选择outGoing references（当前对象，引用的外部对象），即可查看该实例中引用了哪些对象，一直没释放，从而导致该实例占了不少内存
根据步骤4基本就可以确认，究竟是哪些对象实例强引用未能释放，从而导致内存持续上涨直至频繁FGC，这时候就可以拉上开发的童鞋根据代码进行分析
回到问题的原点，这次的问题发生的原因是：多例模式下，大量的对象被加载到OSGI的核心容器中，从而导致大并发情况下，导致内存出现泄漏，最后内存溢出
问题2解决步骤：
分析步骤与问题1并无偏差，但奇怪的现象是生成的报告中任何对象的实例的大小都很小，且总和与实际的内存文件相差甚远
MAT默认是只分析reachable对象实例，所以在"Preferences=>Memory Analyzer"中勾选"Keep Unreachable Objects"，删除索引文件Dump同路径下的所有".index"，即可看到所有的对象，再根据上述步骤4进行分析
此时发现某个对象实例，其某个属性List无比庞大（size>10000）
后经与研发同事分析得知，某些查询动作会入库，从而导致日积月累的情况下，查询时就会创建一个额外的对象，引发频繁的young gc，甚至full gc
问题反思：
版本测试时，除了常规的功能测试外，还要对核心业务进行性能测试，根据时间进度可适当切割，但不能缺失
场景测试时，除了常规的场景测试外，还需考虑当前的数据库量级，若当前表量级较大，业务模块中的sql语句是否有做limit等限制
生产环境上应对应用做相关监控，除了日常的服务器本身性能监控外，还需要对应用本身的各项指标监控，例如：GC次数、GC耗时甚至young、s0、s1、pem、old等不同年代的监控。根据日常的监控图表来判断当前服务是否正常
一般来说，young gc的次数要大于old gc和full gc，且耗时是毫秒级。不然，则有可能：young年代设置过小，应用创建了过大的对象，存在大量强应用的对象实例等
参考资料：
https://my.oschina.net/flashsword/blog/265442
http://www.blogjava.net/rosen/archive/2010/06/13/323522.html
