Log4j2两种Lambda日志写法的性能对比：哪种更优？

首先得明确Log4j2支持Lambda表达式做日志参数的核心目的：避免在日志级别未开启时，执行不必要的计算和字符串拼接操作——这两种写法都能做到这一点，但当日志级别开启时，性能差异就体现出来了。

咱们来拆解两种写法的底层逻辑：

第一种写法：logger.trace("Number is {}", () -> getRandomNumber()); #

• 当Trace级别未开启时：Lambda表达式完全不会被执行，getRandomNumber()根本不会调用，没有任何额外开销。
• 当Trace级别开启时：Log4j2会调用Lambda获取getRandomNumber()的返回值，然后用框架内置的占位符格式化逻辑完成字符串拼接。这个逻辑是Log4j2专门针对日志场景优化过的，它不需要像通用格式化工具那样解析复杂的格式规则，直接把参数对应到占位符，效率很高。

第二种写法：logger.trace(() -> String.format("Number is : %s)", getRandomNumber())); #

• 当Trace级别未开启时：和第一种一样，Lambda不会执行，getRandomNumber()和String.format都不会运行，开销可以忽略。
• 当Trace级别开启时：Lambda会被执行，这时候需要先调用getRandomNumber()，再调用String.format完成格式化。而String.format是Java的通用格式化工具，它需要解析整个格式字符串、处理Locale、支持各种格式符（比如日期、数字格式化），这些额外的逻辑都会带来比Log4j2内置格式化更高的性能开销。

性能结论 #

• 如果你的日志级别大部分时间是关闭的，两种写法的性能几乎没有区别；
• 但当日志级别开启时，第一种写法的性能明显更优，因为它利用了Log4j2优化后的格式化逻辑，避免了String.format的额外开销。

另外从代码可读性和框架最佳实践来说，第一种写法也更贴合Log4j2的设计意图，代码更简洁，不需要手动处理字符串格式化。

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