测试场景：高可用场景--限流测试； 被测交易：查询类交易，HTTP协议； 交易链路：jmeter - web - coimpre(前置服务) -- coimbp -- cobp （coimbp 、coimpre 都会访问同一个数据库）； 注：cobp 为合肥机房，其他服务均为北京机房，要注意跨网段存
测试场景：在高可用场景下进行限流测试。
被测交易：HTTP协议下的查询类交易。
交易链路：jmeter - web - coimpre(前置服务) -- coimbp -- cobp（coimbp、coimpre均访问同一数据库）。
注：cobp位于合肥机房，其他服务位于北京机房，需注意跨网段网络延迟可能导致TPS波动。
场景配置：配置coimpre服务的限流参数。
场景执行：执行场景使TPS大于限流参数，触发限流报错，通过日志和服务返回确认是否成功触发限流。
测试问题：交易触发限流后，监控coimpre服务CPU资源，从5%上升至90%以上，两次验证执行，确认问题存在。
排查思路：
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%。
小编推荐阅读
