在项目中经常遇到的jvm问题，排查经历记录如下。

一，cpu飙高，频繁full gc，内存泄漏

本次cpu飙高，看下gc情况，发现频繁full gc
java cpu占用cpu较高的线程也是gc线程。
如此，则排查full gc的原因。
根据堆转储分析，首先找占内存最大的类。
发现有一个hashmap占内存巨大，其中存在大量不同的key,但value相同的键值对。
对照代码，查出此处存在内存泄漏，存入方式key生成机制存在问题，且没有清理机制。导致该map持续增长，不能得到回收。内存持续泄漏，最终导致超过堆内存gc百分比限制，不停gc，以回收其他部分内存。
由于该map增长速率有限，导致频繁full gc而不报oom。

二，dom4j引起的内存溢出

本次发生oom后，查看堆转储文件，发现存在多个持有dom4j对象的实例占用大量内存，经排查，该对象原始xml文档在10M左右，导致转化为dom4j后占用内存激增，最终导致oom。

dom4j在解析大文件时导致内存占用过高的问题，需要进一步优化。

三，mysql 多表查询产生笛卡尔积导致内存溢出

该次内存溢出，经排查，有个sql查询使用了多表查询，在条件不当的情况下，由笛卡尔积产生了千万条返回结果，导致问题出现。

解决方式，修改sql,改多表查询为连接查询，增加limit限制相应条数。

四，因程序递归不当，产生cpu飙高，卡住所有请求

该次问题产生，看起来是cpu飙高，飙高的线程为gc线程。
有些奇怪的是，该现象下full gc次数并不高，而minor gc 比较频繁。

经查，系统中存在一段代码，使用不合理的递归，导致循环递归产生嵌套，在每层递归时都请求了数据库，导致大量对象的产生和也即是短暂的垃圾产生，从而导致minor gc频繁执行，占满了系统cpu,导致系统卡住。