JVM问题排查分析上篇（调优经验）

一般来说，只要系统架构设计得比较合理，大部分情况下系统都能正常运行，出现系统崩溃等故障问题是小概率事件。也就是说，业务开发是大部分软件工程中的重头戏，所以有人开玩笑说：“面试造火箭，入职拧螺丝。”

一般来说，我们进行排查分析的目的主要有：

• 解决问题和故障
• 排查系统风险隐患

我们按照问题的复杂程度，可以分为两类：

• 常规问题
• 疑难杂症

常规的问题一般在开发过程中就被发现和解决了，所以线上问题一般会比较复杂，出现在大家都没有考虑到的地方。按照我们的多年解决经验，这些复杂问题的排查方式可以分为两种途径：

• 逻辑严密的系统性排查；
• 以猜测来驱动，凭历史经验进行排查。

如果您倾向于选择后一种方式，那么可能会浪费大量的时间，效果得看运气。更糟糕的是，因为基本靠蒙，所以这个过程是完全不可预测的，如果时间很紧张，就会在团队内部造成压力，甚至升级为甩锅和互相指责。

系统出现性能问题或者故障，究竟是不是 JVM 的问题，得从各个层面依次进行排查。

为什么问题排查这么困难？

生产环境中进行故障排查的困难

在生产环境中针对特定问题进行故障排除时，往往会有诸多限制，从而导致排查的过程变得痛苦。

1. 影响到客户的时间越短越好