在高性能 Java 应用中，日志级别检查（如 log.isInfoEnabled()）应放在函数内部，以兼顾性能与可维护性；关键是要避免在日志禁用时执行冗余对象构造和方法调用。
在高性能 Java 应用中，日志级别检查（如 `log.isInfoEnabled()`）应放在函数内部，以兼顾性能与可维护性；关键是要避免在日志禁用时执行冗余对象构造和方法调用。
在实际开发中，日志调用看似轻量，但不当的写法可能悄然引入可观的性能开销——尤其在高频路径（如网络包处理、事件循环）中。核心矛盾在于：逻辑清晰性 与 运行时效率 的权衡。下面从原理、实践和重构三方面给出专业建议。
✅ 推荐方案：日志检查置于函数内部，但需规避副作用计算
将 log.isInfoEnabled() 放入 logPacket() 内部是更优选择，原因如下：
- 方法调用开销极低：JVM 的即时编译器（JIT）对简单方法调用有高度优化（如内联），额外一层 private void 方法几乎不增加 CPU 开销；
- 代码复用与可读性显著提升：调用方无需重复写 if (log.isInfoEnabled())，避免分散、易遗漏的守卫逻辑；
- 真正影响性能的是“日志参数的提前求值”，而非方法调用本身。例如原代码中：
logPacket("Received Packet. ", packetCp, packet, Packet.Type.getTypeByValue(code).toString());即使日志被禁用，Packet.Type.getTypeByValue(code).toString() 仍会被执行——这可能触发枚举查找、字符串拼接、甚至反射调用，属于典型的无效计算浪费。
因此，正确做法是延迟求值：仅在确认日志启用后，才计算日志占位符所需的参数。
✅ 重构示例（安全、高效、整洁）
private void infoLogPacket(String msg, ConnectPoint sessionInfo, Ethernet packet, Code code) {
if (!log.isInfoEnabled()) {
return; // 快速退出，避免后续任何计算
}
// ✅ 所有昂贵操作均在此之后执行
String packetType = Packet.Type.getTypeByValue(code).toString();
String portName = sessionInfo.port().name(); // 避免多次调用
int priority = packet.getPriorityCode();
short vlanId = packet.getVlanID();
short qinqVid = packet.getQinQVID();
byte[] srcMac = packet.getSourceMAC();
byte[] dstMac = packet.getDestinationMAC();
log.info("{} type: {} to: {} client: {} stageCode: {} vlan: {} vlanPcp: {} srcMac: {} dstMac: {}",
msg, packetType, sessionInfo, portName, priority,
vlanId, qinqVid, Arrays.toString(srcMac), Arrays.toString(dstMac));
}? 提示：使用 Arrays.toString(byte[]) 替代原始数组打印，避免 byte[].toString() 返回无意义哈希值。
⚠️ 关键注意事项
- 禁止在日志方法签名中传入已计算的字符串（如 String packetType），否则失去延迟求值意义；
- 避免在日志参数中调用复杂 getter 或业务方法：如 user.getProfile().getPreferences().toJSONString() —— 应提取到 if 块内；
- 考虑使用 SLF4J 的参数化日志（已采用）：它本身不执行字符串拼接，但无法阻止你传入已计算的表达式；
- 极端场景可结合 Lambda 形参（SLF4J 2.0+）：
log.info("Packet type: {}", () -> Packet.Type.getTypeByValue(code).toString());此方式由日志框架自动控制求值时机，进一步降低侵入性。
? 总结
性能优化的第一准则是：先测量，再优化。但在日志场景中，isXxxEnabled() 检查的位置已有明确最佳实践：
✅ 统一放在日志封装方法内部；
✅ 确保所有非平凡参数计算严格位于检查之后；
✅ 通过方法命名（如 infoLogPacket）显式传达其条件行为。
这样既消除了隐藏的性能陷阱，又让调用代码简洁如 infoLogPacket("Received", cp, pkt, code); —— 清晰、安全、可维护。
