一般来说，只要系统架构设计得比较合理，大部分情况下系统都能正常运行，出现系统崩溃等故障问题是小概率事件。也就是说，业务开发是大部分软件工程中的重头戏，所以有人开玩笑说：“面试造火箭，入职拧螺丝。”
一般来说，我们进行排查分析的目的主要有：
解决问题和故障排查系统风险隐患
我们按照问题的复杂程度，可以分为两类：
常规问题疑难杂症
常规的问题一般在开发过程中就被发现和解决了，所以线上问题一般会比较复杂，出现在大家都没有考虑到的地方。按照我们的多年解决经验，这些复杂问题的排查方式可以分为两种途径：
逻辑严密的系统性排查；以猜测来驱动，凭历史经验进行排查。
如果您倾向于选择后一种方式，那么可能会浪费大量的时间，效果得看运气。更糟糕的是，因为基本靠蒙，所以这个过程是完全不可预测的，如果时间很紧张，就会在团队内部造成压力，甚至升级为甩锅和互相指责。
系统出现性能问题或者故障，究竟是不是 JVM 的问题，得从各个层面依次进行排查。
为什么问题排查这么困难？
生产环境中进行故障排查的困难
在生产环境中针对特定问题进行故障排除时，往往会有诸多限制，从而导致排查的过程变得痛苦。
1. 影响到客户的时间越短越好
如果觉得《JVM 问题排查分析上篇（调优经验）》对你有帮助，请点赞、收藏，并留下你的观点哦！
