背景用户压测的时候发现系统的内存跟cpu使用会不断上升，直至内存和cpu占用接近100%，程序崩溃环境：鲲鹏服务器，虚拟机2C6G 压测：压测的是查询两个接口，接口功能只是简单查询如图，内存使用呈现稳定上升趋势初步分析内存不断上升的原因有很多，如： 1. 内存泄漏：程序中存在内存泄漏，即程序中的某些对象被创建后没有被正确地释放，导致内存不断占用。 2. 无限循环：程序中存在无限循环，导致程序不断占用内存。 3. 大量数据处理：程序处理大量数据时，可能会占用大量内存，导致内存占用不断升高。 4. 内存分配不当：程序中的内存分配不当，例如频繁创建大量对象或使用过多的线程，都可能导致内存占用不断升高。这边主要考虑先排查内存泄露的问题数据采集分析针对内存问题，这边主要通过java_perf工具采集了，内存转储，内存分配火焰图，cpu火焰图，采样分析内存分配火焰图拿到内存分配火焰图，第一眼就看到了中间存在一大段平顶的结构，往下看发现这个地方是java的ScheduledThreadPool线程池创建的线程占用的内存，这块肯定是有问题的，正常情况使用线程池线程数量都是会有限制，线程池在火焰图中的占比不会这么高线程分析在分析线程转储的时候，明显发现有一个名称为ifp-session-out-of-time-check-schedule-pool-1的数量很不正常在我们采样的第一秒这个线程的线程数量已经达到了1300+ 采集半分钟最后一秒这个线程的数量达到了2900+ 分析线程的调用栈刚好与我们内存分配火焰图那一块占用很大的线程池对应上，感觉找到了问题的突破口沟通交流这时候跟客户沟通，询问他们代码中有没有用到这个线程池，是不是线程池的配置出了问题，客户反馈他们自己的代码中并未使用到该线程池，这时候就很困惑，他们没用到我们工具采集出来了，现在的关键点是要找到这个线程池在他们代码里哪里使用的。热点火焰图分析接下来回到cpu热点火焰图，想看下这个线程具体是什么地方调用的，好让用户去定位通过这个可以看到这个线程池是com.ifp开头的包名的代码调用的内存转储分析通过内存分配火焰图定位到的内存异常分配的数据结构java.util.concurrent.locks.AbstractQueuedSynchronizer$Node在内存转储中搜索发现，该部分内存就是线程转储中异常增加的线程所占用的，根据此分析系统的内存持续增长大概率就是线程池的线程数量持续增长导致沟通交流向用户反馈了是这个包com.ifp用到的这个线程池，他们说这个包是他们使用的框架用到的，我们建议反编译框架的jar看下这个线程池在哪里使用的。调优结果在排查之后用户反馈确实在他们代码汇总使用到了框架的接口，间接的使用到了这个线程池，但是他们并不需要使用这个接口的功能，已删除代码，重新压测后结果正常，内存使用趋于稳定总结该案例是内存泄漏问题，关于内存泄漏问题我们这边主要关注几个方面 1、内存分配火焰图，能一眼直观的发现那一块占用的内存最多，从而明确大概的分析方向 2、GC分析GC行为，看GC是否正常，堆使用是否正常 3、线程转储，关注有无异常增长的线程 4、内存转储，具体分析可疑对象占用的内存 5、CPU火焰图，根据上面分析明确调用栈，便于提供优化建议工具优化建议 1.采样分析线程转储数据量大图形化界面卡顿严重，体验较差 2.内存转储文件大的时候下载出现卡顿，会让人误以为不能下载 3.针对这种比较典型的问题能否在优化建议体现出来 4.内存转储列出从GC转储到对象最短共同路径的时候，数据列表要显示对应的线程名称且要支持搜索功能