首先祝各位大大国庆快乐！不知道大家国庆七天怎么安排，是赚加班费呢，还是快乐出游呢，又或者是响应防疫号召在家休息不扎堆呢？😆

相信不少大大在欢度国庆的同时也不会停下弯道超车的步伐🤓，所以，登登登登！堆堆为大家准备了10篇精选性能问题排查优化实践文章，希望大家看完有启发，有收获！

话不多说，一起来看文章吧📜～

---

1.JVM垃圾回收与一次线上内存泄露问题分析和解决过程

作者：Java小能手

https://heapdump.cn/article/266960

导语：内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。
Java是由C++发展来的，抛弃了C++中一些繁琐容易出错的东西，程序员忘记或者错误的内存回收会导致程序或系统的不稳定甚至崩溃，而Java的GC(Garbage Collection)是自动检测不用的对象，达到自动回收，
既然是自动检测回收不用对象，那Java有没有可能出现内存泄露的情况呢？

 

2.一次 Young GC 的优化实践（FinalReference 相关）

作者：涤生

https://heapdump.cn/article/266587

导语：此篇是 18 年底的微信上的某同学提供的一个 Young GC 问题案例，找我帮忙解决。这个 GC 案例比较有意思，虽然过去有一段时间了，但是想想觉得还是有必要写出来，应该对大家很有帮助。
排查问题有点像侦探断案，先分析各种可能性，再按照获得的一个个证据，去排除各种可能性、然后定位原因，最终解决问题。

 

3.一次生产 CPU 100% 排查优化实践

作者：crossoverJie

https://heapdump.cn/article/397282

导语：到了年底果然都不太平，最近又收到了运维报警：表示有些服务器负载非常高，让我们定位问题。
还真是想什么来什么，前些天还故意把某些服务器的负载提高（没错，老板让我写个 BUG！），不过还好是不同的环境互相没有影响。

 

4.一次 HashSet 所引起的并发问题

作者：crossoverJie

https://heapdump.cn/article/543424

导语：上午刚到公司，准备开始一天的摸鱼之旅时突然收到了一封监控中心的邮件。心中暗道不好，因为监控系统从来不会告诉我应用完美无 bug，其实系统挺猥琐。打开邮件一看，果然告知我有一个应用的线程池队列达到阈值触发了报警。由于这个应用出问题非常影响用户体验；于是立马让运维保留现场 dump 线程和内存同时重启应用，还好重启之后恢复正常。于是开始着手排查问题。

 

5.一次线上服务高 CPU 占用优化实践

作者：挖坑的张师傅

https://heapdump.cn/article/596690

导语：线上有一个非常繁忙的服务的 JVM 进程 CPU 经常跑到 100% 以上，下面写了一下排查的过程。通过阅读这篇文章你会了解到下面这些知识。
•Java 程序 CPU 占用高的排查思路
•可能造成线上服务大量异常的 log4j 假异步
•Kafka 异步发送的优化
•On-CPU 火焰图的原理和解读
•使用 Trie 前缀树来优化 Spring 的路径匹配

 

6.一次艰难的内存泄露排查，BeanUtils的锅

作者：landon30

https://heapdump.cn/article/1717246

导语：通过jstat -gcutil pid 5000 ，发现fgc次数很多而且频繁，此时老年代占比已经大约70%左右，且已经回收不了内存，我们这边设置的fgc阈值是老年代的70%。此时因为还有30%的老年空间，所以整体内存相对还算稳定，CPU也比较稳定，但是有很大的潜在的风险，就是内存一直上涨，不释放。

 

7.线程池运用不当的一次线上事故

作者：Rockets

https://heapdump.cn/article/646639

导语：在高并发、异步化等场景，线程池的运用可以说无处不在。线程池从本质上来讲，即通过空间换取时间，因为线程的创建和销毁都是要消耗资源和时间的，对于大量使用线程的场景，使用池化管理可以延迟线程的销毁，大大提高单个线程的复用能力，进一步提升整体性能。
今天遇到了一个比较典型的线上问题，刚好和线程池有关，另外涉及到死锁、jstack命令的使用、JDK不同线程池的适合场景等知识点，同时整个调查思路可以借鉴，特此记录和分享一下。

 

8.一次I/O问题引发的P0重大故障

作者：冯涛_二马读书

https://heapdump.cn/article/1741711

导语：几年前的一个下午，公司里码农们正在安静地敲着代码，突然很多人的手机同时“哔哔”地响了起来。本来以为发工资了，都挺高兴！打开一看，原来是告警短信。
告警提示“线程数过多，超出阈值”，“CPU空闲率太低”。打开监控系统一看，订单服务所有20个服务节点都不行了，服务没响应。

 

9.一次“内存泄漏”引发的血案

作者：technology

https://heapdump.cn/article/1842762

导语：对性能不佳的Ark Server进行了改造和重写。重编发布一段时间后，结果发现新发布的Svr的机器内存一直在上涨。花了3、4天时间，使用各种办法进行定位，一无所获。后来无意中在SPP日志中发现了端倪。

 

10.一次线上JVM Young GC调优，搞懂了这么多东西！

作者：冯涛_二马读书

https://heapdump.cn/article/1846118

导语：先说一下基本情况，本次是对线上商品服务的JVM优化。商品服务的访问量非常高，单机QPS在3000左右，线上总共部署了15个商品服务节点。JVM堆内存大小是8G，其中给新生代分配了2G，老年代垃圾回收器采用CMS，新生代垃圾回收器是ParNew。

 

---

看完了这么多文章，你认为写得最好对你最有帮助的是哪篇呢？又或者延伸出了哪些新的思考？可以在评论区交流哦～节后堆堆会选取一条精彩评论送上我们社区的🎁专属小礼品～一起来快乐学习吧！🥳