项目引入：某个功能页面一直打开进行静态拷机，发现内存持续增长。
可以通过JConsole监测内存增长曲线：
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=YOUR_PORT
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.rmi.server.hostname=YOUR_SERVER_IP
然后输出一下堆内存快照，通过MAT进一步分析：
jmap: jmap -dump:live,format=b,file=<filename>.hprof <pid>
jcmd: jcmd <pid> GC.heap_dump <filename>.hprof
同时查看一下Full GC频率：
jstat -gc <pid> interval count
- S0C 和 S1C：Survivor区0和Survivor区1的当前容量（字节）。
- S0U 和 S1U：Survivor区0和Survivor区1的已用空间大小。
- EC 和 EU：Eden区的当前容量及其已用空间大小。
- OC 和 OU：老年代的当前容量及其已用空间大小。
- MC 和 MU：Metaspace的当前容量及其已用空间大小（在Java 8及以上版本中，永久代被Metaspace取代）。
- CCSC 和 CCSU：压缩类空间的当前容量及其已用空间大小。
- YGC 和 YGCT：年轻代GC事件的总次数及其总耗时（秒）。
- FGC 和 FGCT：Full GC事件的总次数及其总耗时（秒）。
- GCT：所有GC事件的总耗时（秒），等于YGCT加FGCT
MAT打开Heap Dump文件，查看Dominator Tree的引用链，哪个对象占用对空间最大
经分析，最终定位到2处泄漏的地方：一处是 JNI回调方法中，由于这些方法被频繁地调用，处理JNI对象时候生成了部分局部引用一直被占用未被释放；另一处是一个静态Map一直被占用，处理LRUCache的数据并存放到Map，由于size过大还没处理完又不断有新请求进来，强引用太多，调用方法阻塞。
除修改泄漏处代码外，调整了部分JVM参数，如下：
// 设置G1垃圾收集器触发一次混合垃圾回收周期时整个堆占用率的阈值
-XX:InitiatingHeapOccupancyPercent=25
// G1启用字符串去重功能以减少内存占用
-XX:+UseStringDeduplication
// 设置G1垃圾收集器允许的最大堆浪费比例
-XX:G1HeapWastePercent=10
**//**设置应该预留的堆空间百分比
-XX:G1ReservePercent=20
-XX:ParallelRefProcEnabled
******//******设置尝试达到的目标最大GC停顿时间
-XX:MaxGCPauseMillis=100
// 设置 Eden 区与单个 Survivor 区的比例
-XX:SurvivorRatio=6
****//****设置 Minor GC 后 Survivor 区（To Space）预期的占用比例