【Java核心-性能基础】诊断后台服务明显变慢

详细描述问题现象

服务变慢的具体表现形式往往可以提供一些思路，帮我们缩小排查范围。如：

服务时突然变慢 还是 长时间运行后变慢？

该现象是否重复出现？

 

（

虽然以下开发人员的回答经常会被谴责，甚至认为政治不正确，但这样的回答确实可以为排查问题提供一些信息。

测试：“程序有bug。”

开发：“不可能。在我机器上运行是好的。”

在这种情况下，“先认定程序逻辑没问题，去排查环境问题”也是比较合理的一个方向。

）

 

解决思路

1. 定位问题原因

1.1 先排查功能性原因

通过问题中描述的业务场景，自顶向下理清各模块调用链路；结合服务日志及其它相关运行时数据定位问题。

查看服务自身的业务日志。如果有异常日志，可从异常日志入手。

 

1.2 再排查非功能性原因

1.2.1 查看操作系统级别的资源使用情况

如，是否大量CPU、内存等资源被其它进程占用。

Linux 中可使用命令：

• dstat：一个综合性的系统资源使用状况查看工具
• top：查看CPU与内存占用率较高的进程数据（默认按CPU占用率降序排列）
• vmstat：查看CPU、内存、IO等性能相关的数据
• 如，上下文切换频率（cs）比系统中断频率（in）高很多，可能是多线程调度不合理
• pidstat：查看单个进程的CPU、内存、IO等相关数据
• iostat：查看各设备的IO状况
• free命令：查看操作系统内存使用情况

《Linux 性能》

 

 

1.2.2 查看Java服务的JVM相关日志

• GC日志中是否出现 Full GC、Minor GC 耗时是否变长等现象。
• （《GC调优思路》 -Xlog:gc）
• 查看内存使用信息（jstat）
• 查看是否出现死锁（jstack）

另外，使用 Profiling 工具对 Java 程序进行性能分析一般是在性能测试阶段。（专业的 Profiling 工具如果用得好，帮助很大）

对生产系统上的 Java程序进行 Profiling 会使系统性能明显下降。

如果确实需要在生产系统上进行，可以采用 JFR + JMC 的方式。JFR 采集数据的方式开销较小（低于2%）

《JVM 内存监控与诊断》

 

有时候 火焰图 也是一种选择。可以从视觉上的感受哪些方法耗时较长。（当然，专业集成化 Profiling 工具更强大）

 

2. 根据问题原因修复程序或调整相关配置，并验证问题已解决

如未解决，重复上述操作