相通点：

• 两者都为通用日志接口

异同：

• 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());