Java System.Logger 怎样按级别判断是否构造日志参数

Java 日志代码里最容易被忽略的成本，不是调用 log 本身，而是调用之前已经完成的字符串拼接、对象遍历或 JSON 序列化。如果 DEBUG 级别没有开启，这些参数仍然会被构造，日志虽然被过滤了，业务线程却已经付出了计算成本。

System.Logger 的处理方式很明确：用 isLoggable 判断某个级别当前是否会记录；需要延迟构造消息时，把逻辑放进 Supplier。两者解决的是同一个问题的不同形态，不能把日志级别判断当成业务条件。

先把日志级别和参数成本拆开

System.Logger 的级别判断只回答“这一条消息当前是否可记录”，不回答“参数是否已经计算”。下面这种写法会先执行 buildDiagnosticText，再把结果交给日志 API：

// 低级别日志关闭时，复杂诊断文本仍会先被构造
String detail = buildDiagnosticText(request);
logger.log(System.Logger.Level.DEBUG, "request detail=" + detail);

因此排查性能问题时要分成两个指标看：日志调用是否被级别过滤，以及过滤前是否已经发生了昂贵的参数准备。第二项才是这篇文章要消除的浪费。

需要显式边界时使用 isLoggable

当日志参数需要多步准备、需要复用判断结果，或者你想把保护范围写得非常清楚时，可以先判断级别：

// 只有 DEBUG 级别实际可记录时，才遍历对象并拼接诊断信息
if (logger.isLoggable(System.Logger.Level.DEBUG)) {
    String detail = buildDiagnosticText(request);
    logger.log(System.Logger.Level.DEBUG, "request detail=" + detail);
}

这段判断的边界是日志系统，不是业务流程。不要写成“DEBUG 开启才执行关键业务”，也不要把同一个级别判断结果缓存成长期业务状态；日志后端的有效级别可能由运行时配置决定。

只延迟消息时直接传 Supplier

如果只是希望消息文本在真正需要记录时才生成，直接传 Supplier 更紧凑：

// Lambda 只描述消息生成方式，避免 DEBUG 未开启时立即执行遍历
logger.log(
    System.Logger.Level.DEBUG,
    () -> "request detail=" + buildDiagnosticText(request)
);

这里延迟的是 Lambda 内部的表达式。把昂贵计算放在 Lambda 外面，仍然会失去延迟效果；例如先执行 String detail = ... 再返回 () -> detail，只是把已经发生的计算包了一层。

如果消息需要同时带异常，也可以使用带 Throwable 和 Supplier 的重载，让异常对象保持可追踪，同时不提前生成描述文本。

两种写法怎样选择

最后检查三点：级别参数是否写对、昂贵代码是否真的位于 Lambda 或判断块内、Lambda 是否包含会改变业务状态的副作用。System.Logger 负责表达日志意图，具体输出和级别配置仍由底层日志实现负责。

常见问题

用了 Supplier，为什么还是感觉有开销？

Supplier 只能延迟它内部的消息生成；日志调用前的对象创建、方法参数求值和外层字符串拼接仍会照常发生，应把需要延迟的计算整体放入 Lambda。

isLoggable 能替代日志后端配置吗？

不能。它只读取当前 Logger 对某个级别是否可记录，不能配置 Handler、格式化器或具体后端。