生产环境应避免循环中打印大量日志，需从逻辑设计（聚合记录）、输出控制（限频/采样）、框架机制（级别判断+延迟求值+mdc）三方面系统规避。
在循环中打印大量日志是生产环境常见的性能隐患——它不仅放大 CPU 消耗（尤其是字符串拼接或 JSON 序列化），更会触发高频磁盘 I/O，导致线程阻塞、响应延迟甚至服务抖动。避免的关键不是“少打几条”，而是从逻辑设计、输出控制和框架机制三方面系统规避。
用聚合代替逐条记录
循环本质是批量操作，日志也应按批次表达结果，而非每轮都“汇报一次”。例如处理 1000 条订单时，不要在 for 中写 1000 次 info，而应在循环外统计并汇总输出。
- 记录总数、成功数、失败数、耗时等聚合指标，如：“批量处理完成：共1000条，成功982条，失败18条，耗时327ms”
- 仅对异常项单独记录（且加限频），例如只打印前 3 个失败详情，其余仅计数
- 若需审计每条，改用结构化方式写入独立审计表或消息队列，不走业务日志通道
必须打时，严格限频或采样
某些调试场景确实需要观察循环行为，但绝不能无约束输出。可结合计数器、时间窗口或随机采样控制频率。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 每 N 次打一次：用 counter % 100 == 0 实现“每百次记录一次”
- 按时间限频：用 System.nanoTime() 控制最小间隔（如 5 秒内最多打 1 条）
- 低概率采样：用 Math.random() 实现 1% 抽样，适合高 QPS 场景
预检日志级别 + 延迟求值
即使用了占位符，参数表达式仍会在调用时执行。循环中调用 heavyJsonSerialize(item) 或 item.toString() 依然昂贵。
- 先判断是否开启对应级别：if (logger.isDebugEnabled()) { logger.debug("Item: {}", item); }
- 对高开销参数，用 Supplier 包裹（Log4j2/SLF4J 2.0+ 支持）：logger.debug("Detail: {}", () -> toJson(item));
- 避免在循环内反复调用 JSON.toJSONString() 等重型方法，提前计算好再传入
用 MDC 注入上下文，替代重复打印
循环中反复打印相同上下文（如 batchId、threadId、traceId）既冗余又难读。改用 MDC 统一注入，让日志格式自动携带。
- 循环前设置：MDC.put("batchId", "BATCH-20260925-001");
- 日志 pattern 中配置：batchId=%X{batchId:-N/A}
- 这样每条日志自动带 batchId，无需在循环体里手动拼接
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
