后台服务出现明显“变慢”，谈谈你的诊断思路？

在日常工作中，应用或者系统出现性能问题往往是不可避免的，除了在有一定规模的IT企业或者专注于特定性能领域的企业，可能大多数工程师并不会成为专职的性能工程师，但是掌握基本的性能知识和技能，往往是日常工作的需要，并且也是工程师进阶的必要条件之一，能否定位和解决性能问题也是对你知识、技能和能力的检验

今天我要问你的问题是，后台服务出现明显“变慢”，谈谈你的诊断思路？

典型回答

• 首先，需要对这个问题进行更加清晰的定义:

  • 服务是突然变慢还是长时间运行后观察到变慢？类似问题是否重复出现？
  • “慢”的定义是什么，我能够理解是系统对其他方面的请求的反应延时变长吗?

• 第二，理清问题的症状，这更便于定位具体的原因，有以下一些思路：

  • 问题可能来自于Java服务自身，也可能仅仅是受系统里其他服务的影响。初始判断可以先确认是否出现了意外的程序错误，例如检查应用本身的错误日志
  • 对于分布式系统，很多公司都会实现更加系统的日志、性能等监控系统。一些Java诊断工具也可以用于这个诊断，例如通过JFR（Java Flight Recorder），监控应用是否大量出现了某种类型的异常。
  • 如果有，那么异常可能就是个突破点
  • 如果没有，可以先检查系统级别的资源等情况，监控CPU、内存等资源是否被其他进程大量占用，并且这种占用是否不符合系统正常运行状况
  • 监控Java服务自身，例如GC日志里面是否观察到Full GC等恶劣情况出现，或者是否Minor GC在变长等；利用jstat等工具，获取内存使用的统计信息也是个常用手段；利用jstack等工具检查是否出现死锁等
  • 如果还不能确定具体问题，对应用进行Profling也是个办法，但因为它会对系统产生侵入性，如果不是非常必要，大多数情况下并不建议在生产系统进行
  • 定位了程序错误或者JVM配置的问题后，就可以采取相应的补救措施，然后验证是否解决，否则还需要重复上面部分过程

考点分析

• 在正面回答之前，先探讨更加精确的问题定义是什么。有时候面试官并没有表达清楚，有必要确认自己的理解正确，然后再深入回答
• 从系统、应用的不同角度、不同层次，逐步将问题域尽量缩小，隔离出真实原因。具体步骤未必千篇一律，在处理过较多这种问题之后，经验会令你的直觉分外敏感
• 大多数工程师也许并没有全面的性能问题诊断机会，如果被问到也不必过于紧张，你可以向面试官展示诊断问题的思考方式，展现自己的知识和综合运用的能力。接触到一个陌生的问题，通过沟通，能够条理清晰地将排查方案逐步确定下来，也是能力的体现
• 面试官可能会针对某个角度的诊断深入询问，兼顾工作和面试的需求，我会针对下面一些方面进行介绍。目的是让你对性能分析有个整体的印象，在遇到特定领域问题时，即使不知道具体细节的工具和手段，至少也可以找到探索、查询的方向