问题概述
产品运维人员反馈，系统割接时新系统卡顿，无法响应用户请求，同时cpu、内存使用率都不高，业务基本没什么流量。通过arthas 工具定位热点代码，并跟踪到是业务变更导致了这次故障。
问题分析
1、查看cpu、内存、io ，业务量监控
从机器监控和采集的数据查看，系统指标正常，机器资源不足的原因被排除
故障发生在凌晨，业务流量基本没有，排除业务量增长的原因。这个问题属于隐蔽性较高的问题，需要结合现场分析，因此提出了压测方式复现。
2、采用业务模拟方式去压测没有复现问题
业务接口较多，业务提供了部分sql进行系统的压测，问题没有复现，这个问题和业务强相关，在1000多个接口里找到这个问题接口，比较困难，提出再次割接复现问题。
3、通过割接复现问题，通过jstack 分析系统的栈情况
采集信息命令如下：
jstack ${pid} > stack.txt
通过jstack 采集的信息，看到系统线程全部waiting 被block住了，基本可以判定，程序存在热点，主要是连接池存在严重的竞争，导致cpu的无效浪费，用户请求无法得到处理
4、通过割接复现问题，通过arthas 采集信息
采集的命令如下
profiler start
profiler status
profiler stop --format html
采集后的火焰图
根据火焰图可以很明显的看到有两处代码占用了70%的cpu调用，这两块代码基本属于非正常情况下代码。这两处非正常情况下的处理逻辑，消耗了cpu，也解释了系统正常业务无法得到响应的原因，cpu基本被这两处消耗，业务请求无法得到处理。也符合stack信息被block的情况，但是业务反馈他们没有变更，但是从采集的数据看，连接池这块是有问题的。
我们再次根据疑点代码和业务沟通，确认他们最近是否有和连接池相关的变更，后面他们反馈，他们在做系统改造，将部分的分片规则进行了修改。
我们根据他们的修改分析，他们的修改将连接需求扩大了几十倍，导致了故障，我们根据他们提供的有变更的sql 进行了压测，故障立马就复现了
问题解决
修复业务的变更，还原到历史状态，问题得到了解决。
