在日常工作中，应用性能问题在所难免。大多数公司都没有专门的绩效团队，仍然需要我们自己排查和处理问题。因此，掌握基本的表演知识和技巧是非常重要的。有必要，也是开发工程师进阶的必要条件。能否快速准确地定位和解决问题，也是对知识、技能和能力的考验。我们今天要讨论的问题是如何诊断和处理服务明显变慢的情况？首先我们要判断服务是否突然变慢，运行一段时间后观察？类似的减速是经常发生还是偶尔发生？另外，慢的定义是什么？是否可以理解为系统对其他方面请求的延迟变长了？弄清楚问题的症状后，更有利于分析问题的具体原因。大概有以下思路：检查应用程序本身的错误日志，看系统变慢时是否有大量的错误日志，判断是否有意外的程序错误。对于分布式系统，很多公司都有日志和性能监控系统，也可以使用一些Java诊断工具进行诊断，监控应用中是否大量出现某类异常。监控Java服务本身，查看GC日志中是否观察到频繁的FullGC。可以使用jstat等工具统计内存使用情况，使用jstack等工具查看是否发生死锁。如果无法定位问题，可以使用性能检测工具Profiling，因为它对系统有侵入性，没有必要，不推荐用于生产系统。定位问题，采取相应的补救措施，再验证是否解决。如果没有，重复上述操作。接下来，让我们看一下业界范围广泛的性能分析方法。方法论总结为两类：自上而下。从应用的顶层开始，逐渐深入到具体的不同模块，或者更接近技术细节的单元，寻找可能存在的问题和解决方案。这也是最常见的性能分析方法，也是大多数人的选择。自下而上。从CPU这样的硬件底层，判断Cache-Miss、调优机会等问题，出发点是指令级优化。这往往有比较高的门槛，需要专业的技能和专业的工具。通常发生在移植新平台或追求极致性能时。我们专注于第一种类型，自上而下。每个阶段使用的想法和工具。分析系统性能，我们往往从CPU、内存、IO入手，这些都是需要重点关注的地方。对于CPU，如果是linux环境，可以先用top命令查看负载：可以看到平均负载的三个值都不高，也没有上升的迹象，可以不特别关注，然后分析最耗CPU的Java线程，步骤如下：使用top命令获取对应的pid，-H代表线程模式，也可以配合grep命令更精确的定位。top-H然后转换为十六进制。printf"%x"your_pid最后用jstack得到的线程栈来比对对应的ID。您还可以使用vmstat查看上下文切换次数。例如指定时间间隔为1，则采集20次。vmstat-1-20如果上下文切换很高，系统高很多，说明可能是线程调度不合理。您可以使用pidstat进一步分析定位。除了CPU，内存和IO也有很多考虑：使用free查看内存的使用情况。进一步判断swap的使用情况，top命令输出中的Virt作为虚拟内存使用量，是物理内存（Res）和swap的总和，所以swap的使用情况可以反过来。显然，JVM不希望发生大量交换使用。对于IO问题，可能发生在磁盘IO或者网络IO上。例如，使用iostat等命令可以帮助确定磁盘的健康状况。
