log4j，slf4j及Commons Logging介绍与原理使用



一、     概念

Log4j 
Apache的一个开放源代码项目，通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件、甚至是套接口服务 器、NT的事件记录器、UNIX Syslog守护进程等；用户也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，用户能够更加细致地控制日志的生成过程。这些可以通过一个 配置文件来灵活地进行配置，而不需要修改程序代码。是 经典的一种日志解决方案。内部把日志系统抽象封装成Logger 、appender 、pattern 等实现。我们可以通过配置文件轻松的实现日志系统的管理和多样化配置。

LOGBack 
Logback是由log4j创始人设计的又一个开源日记组件。logback当前分成三个模块：logback-core,logback- classic和logback-access。logback-core是其它两个模块的基础模块。logback-classic是log4j的一个 改良版本。此外logback-classic完整实现SLF4J API使你可以很方便地更换成其它日记系统如log4j或JDK14 Logging。logback-access访问模块与Servlet容器集成提供通过Http来访问日记的功能。LOGBack 作为一个通用可靠、快速灵活的日志框架，将作为Log4j 的替代和SLF4J 组成新的日志系统的完整实现。官网上称具有极佳的性能，在关键路径上执行速度是log4j 的10 倍，且内存消耗更少。具体优势见：http://logback.qos.ch/reasonsToSwitch.html

Log4J vs. LOGBack 
LOGBack作为一个通用可靠、快速灵活的日志框架，将作为Log4j的替代和SLF4J组成新的日志系统的完整实现。LOGBack声称具有极佳的性能，“ 某些关键操作，比如判定是否记录一条日志语句的操作，其性能得到了显著的提高。这个操作在LogBack中需要3纳秒，而在Log4J中则需要30纳秒。 LogBack创建记录器（logger）的速度也更快：13微秒，而在Log4J中需要23微秒。更重要的是，它获取已存在的记录器只需94纳秒，而 Log4J需要2234纳秒，时间减少到了1/23。跟JUL相比的性能提高也是显著的”。 

另外，LOGBack的所有文档是全面免费提供的，不象Log4J那样只提供部分免费文档而需要用户去购买付费文档。 

SLF4J 
简单日记门面(Facade)SLF4J是为各种loging APIs提供一个简单统一的接口，从而使得最终用户能够在部署的时候配置自己希望的loging APIs实现。 Logging API实现既可以选择直接实现SLF4J接的loging APIs如： NLOG4J、SimpleLogger。也可以通过SLF4J提供的API实现来开发相应的适配器如Log4jLoggerAdapter、JDK14LoggerAdapter。 

Apache Common-Logging 
目前广泛使用的Java日志门面库。通过动态查找的机制，在程序运行时自动找出真正使用的日志库。但由于它使用了ClassLoader寻找和载入底层的日志库， 导致了象OSGI这样的框架无法正常工作，由于其不同的插件使用自己的ClassLoader。 OSGI的这种机制保证了插件互相独立，然而确使Apache Common-Logging无法工作。 apache最早提供的日志的门面接口。避免和具体的日志方案直接耦合。类似于JDBC 的api 接口，具体的的JDBC driver 实现由各数据库提供商实现。通过统一接口解耦，不过其内部也实现了一些简单日志方案。

SLF4J vs. Apache Common-Logging 
SLF4J库类似于Apache Common-Logging。但是，他在编译时静态绑定真正的Log库。使用SLF4J时，如果你需要使用某一种日志实现，那么你必须选择正确的SLF4J的jar包的集合。 如此便可以在OSGI中使用了。 
另外，SLF4J 支持参数化的log字符串，避免了之前为了减少字符串拼接的性能损耗而不得不写的if(logger.isDebugEnable())，现在你可以直接写：logger.debug(“current user is: {}”, user)。拼装消息被推迟到了它能够确定是不是要显示这条消息的时候，但是获取参数的代价并没有幸免。同时，日志中的参数若超过三个，则需要将参数以数组的形式传入，如： 
Object[] params = {value1, value2, value3}; 
logger.debug(“first value: {}, second value: {} and third value: {}.”, params); 

现在，Hibernate、Jetty、Spring-OSGi、Wicket和MINA等项目都已经迁移到了SLF4J，由此可见SLF4J的影响力不可忽视。 

        Slf4j全称为Simple Logging Facade for JAVA：java简单日志门面。 是对不同日志框架提供的一个门面封装。可以在部署的时候不修改任何配置即可接入一种日志实现方案。和commons-loging 应该有一样的初衷。个人感觉设从计上更好一些，没有commons 那么多潜规则。同时有两个额外特点：

1. 能支持多个参数，并通过{} 占位符进行替换，避免老写logger.isXXXEnabled 这种无奈的判断，带来性能提升见：http://www.slf4j.org/faq.html#logging_performance 。

2.OSGI 机制更好兼容支持，官网上的一个图：

从上图可以发现，选择还是很多的。

二、     常见日志方案和注意事项

1.Commons-logging+log4j : 经典的一个日志实现方案。出现在各种框架里。如spring 、webx 、ibatis 等等。直接使用log4j 即可满足我们的日志方案。但是一般为了避免直接依赖具体的日志实现，一般都是结合commons-logging 来实现。常见代码如下：

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

private static Log logger = LogFactory.getLog(CommonsLoggingTest.class);

代码上，没有依赖任何的log4j 内部的类。那么log4j 是如何被装载的？

Log 是一个接口声明。LogFactory 的内部会去装载具体的日志系统，并获得实现该Log 接口的实现类。而内部有一个Log4JLogger 实现类对Log 接口同时内部提供了对log4j logger 的代理。LogFactory 内部装载日志系统流程：

1.   首先，寻找org.apache.commons.logging.LogFactory 属性配置

2.   否则，利用JDK1.3 开始提供的service 发现机制，会扫描classpah 下的META-INF/services/org.apache.commons.logging.LogFactory 文件，若找到则装载里面的配置，使用里面的配置。

3.   否则，从Classpath 里寻找commons-logging.properties ，找到则根据里面的配置加载。

4.   否则，使用默认的配置：如果能找到Log4j 则默认使用log4j 实现，如果没有则使用JDK14Logger 实现，再没有则使用commons-logging 内部提供的SimpleLog 实现。

从上述加载流程来看，如果没有做任何配置，只要引入了log4j 并在classpath 配置了log4j.xml ，则commons-logging 就会使log4j 使用正常，而代码里不需要依赖任何log4j 的代码。

2.Commons-logging+log4j+slf4j

如果在原有commons-logging 系统里，如果要迁移到slf4j, 使用slf4j 替换commons-logging ，也是可以做到的。原理使用到了上述commons-logging 加载的第二点。需要引入Org.slf4j.jcl-over-slf4j-1.5.6.jar 。这个jar 包提供了一个桥接，让底层实现是基于slf4j 。原理是在该jar 包里存放了配置META-INF/services/org.apache.commons.logging.LogFactory =org.apache.commons.logging.impl.SLF4JLogFactory，而commons-logging 在初始化的时候会找到这个serviceId ，并把它作为LogFactory 。

完成桥接后，那么那么简单日志门面SLF4J 内部又是如何来装载合适的log 呢？

原理是SLF4J 会在编译时会绑定import org.slf4j.impl.StaticLoggerBinder; 该类里面实现对具体日志方案的绑定接入。任何一种基于slf4j 的实现都要有一个这个类。如：

org.slf4j.slf4j-log4j12-1.5.6: 提供对 log4j 的一种适配实现。

Org.slf4j.slf4j-simple-1.5.6: 是一种 simple 实现，会将 log 直接打到控制台。

……

那么这个地方就要注意了：如果有任意两个实现slf4j 的包同时出现，那就有可能酿就悲剧，你可能会发现日志不见了、或都打到控制台了。原因是这两个jar 包里都有各自的org.slf4j.impl.StaticLoggerBinder ，编译时候绑定的是哪个是不确定的。这个地方要特别注意！！出现过几次因为这个导致日志错乱的问题。

 

 

3.使用SLf4j +log4j很简单：

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
public class TestSlf4j {
private static final Logger logger = LoggerFactory.getLogger(TestSlf4j.class);
public static void main(String[] args) {
logger.info(logger.getName());
}
}

代码里也看不到任何具体日志实现方案的痕迹。

三、springMVC中commons logging的源码

HttpServletBean.java

/** Logger available to subclasses */protected final Log logger = LogFactory.getLog(getClass());

/**     * Convenience method to return a named logger, without the application     * having to care about factories.     *     * @param clazz Class from which a log name will be derived     * @throws LogConfigurationException if a suitable <code>Log</code>     *  instance cannot be returned     */    public static Log getLog(Class clazz) throws LogConfigurationException {        return getFactory().getInstance(clazz);    }

commons logging中的LogFactory.getFactory()

 /**     * Construct (if necessary) and return a <code>LogFactory</code>     * instance, using the following ordered lookup procedure to determine     * the name of the implementation class to be loaded.     * <p>     * <ul>     * <li>The <code>org.apache.commons.logging.LogFactory</code> system     *     property.</li>     * <li>The JDK 1.3 Service Discovery mechanism</li>     * <li>Use the properties file <code>commons-logging.properties</code>     *     file, if found in the class path of this class.  The configuration     *     file is in standard <code>java.util.Properties</code> format and     *     contains the fully qualified name of the implementation class     *     with the key being the system property defined above.</li>     * <li>Fall back to a default implementation class     *     (<code>org.apache.commons.logging.impl.LogFactoryImpl</code>).</li>     * </ul>     * <p>     * <em>NOTE</em> - If the properties file method of identifying the     * <code>LogFactory</code> implementation class is utilized, all of the     * properties defined in this file will be set as configuration attributes     * on the corresponding <code>LogFactory</code> instance.     * <p>     * <em>NOTE</em> - In a multi-threaded environment it is possible     * that two different instances will be returned for the same     * classloader environment.     *     * @throws LogConfigurationException if the implementation class is not     *  available or cannot be instantiated.     */    public static LogFactory getFactory() throws LogConfigurationException {        // Identify the class loader we will be using        ClassLoader contextClassLoader = getContextClassLoaderInternal();        if (contextClassLoader == null) {            // This is an odd enough situation to report about. This            // output will be a nuisance on JDK1.1, as the system            // classloader is null in that environment.            if (isDiagnosticsEnabled()) {                logDiagnostic("Context classloader is null.");            }        }        // Return any previously registered factory for this class loader        LogFactory factory = getCachedFactory(contextClassLoader);        if (factory != null) {            return factory;        }        if (isDiagnosticsEnabled()) {            logDiagnostic(                    "[LOOKUP] LogFactory implementation requested for the first time for context classloader " +                    objectId(contextClassLoader));            logHierarchy("[LOOKUP] ", contextClassLoader);        }        // Load properties file.        //        // If the properties file exists, then its contents are used as        // "attributes" on the LogFactory implementation class. One particular        // property may also control which LogFactory concrete subclass is        // used, but only if other discovery mechanisms fail..        //        // As the properties file (if it exists) will be used one way or        // another in the end we may as well look for it first.        Properties props = getConfigurationFile(contextClassLoader, FACTORY_PROPERTIES);        // Determine whether we will be using the thread context class loader to        // load logging classes or not by checking the loaded properties file (if any).        ClassLoader baseClassLoader = contextClassLoader;        if (props != null) {            String useTCCLStr = props.getProperty(TCCL_KEY);            if (useTCCLStr != null) {                // The Boolean.valueOf(useTCCLStr).booleanValue() formulation                // is required for Java 1.2 compatibility.                if (Boolean.valueOf(useTCCLStr).booleanValue() == false) {                    // Don't use current context classloader when locating any                    // LogFactory or Log classes, just use the class that loaded                    // this abstract class. When this class is deployed in a shared                    // classpath of a container, it means webapps cannot deploy their                    // own logging implementations. It also means that it is up to the                    // implementation whether to load library-specific config files                    // from the TCCL or not.                    baseClassLoader = thisClassLoader;                }            }        }        // Determine which concrete LogFactory subclass to use.        // First, try a global system property        if (isDiagnosticsEnabled()) {            logDiagnostic("[LOOKUP] Looking for system property [" + FACTORY_PROPERTY +                          "] to define the LogFactory subclass to use...");        }        try {            String factoryClass = getSystemProperty(FACTORY_PROPERTY, null);            if (factoryClass != null) {                if (isDiagnosticsEnabled()) {                    logDiagnostic("[LOOKUP] Creating an instance of LogFactory class '" + factoryClass +                                  "' as specified by system property " + FACTORY_PROPERTY);                }                factory = newFactory(factoryClass, baseClassLoader, contextClassLoader);            } else {                if (isDiagnosticsEnabled()) {                    logDiagnostic("[LOOKUP] No system property [" + FACTORY_PROPERTY + "] defined.");                }            }        } catch (SecurityException e) {            if (isDiagnosticsEnabled()) {                logDiagnostic("[LOOKUP] A security exception occurred while trying to create an" +                              " instance of the custom factory class" + ": [" + trim(e.getMessage()) +                              "]. Trying alternative implementations...");            }            // ignore        } catch (RuntimeException e) {            // This is not consistent with the behaviour when a bad LogFactory class is            // specified in a services file.            //            // One possible exception that can occur here is a ClassCastException when            // the specified class wasn't castable to this LogFactory type.            if (isDiagnosticsEnabled()) {                logDiagnostic("[LOOKUP] An exception occurred while trying to create an" +                              " instance of the custom factory class" + ": [" +                              trim(e.getMessage()) +                              "] as specified by a system property.");            }            throw e;        }        // Second, try to find a service by using the JDK1.3 class        // discovery mechanism, which involves putting a file with the name        // of an interface class in the META-INF/services directory, where the        // contents of the file is a single line specifying a concrete class        // that implements the desired interface.        if (factory == null) {            if (isDiagnosticsEnabled()) {                logDiagnostic("[LOOKUP] Looking for a resource file of name [" + SERVICE_ID +                              "] to define the LogFactory subclass to use...");            }            try {                final InputStream is = getResourceAsStream(contextClassLoader, SERVICE_ID);                if( is != null ) {                    // This code is needed by EBCDIC and other strange systems.                    // It's a fix for bugs reported in xerces                    BufferedReader rd;                    try {                        rd = new BufferedReader(new InputStreamReader(is, "UTF-8"));                    } catch (java.io.UnsupportedEncodingException e) {                        rd = new BufferedReader(new InputStreamReader(is));                    }                    String factoryClassName = rd.readLine();                    rd.close();                    if (factoryClassName != null && ! "".equals(factoryClassName)) {                        if (isDiagnosticsEnabled()) {                            logDiagnostic("[LOOKUP]  Creating an instance of LogFactory class " +                                          factoryClassName +                                          " as specified by file '" + SERVICE_ID +                                          "' which was present in the path of the context classloader.");                        }                        factory = newFactory(factoryClassName, baseClassLoader, contextClassLoader );                    }                } else {                    // is == null                    if (isDiagnosticsEnabled()) {                        logDiagnostic("[LOOKUP] No resource file with name '" + SERVICE_ID + "' found.");                    }                }            } catch (Exception ex) {                // note: if the specified LogFactory class wasn't compatible with LogFactory                // for some reason, a ClassCastException will be caught here, and attempts will                // continue to find a compatible class.                if (isDiagnosticsEnabled()) {                    logDiagnostic(                        "[LOOKUP] A security exception occurred while trying to create an" +                        " instance of the custom factory class" +                        ": [" + trim(ex.getMessage()) +                        "]. Trying alternative implementations...");                }                // ignore            }        }        // Third try looking into the properties file read earlier (if found)        if (factory == null) {            if (props != null) {                if (isDiagnosticsEnabled()) {                    logDiagnostic(                        "[LOOKUP] Looking in properties file for entry with key '" + FACTORY_PROPERTY +                        "' to define the LogFactory subclass to use...");                }                String factoryClass = props.getProperty(FACTORY_PROPERTY);                if (factoryClass != null) {                    if (isDiagnosticsEnabled()) {                        logDiagnostic(                            "[LOOKUP] Properties file specifies LogFactory subclass '" + factoryClass + "'");                    }                    factory = newFactory(factoryClass, baseClassLoader, contextClassLoader);                    // TODO: think about whether we need to handle exceptions from newFactory                } else {                    if (isDiagnosticsEnabled()) {                        logDiagnostic("[LOOKUP] Properties file has no entry specifying LogFactory subclass.");                    }                }            } else {                if (isDiagnosticsEnabled()) {                    logDiagnostic("[LOOKUP] No properties file available to determine" + " LogFactory subclass from..");                }            }        }        // Fourth, try the fallback implementation class        if (factory == null) {            if (isDiagnosticsEnabled()) {                logDiagnostic(                    "[LOOKUP] Loading the default LogFactory implementation '" + FACTORY_DEFAULT +                    "' via the same classloader that loaded this LogFactory" +                    " class (ie not looking in the context classloader).");            }            // Note: unlike the above code which can try to load custom LogFactory            // implementations via the TCCL, we don't try to load the default LogFactory            // implementation via the context classloader because:            // * that can cause problems (see comments in newFactory method)            // * no-one should be customising the code of the default class            // Yes, we do give up the ability for the child to ship a newer            // version of the LogFactoryImpl class and have it used dynamically            // by an old LogFactory class in the parent, but that isn't            // necessarily a good idea anyway.            factory = newFactory(FACTORY_DEFAULT, thisClassLoader, contextClassLoader);        }        if (factory != null) {            /**             * Always cache using context class loader.             */            cacheFactory(contextClassLoader, factory);            if (props != null) {                Enumeration names = props.propertyNames();                while (names.hasMoreElements()) {                    String name = (String) names.nextElement();                    String value = props.getProperty(name);                    factory.setAttribute(name, value);                }            }        }        return factory;    }

参考：

http://javacrazyer.iteye.com/blog/1135493

http://blog.csdn.net/woshiwxw765/article/details/7624556

http://blog.csdn.net/conquer0715/article/details/9365491