本文主要是介绍隐藏老代码拖慢CPU，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
一次代码优化过程中发现，A处理的速度很慢，最开始盲看代码，发现A依赖的其它所有非B依赖都不会慢，当时就疑问了。
最后将A的所有外部依赖打印耗时日志分析，分析A所有的外部非B依赖都不慢，B是内存操作，为啥会慢呢？又一次疑问？
接着将A的主要接口内存函数都打赢耗时日志，发现B不慢
现在的问题是生产慢，发现测试缓解B的内存比较的数据量和生产不一样，测试环境只有１０ｗ的级别，生产环境最多的场景有５００ｗ的水平。
于是在测试环境构造了500w的数据，这样测试环境和生产环境的一样了，再跑一次，发现测试环境的耗时和生产一样了，最后把B的内存操作代码仔细debug一看，确认是是每次A调用B做数据比较的时候，都会执行500w次循环。业务初期B的比较量可能就几百几千，一两年后可能就几万，几十万，当5年左右的时间B的比较量达到500的时候，应用才开始慢了。
总结
- 第一版代码编写者就可以预判这个可能是未来的瓶颈，更换算法或者实现方式，再不济写一个注释
- 问题排查的过程中，主管判断是第一步，然后一定要用测试数据去佐证，不能直接主管判断下结论，特别是性能分析场景
- 大多数慢优化场景都是分析IO，网络，内存问题，很少有几个循环比较导致CPU慢的场景，这个容易让分析者习惯性走偏，为了避免这种情况，核心的办法就是测试对比，打印耗时，这是直接准确的数据，一且都要数据说话
- 一般测试环境分析问题都会存在和线上环境的基线环境不一样，内存，网络，cpu，数据等不同要考虑进去，允许的情况可以测试环境构造类似的生产数据来验证分析
这篇关于隐藏老代码拖慢CPU的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
