日志打印高并发场景case记录

case介绍

线上服务OOM,通过Java自带的jvisualvm打开dump文件查看内存对象分析,500个一组,发现前面几组的栈信息全部指向代码中的同一行

LOGGER.info("业务xxxx, xName: {}, xText: {}", xName, xText);

jvisualvm截图如下
日志打印高并发场景case记录_第1张图片

case分析(直接扒源码)

日志打印高并发场景case记录_第2张图片

日志打印高并发场景case记录_第3张图片
日志打印高并发场景case记录_第4张图片
请添加图片描述

跳过N步后

日志打印高并发场景case记录_第5张图片

结论归纳

可以看到上图最终是通过构造event参数体填充传入的StringBuffer,对比上面jvisualvm截图可以理解原因如下:

StringBuilder内部通过final修饰的char数组来存储数据,高并发情况短期大量线程构造StringBuilder对象,同时由于方法内部处理逻辑时间可能较长或者StringBuilder随弹栈返回,导致构建的StringBuilder在此期间大量存在最终累积导致OOM

学到的东西

作为技术人,用技术更要懂技术 。对于使用的技术工具最好能深入了解整个流程,一方面做技术规划时有更充分的理由支持技术栈的选择,另一方面也是避免踩坑。
其次,技术栈规划最好是使用社区活跃,适用人群较多的工具、语言,遇到问题排查成本会更小

你可能感兴趣的:(后端,日志,java,oom,log4j)