slf4j与common-logging

相通点:

  • 两者都为通用日志接口

异同:

  • slf4j 静态绑定日志(编译时绑定)
  • jcl 动态绑定(动态绑定跟类加载器有关,会有一定的问题)

slf4j 解决 jcl 以下两点问题

解决加载问题

Commons Logging存在的ClassLoader问题,即当服务器本身引入Commons Logging时,如果在服务器中载入Commons Logging包,则该包中的类由服务器的ClassLoader加载,从而在加载Log4J中的Logger类时会出现ClassNotFoundException,因为服务器中的ClassLoader没法找到Web App下的jar包。对于父ClassLoader优先的类加载机制来说,目前的一个解决方案是使用commons-logging-api-1.1.1.jar包,该包的Log实现类只包含Jdk14Logger、SimpleLog、NoOpLog三个类,因而在加载这几个类时会使用Web App中的Commons Logging包,从而解决ClassNotFoundException的问题,然而这种方式对那些实现Child ClassLoader First的服务器来说,由WebClassLoader父ClassLoader加载的类在使用日志时会存在问题,因为它们的Log接口由加载自身类的ClassLoader加载,而Log4JLogger类却由WebClassLoader加载。

性能优一些

在使用Commons Logging时,我们经常会看到以下方法的写法:
if (logger.isDebugEnabled()) {
logger.info(“Loading XML bean definitions from ” + encodedResource.getResource());
}

存在isDebugEnabled()的判断逻辑是为了在避免多余的字符串拼接,即如果不存在isDebugEnabled()判断,即使当前日志级别为ERROR时,在遇到logger.info()调用时,它还会先拼接日志消息的字符串,然后进入该方法内,才发现这个日志语句不用打印。而这种多余的拼接不仅浪费了多余的CPU操作,而且会增加GC的负担。SLF4J则提供以下的方式来解决这个问题:

logger.info(“Loading XML bean definitions from {}”, encodedResource.getResource());