WildFly21配置INFO日志级别时logger.debug语句的性能影响咨询

直接给结论：保留未触发输出的logger.debug()语句会产生极少量的基础开销，但绝大多数业务场景下这点开销完全可以忽略，不需要为了性能特意删除这些语句，排障时直接调整日志级别启用即可，但要注意规避写法不当带来的额外开销。

不存在“日志性能成本仅来自文件I/O”的绝对说法，整个debug调用的开销可以拆成三个部分，在你设置日志级别为INFO的前提下，不同部分的触发情况完全不同：

• 固定触发的基础开销
  只要代码执行到logger.debug()这行，首先会触发一次方法调用，方法内部第一时间会做日志级别校验：判断当前配置的日志级别是否允许DEBUG输出。你配置的是INFO级别，这一步校验会直接返回false，后续所有日志处理流程直接终止。
  这部分的开销本质就是一次普通Java方法调用+一个整型数值的大小比较，现代JVM的JIT编译甚至会把这段逻辑直接内联优化，单次调用耗时在纳秒级。除非你是在每秒执行几十万次的极致性能热点循环（比如底层序列化、流量转发的核心路径）里堆了大量debug语句，否则常规业务代码里的这点开销压测都测不出差异，完全不需要在意。
  另外WildFly21默认使用JBoss LogManager作为底层日志实现，你代码里用的Log4j API会自动桥接到JBoss LogManager，级别校验逻辑在调用最外层就会执行，不存在桥接层额外消耗性能的问题。
• 写法不当会带来的可规避开销
  这才是很多人踩性能坑的核心点，和debug方法本身无关：如果你在debug参数里提前做了高成本计算，哪怕日志级别是INFO不会输出，这部分计算也会实打实执行。
  比如下面这种错误写法：

  // 错误示例：提前拼接字符串、做JSON序列化
  logger.debug("处理请求，用户信息：" + objectMapper.writeValueAsString(user) + "，参数：" + JSON.toJSONString(req));
  

  这种写法下，JVM会先执行完括号里所有的字符串拼接、JSON序列化逻辑，把最终拼好的字符串传给debug方法，之后才会走级别校验发现不需要输出。如果序列化的是大对象，这部分开销可能到毫秒级，积少成多会带来明显的性能浪费。
  规避这个问题非常简单：
  • 优先用日志框架自带的占位符写法传参，不要手动拼接字符串：

    // 正确写法：级别不满足时不会对参数做求值处理
    logger.debug("处理请求，用户信息：{}，参数：{}", user, req);
    

  • 如果参数本身需要高成本计算（比如序列化大对象、遍历大集合做内容拼接），先加级别判断再执行：

    if (logger.isDebugEnabled()) {
        logger.debug("处理请求，用户信息：{}", objectMapper.writeValueAsString(user));
    }
    

• 不会触发的高成本流程
  你担心的日志格式化、锁竞争、磁盘I/O、控制台输出这类高成本操作，只有在DEBUG级别真的开启时才会执行，当前配置INFO级别的前提下，这部分流程完全不会走到，没有任何开销。

实操建议 #

• 普通业务代码里的debug语句，只要用标准占位符写法，完全可以保留，不需要为了极致性能删除，排障时直接调整日志级别就能快速输出信息，效率远高于临时加日志重新发布。
• 对于QPS极高的核心性能热点路径，可以酌情精简非必要的debug语句，涉及高成本参数计算的逻辑必须加isDebugEnabled()判断包裹。
• 无论什么场景，都不要在debug语句里写无级别判断的高成本计算逻辑，避免不必要的性能浪费。

内容的提问来源于stack exchange，提问作者Phuthib