详细描述问题现象
服务变慢的具体表现形式往往可以提供一些思路，帮我们缩小排查范围。如：
服务时突然变慢 还是 长时间运行后变慢？
该现象是否重复出现？
（
虽然以下开发人员的回答经常会被谴责，甚至认为政治不正确，但这样的回答确实可以为排查问题提供一些信息。
测试：“程序有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%）
有时候 火焰图 也是一种选择。可以从视觉上的感受哪些方法耗时较长。（当然，专业集成化 Profiling 工具更强大）
2. 根据问题原因修复程序或调整相关配置，并验证问题已解决
如未解决，重复上述操作