几种日志的区别
- commons-logging
apache最早提供的日志的门面接口。避免和具体的日志方案直接耦合。类似于JDBC的api接口，具体的的JDBC driver实现由各数据库提供商实现。通过统一接口解耦，不过其内部也实现了一些简单日志方案。 - Log4j
Logging for Java，经典的一种日志解决方案。内部把日志系统抽象封装成Logger、appender、pattern等实现。我们可以通过配置文件轻松的实现日志系统的管理和多样化配置。 - slf4j
全称为Simple Logging Facade for Java。 是对不同日志框架提供的一个门面封装。可以在部署的时候不修改任何配置即可接入一种日志实现方案。和commons-loging类似。个人感觉设从计上更好一些，没有commons那么多潜规则。同时有两个额外特点：①能支持多个参数，并通过{}占位符进行替换，避免老写logger.isXXXEnabled这种无奈的判断，带来性能提升见；②OSGI机制更好兼容支持。 - logback
作为一个通用可靠、快速灵活的日志框架，将作为Log4j的替代和slf4j组成新的日志系统的完整实现。具有极佳的性能，在关键路径上执行速度是log4j的10 倍，且内存消耗更少。 - Log4j2
Log4j2是Log4j的升级版，与之前的版本Log4j 1.x相比、有重大的改进，在修正了Logback固有的架构问题的同时，改进了许多Logback所具有的功能。
可以这么理解，slf4j和commons-logging是一种抽象接口，Log4j、Log4j2和logback是它们的实现，在实际使用中，一般选择slf4j+Log4j2或者slf4j+logback。
性能对比可以看：Apache Log4j 2.0值得升级吗
下文仅讨论slf4j+logback
配置及使用
1、引入相关日志依赖，去除其他无关日志依赖
既然选择了slf4j+logback，首先要将项目中的其他jar包，如commons-logging、Log4j去掉。
如果项目使用maven，可以使用mvn dependency:tree命令来查看描绘项目依赖树，看哪些显式的dependecy依赖了它们。
如spring-core里面就集成了commons-logging，可以通过exclusions标签将其排除掉。
org.springframework
spring-core
${spring.version}
commons-logging
commons-logging
但spring本身日志就使用的commons-logging，仅仅去掉就会使其不能正常工作，还需要添加commons logging到slf4j的桥接器jcl-over-slf4j，如下在项目中添加该依赖：
org.slf4j
jcl-over-slf4j
${jcl.over.slf4j.version}
如果有直接使用log4j的组件，也要将log4j排除掉，同时添加log4j-over-slf4。
org.slf4j
log4j-over-slf4j
最后，可以使用mvn dependency:tree或者mvn dependency:list查看项目依赖，看是否存在重复引入等，比如我们使用slf4j+logback的方案，只需要引入logback-classic即可，不必再显示添加slf4j-api和logback-core，因为logback-classic本身依赖它们。
ch.qos.logback
logback-classic
${logback.version}
这一步就是引入logback和slf4j，去掉common-logging、Log4j、Log4j等无关日志组件，同时添加commons logging到slf4j的桥接器jcl-over-slf4j（如果项目中原来使用到了commons logging）。
2、配置logback
logback在启动时，根据以下步骤寻找配置文件：①在classpath中寻找logback-test.xml文件→②如果找不到logback-test.xml，则在 classpath中寻找logback.groovy文件→③如果找不到 logback.groovy，则在classpath中寻找logback.xml文件
如果上述的文件都找不到，则logback会使用JDK的SPI机制查找 META-INF/services/ch.qos.logback.classic.spi.Configurator中的 logback 配置实现类，这个实现类必须实现Configuration接口，使用它的实现来进行配置
如果上述操作都不成功，logback 就会使用它自带的 BasicConfigurator 来配置，并将日志输出到console。
这里采用xml格式的配置文件：在resources目录下新建logback.xml文件，logback.xml文件的具体配置如下（仅供参考）：
edu-cloud
[%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] %-5level %logger{36} : %msg%n
UTF-8
INFO
${LOG_HOME}/log.%d{yyyy-MM-dd}.log
30
UTF-8
[%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] %-5level %logger{36} : %msg%n
error
${LOG_HOME}/error.%d{yyyy-MM-dd}.log
30
UTF-8
[%d{yyyy-MM-dd HH:mm:ss.SSS}] [%thread] %-5level %logger{36} : %msg%n
在进行配置的时候，主要要理解或记住以下几点（主要标签的用处）：
-
appender，负责定义日志的输出目的地（控制台、日志文件、滚动日志文件，其他如logstash等）。-
encoder负责定义日志的输出样式和字符编码，如果在控制台出现?????或乱码，则指定编码（一般是UTF-8）就好了。 -
filter负责过滤日志，即使logger传来了dubug级别以上的日志，如果filter中设定了级别为info，则该appender只会将info级别及以上的日志输出到目的地。 -
rollingPolicy负责制定日志文件的滚动规则，是根据日志文件大小还是根据日期进行滚动。
-
logger，负责定义我们实际代码中使用的logger。logger中有一个非常重要的属性name，name必须指定。在logback中，logger有继承关系，而所有的logger的祖先是root。
举个例子，如果我们有个类叫UserService，所在的包为com.maxwell.service，在UserService中要打印日志，我们一般会这么写：
①private Logger logger = LoggerFactory.getLogger(UserService.class);
或者
②private Logger logger = LoggerFactory.getLogger("com.maxwell.service.UserService");
这两种写法是一样的，第①中写法实际会转化为②中的方式来获取一个logger实例。
当我们写下这行代码时，logback会依次检查以下各个logger实例的是否存在，如果不存在则依次创建：
com
com.maxwell
com.maxwell.service
com.maxwell.service.UserService
而创建logger实例的时候，就会去配置文件中查找名字为com、com.maxwell、com.maxwell.service、com.maxwell.service.UserService的logge标签，并根据其中定义的规则创建。所以，假如你在配置文件中没有定义name为上述字符串的logger时，就会找到root这个祖先，根据root标签定义的规则创建logger实例。
理解了上面的这一点，想要实现某个包或者某个类单独输出到某日志文件的需求就很好实现了：①定义一个appender，指明日志文件的输出目的地；②定义一个logger，name设为那个包或类的全路径名。如果只想将这个类或包的日志输出到刚才定义的appender中，就将additivity设置为false。
还有就是，上面的参考配置可以保证mybatis的sql语句、spring的日志正常输出到控制台，但由于mybatis的sql语句输出的级别为debug，所以不会输出到name为infoFile的appender中，因为该appender中设置了级别为info的过滤器filter，如果想将mybatis的sql语句也输出到日志文件中，请将info改为debug。
也就是，一条日志想要顺利到达输出目的地，除了logger的级别要低于该级别，appender中的filter中设置的级别也要低于该级别。（TRACE < DEBUG < INFO < WARN < ERROR）
3、使用
在代码中获取logger时，我们可能有两种方式：
private static Logger logger = LoggerFactory.getLogger(UserService.class);
private Logger logger = LoggerFactory.getLogger(UserService.class);
你可能会认为不加static会为UserService类的不同实例创建多个logger实例，实际不是的，某个类的logger实例一旦创建，logback会将其缓存在一个map中(Map)，下次获取的时候直接从这个map中获取。所以，上述两种写法性能差距不大，只多一个很小的从cache中取对象的开销：加上static，下次获取的时候就直接从内存中取了（类变量是多个实例共享的），不会再调用LoggerFactory.getLogger(UserService.class)，而不加static则从logback的缓存中取，需要调用LoggerFactory.getLogger(UserService.class)。
最后要注意的是，这里的Logger和LoggerFactory是slf4j包里的，不要选成了java.util.logging。如果你的IDE出现了slf4j和java自带日志包外的其他选项，就要考虑你是不是没有将其他不相关的日志组件从你的项目中去掉。
参考
logback中logger对象的创建过程源码分析
Why log4j's Logger.getLogger() need pass a Class type?
logback logback.xml常用配置详解
java日志，需要知道的几件事(commons-logging,log4j,slf4j,logback)
logback 配置详解
logback为单独的包配置日志输出文件
Apache Log4j 2.0值得升级吗