生产环境一次JVM 调优的记录总结（八）

r囧r小猫 2022-12-07 12:29 173阅读 0赞

cpu过高、项目运行慢：

进入Linux重端命令行  top 命令：找到java 进程号  7498

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

**2.****执行** **top -p 7498 ****单独监控该进程，页面：**

![20200915225719961.png][]

**3****、在第** **2** **步的监控界面输入** **H****，获取当前进程下的所有线程信息：发现7501、7500两个线程占用内存最大。**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

**4、执行**  **jstack 7498 ** **对当前的进程做**  **dump** **，输出所有的线程信息，随机截图：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

**5、里面的线程id 是16进制，随机找到一个截图：**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

**6**  **将第 3** ** ** **步得到的线程编号 7500** ** 通过计算器** **转成**  **16**  **进制是 1D4C、1D4D**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]  ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5][]

或者   printf "%x\\n" 7500  生成1D4D    然后  ： jstack 7498|grep 1D4D -C 10

![20200927170157707.png][]

![20200927170513545.png][]

**7、 ** **根据第**  **6**  **步得到的 1D4D** ** ** **在第**  **5**  **步的线程信息里面去找对应线程内容:**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7][] ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8][]

**8**  **解读线程信息，定位具体代码位置，发现是两个垃圾回收的线程占用过多的线程资源，疯狂的垃圾回收导致系统变慢；看看日志（加上打印垃圾回收的日志）还有OOM异常；**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 9][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 10][]

发现新生代不进行垃圾回收，一直进行FGC垃圾回收，5秒钟进行10次，全部时间用来FGC。WAY!!!,找原因！！！！

9、jmap -heap 7498

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 11][]

发现老年代已经塞满。

10、查一下这个进程的占据内存的前20名的对象，找到代码中相应的类，命令： jmap -histo 7498 | head -20

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 12][]

业务代码类找到了，就去项目中看看，这时所有问题都迎刃而解了！！！ 今天实战线上排查到此结束！

注意！！！

原因：

业务场景1，此线程有非常多或非常大的对象存在，并且处理这些对象的过程很慢、很耗时，即此线程不结束，对象引用一直存在，不会变成垃圾，因此，GC频繁进行，内存也不会有变化。

业务场景2：内存泄漏引起OOM异常，该回收的垃圾，回收不了，造成系统变慢。如：map中 对象作为key 而没有重写 hashcode 和equal 方法。

业务场景3：慢sql查询大的数据量，导致数据库连接数紧张。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221123/e2061dd2b115422483b8b248204ca3bf.png
[20200915225719961.png]: /images/20221123/3b479eb89e714f638819b25d0780c9ea.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221123/c3f776eee0e043c0bb778265dc179f52.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221123/4d16025303674184bd6ab68c866b1b47.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221123/1defbbedee3f4c70992b73215eff8b78.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: https://img-blog.csdnimg.cn/20200915230619996.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5]: /images/20221123/95609fb3877544e580f6717a09d60d57.png
[20200927170157707.png]: /images/20221123/d3e3ddbbbb7841a9bc5e92a48b61dd8c.png
[20200927170513545.png]: /images/20221123/dc1d51dca50248ac8c858f300a4ebf2a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 6]: /images/20221123/2638e14f17e144928c35e77c8d48a00f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 7]: https://img-blog.csdnimg.cn/20200915230944735.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA==,size_16,color_FFFFFF,t_70
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 8]: /images/20221123/353679f9cdfb4015923ba6d5158dc97b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 9]: /images/20221123/92ee2233e28940ebacb6fd171c3f3270.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 10]: /images/20221123/89e6831d8d3a4397898550999855e616.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 11]: /images/20221123/ffd29463fb8a4079a28c00ae8c144e66.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 12]: /images/20221123/f3da1027223744d2b9b830823d43f5d6.png