为何线上高并发日志输出应避免包含代码位置信息？
- 内容介绍
- 文章标签
- 相关推荐
本文共计615个文字，预计阅读时间需要3分钟。
个人创作公约：本人声明，所创作的所有文章均为原创，如若引用其他文章，将注明出处。如有疏漏，欢迎批评指正。如发现网上有抄袭本文章的内容，欢迎举报，并给予积分奖励。
个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库 提交 issue，谢谢支持~
本文是“为什么我建议”系列第二篇，本系列中会针对一些在高并发场景下，我对于组内后台开发的一些开发建议以及开发规范的要求进行说明和分析解读，相信能让各位在面对高并发业务的时候避开一些坑。
往期回顾：
- 为什么我建议在复杂但是性能关键的表上所有查询都加上 force index
在业务一开始上线的时候，我们线上日志级别是 INFO，并且在日志内容中输出了代码位置，格式例如：
2022-03-02 19:57:59.425 INFO [service-apiGateway,,] [35800] [main][org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator:88]: Loaded RoutePredicateFactory [Query]
我们使用的日志框架是 Log4j2，方式是异步日志，Log4j2 的 Disruptor 的 WaitStrategy 采用了比较平衡 CPU 占用比较小的 Sleep，即配置了：AsyncLoggerConfig.WaitStrategy=Sleep。随着业务的增长，我们发现经常有的实例 CPU 占用非常之高（尤其是那种短时间内有大量日志输出的），我们 dump 了 JFR 进行进一步定位：
首先我们来看 GC，我们的 GC 算法是 G1，主要通过 G1 Garbage Collection这个事件查看：
发现 GC 全部为 Young GC，且耗时比较正常，频率上也没有什么明显异常。
接下来来看，CPU 占用相关。直接看 Thread CPU Load 这个事件，看每个线程的 CPU 占用情况。发现reactor-www.zhihu.com/people/zhxhash
本文共计615个文字，预计阅读时间需要3分钟。
个人创作公约：本人声明，所创作的所有文章均为原创，如若引用其他文章，将注明出处。如有疏漏，欢迎批评指正。如发现网上有抄袭本文章的内容，欢迎举报，并给予积分奖励。
个人创作公约：本人声明创作的所有文章皆为自己原创，如果有参考任何文章的地方，会标注出来，如果有疏漏，欢迎大家批判。如果大家发现网上有抄袭本文章的，欢迎举报，并且积极向这个 github 仓库 提交 issue，谢谢支持~
本文是“为什么我建议”系列第二篇，本系列中会针对一些在高并发场景下，我对于组内后台开发的一些开发建议以及开发规范的要求进行说明和分析解读，相信能让各位在面对高并发业务的时候避开一些坑。
往期回顾：
- 为什么我建议在复杂但是性能关键的表上所有查询都加上 force index
在业务一开始上线的时候，我们线上日志级别是 INFO，并且在日志内容中输出了代码位置，格式例如：
2022-03-02 19:57:59.425 INFO [service-apiGateway,,] [35800] [main][org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator:88]: Loaded RoutePredicateFactory [Query]
我们使用的日志框架是 Log4j2，方式是异步日志，Log4j2 的 Disruptor 的 WaitStrategy 采用了比较平衡 CPU 占用比较小的 Sleep，即配置了：AsyncLoggerConfig.WaitStrategy=Sleep。随着业务的增长，我们发现经常有的实例 CPU 占用非常之高（尤其是那种短时间内有大量日志输出的），我们 dump 了 JFR 进行进一步定位：
首先我们来看 GC，我们的 GC 算法是 G1，主要通过 G1 Garbage Collection这个事件查看：
发现 GC 全部为 Young GC，且耗时比较正常，频率上也没有什么明显异常。
接下来来看，CPU 占用相关。直接看 Thread CPU Load 这个事件，看每个线程的 CPU 占用情况。发现reactor-www.zhihu.com/people/zhxhash