测试场景：高可用场景--限流测试；
被测交易：查询类交易，HTTP协议；
交易链路：jmeter - web - coimpre(前置服务) -- coimbp -- cobp （coimbp 、coimpre 都会访问同一个数据库）；
注：cobp 为合肥机房，其他服务均为北京机房，要注意跨网段存在网络延迟（会导致TPS波动情况）；
场景配置：配置coimpre 服务的限流参数；
场景执行：执行场景使TPS 大于 限流参数，出发限流报错，可通过日志以及服务返回确认是否成功触发限流；
测试问题：交易触发限流后，监控coimpre服务CPU资源，从5% 上升至 90%以上，两次i验证执行，确认问题存在；
排查思路：
1. 使用top命令监控消耗CPU高的进程是否为java服务，（程序为java开发）；
2.使用top -Hp pid 查看进程下的线程消耗进一步确认是哪个线程消耗；
3. 打印线程dump文件，分析dump文件查看该线程此时的业务操作'（第一个图是 linux下 jcmd生成的，第二个是使用的 java VisualVM 生成的）
4. 定位问题，给出优化意见，测试验证；
4.1 通过dump文件分析，有问题的线程主要是在java net.URClassLoader.findResouce()方法，通过第一个图可以看到java util.zip,ziprile getentry，结合两个方法，并通过和开发沟通是否对某个 ZIP 文件中文件文件有操作。
4.2 项目组确认，交易报错后，日志会打印错误信息并带出是哪个jar包导致的错误，从而就会遍历整个jar目录。
4.3 共同认定是该问题导致的cpu升高，开发人员修改此处代码，不再遍历jar。
4.4 修改后，重新部署版本，再次验证限流，cpu资源下降至10%