Logger.getLogger() 與 LogFactory.getLog() 核心差異與選型指南

Java 日誌門面兩大巨頭：Log4j vs Commons Logging 核心 API 差異解析

在 Java 日誌生態中，Logger.getLogger() (Log4j/Log4j2 原生 API) 與 LogFactory.getLog() (Commons Logging / JCL) 是兩種最常見的日誌獲取方式。它們分別代表「具體實現綁定」與「門面抽象」兩種設計哲學，選型直接影響專案的靈活度與維護成本。

核心差異速覽表

代碼使用對比

// === Log4j 原生 API (強綁定) ===
import org.apache.log4j.Logger;

public class Log4jNativeExample {
    // 通常傳入當前類別，支援按類別分級配置
    private static final Logger logger = Logger.getLogger(Log4jNativeExample.class);
    
    public void doBusiness() {
        logger.info("業務處理開始");
        logger.debug("詳細除錯信息");
    }
}

// === Commons Logging (JCL) 門面 API (弱綁定) ===
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public class JclExample {
    private static final Log log = LogFactory.getLog(JclExample.class);
    
    public void doBusiness() {
        log.info("業務處理開始");
        log.debug("詳細除錯信息");
    }
}

JCL 的動態綁定機制深度解析

LogFactory.getLog() 內部執行以下查找順序 (類別載入器層級)：

1. 尋找 org.apache.commons.logging.Log 實現類 (由 commons-logging.properties 指定)
2. 嘗試載入 org.apache.commons.logging.impl.Log4jLogger (若類路徑有 Log4j)
3. 嘗試載入 org.apache.commons.logging.impl.Jdk14Logger (Java Util Logging - JUL)
4. 退回 org.apache.commons.logging.impl.SimpleLog (控制台輸出，無需額外依賴)

這意味著：同一套代碼，換掉類路徑下的日誌實現 JAR，行為自動適配。

經典坑點：類別載入器地獄

JCL 依賴 TCCL (Thread Context ClassLoader) 掃描實現類，在以下環境極易出問題：

• OSGi / 模組化環境： 類別載入器隔離導致找不到實現類
• 應用服務器 (WebLogic, JBoss, Tomcat 共享庫)： 父子載入器衝突
• Spring Boot 內嵌容器： 類別載入器層級複雜，JCL 常綁定錯誤實現

這是 SLF4J 取代 JCL 成為主流門面的核心原因——SLF4J 在編譯期靜態綁定，避免運行時掃描風險。

現代選型建議 (2024+)

遷移最佳實踐

1. 統一門面： 專案中禁用 Logger.getLogger() 和 LogFactory.getLog()，全面改用 org.slf4j.LoggerFactory.getLogger()
2. 橋接舊依賴： 引入 log4j-over-slf4j、jcl-over-slf4j、jul-to-slf4j 將舊 API 重定向至 SLF4J
3. 選擇實現： 引入 logback-classic 或 log4j-slf4j-impl 作為最終實現
4. 統一配置： 僅保留 logback-spring.xml 或 log4j2.xml 一份配置

理解兩者本質差異，能幫助你在技術債重構、框架選型、疑難雜症排查時做出架構級決策。