JVM线上问题解决整理

JVM服务问题排查:JVM服务问题排查_左手-CSDN博客

一让人难以忘怀的排查频繁 Full GC 过程：https://www.iteye.com/blog/caogen81-1513345

线上 FullGC 频繁的排查：线上FullGC频繁排查-druid_Rocky的博客-CSDN博客_full gc排查

JVM线上应用故障排查：【JVM】线上应用故障排查 - Mr.Ming2 - 博客园高CPU占用 一个应用占用CPU很高，除了确实是计算密集型应用之外，通常原因都是出现了死循环。 根据top命令，发现PID为28555的Java进程占用CPU高达200%，出现故障。 通过ps auxhttps://www.cnblogs.com/Dhouse/p/7839810.html 

一次 JVM 中 FullGC 问题排查过程：

https://www.iteye.com/blog/iamzhongyong-1830265

JVM 内存溢出导致的 CPU 过高问题排查案例：JVM内存溢出导致的CPU过高问题排查案例_nielinqi520的博客-CSDN博客_排查jvm内存溢出 

JVM 内存溢出导致的 CPU 过高问题排查案例：JVM内存溢出导致的CPU过高问题排查案例_nielinqi520的博客-CSDN博客_排查jvm内存溢出问题背景：近期针对某接口做压力测试的过程中发现，某接口在用户量3千左右，并且业务没有对外开放，CPU一直居高不下。分析：初步怀疑开发人员逻辑控制不严谨， 导致死循环，因为业务量不大，用户量不大，不可能出现高并发。 1.通过jstack查找出对应执行线程是Vm Thread 线程,初步怀疑是频繁的GC导致cpu过高。 2.查看堆栈信息 jmap -heap 16190https://blog.csdn.net/nielinqi520/article/details/78455614 

一个java内存泄露的排查案例：一个java内存泄漏的排查案例_aasgis6u的专栏-CSDN博客_java内存泄漏排查这是个比较典型的java内存使用问题，定位过程也比较直接，但对新人还是有点参考价值的，所以就纪录了一下。下面介绍一下在不了解系统代码的情况下，如何一步步分析和定位到具体代码的排查过程（以便新人参考和自己回顾） 初步的现象业务系统消费MQ中消息速度变慢，积压了200多万条消息，通过jstat观察到业务系统fullgc比较频繁,到最后干脆OOM了：进一步分析既https://blog.csdn.net/aasgis6u/article/details/54928744