循环中打日志的核心原则是“打对日志”而非“少打日志”：需控制级别与触发条件、用占位符延迟格式化、将上下文准备与聚合统计移出循环、采用异步日志框架兜底，并支持动态降级或关闭。
在大循环中记录日志，最直接的风险是日志量爆炸性增长、I/O阻塞加剧、线程等待变长，甚至拖垮整个应用响应。关键不是“少打日志”，而是“打对日志”——让日志既保留诊断价值，又不成为性能瓶颈。
控制日志级别与触发条件
不要在循环体里无差别调用 logger.info() 或 logger.debug()。高频日志应严格限定为 WARN 或 ERROR 级别，并附加明确的业务阈值或状态判断：
- 只在异常路径或关键状态跃迁时记录，例如：
if (item.isInvalid() && !loggedInvalidWarn) { logger.warn("首次发现无效项: {}", item.getId()); loggedInvalidWarn = true; } - 用计数器采样，如每千次迭代记录一次摘要：
if (i % 1000 == 0) logger.info("已处理 {} 条", i); - 避免在循环内拼接字符串或调用
toString()—— 使用占位符（{}）让 SLF4J 延迟格式化，仅当日志实际输出时才计算。
把日志逻辑移出热路径
循环本身是性能敏感区，所有非核心逻辑都应剥离。常见可外提的操作包括：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 日志上下文准备：如耗时的
getUserInfo()、getTraceId()调用，提前在循环外获取并缓存； - 结构化字段组装：将 JSON 字段构建、标签映射等逻辑放在循环前或后统一处理；
- 聚合统计代替逐条记录：用
AtomicInteger或局部变量累计失败数、耗时总和等，循环结束后一次性输出汇总日志。
用异步日志框架兜底
即使做了上述控制，突发流量下仍可能产生短时日志洪峰。推荐使用 Logback 的 AsyncAppender 或 Log4j2 的异步模式（基于 LMAX Disruptor），它们将日志写入操作转交给独立线程池处理，主线程几乎零阻塞：
立即学习“Java免费学习笔记（深入）”；
- Log4j2 配置示例：
<AsyncLogger name="com.example.BatchProcessor" level="info" includeLocation="false"/> - 注意设置合理的队列容量和丢弃策略（如
DiscardingThreshold），避免异步队列撑爆内存。
必要时关闭日志或降级
对超大规模批处理（如千万级数据导入），可在启动参数或配置中心动态开关 DEBUG/INFO 日志：
- 通过
logging.level.com.example=warn全局降级； - 在循环入口加判断：
if (LOGGER.isDebugEnabled()) { LOGGER.debug("batch processing start, size={}", list.size()); }，避免构造日志参数的开销； - 极端场景下，用
System.out.printf替代日志（仅限临时调试），绕过日志框架全部开销。
