- JAVA日志系统的演变史
我们先看一个故事。项目经理A带着一帮兄弟开发了一套复杂的企业ERP系统，这个系统一连开发了好几年，开发人员也换了好几拨。
阶段一：最开始的时候，项目经理A安排小B在系统中添加日志功能，在控制台上打印一些必要的信息。最开始的时候，由于项目的功能比较少，于是小B就是用System.out.println的方式打印日志信息。经理A感觉这样使用比较方便，也便于项目小组人员的使用，于是就沿用了下来。
阶段二：此时小B被借调到其他项目，小C加入到了项目组中。此时项目经理A要求改造日志系统，要求能把日志写到一个文件中，方便以后分析用户行为。小C在查看了以前的日志方式之后，感觉特别low，于是自己写了一个日志框架，命名为xiaoC-logging.jar，此举收到了项目经理A的好评。
阶段三：项目组中加入了一个大牛老D，老D发现xiaoC-logging.jar这个日志框架虽然可以满足基本的日志要求，但是还不够高大上，没有一些诸如自动归档，异步写入文件，把日志文件写入NoSQL数据库中等功能。于是老D开发了一个更高级的日志框架叫oldD-logging.jar。
阶段四：oldD-logging.jar开发完成之后，需要把原来的xiaoC-logging.jar中的日志API做修改，把之前的日志实现写下来，换上高大上的oldD-logging.jar。
阶段五：在这个卸载与上新的过程中，老D的工作量陡增，他感觉很累。不过姜还是老的辣，他参考了JDBC和spring中面向接口的编程方式，制定了一个日志的门面（一系列的接口），以后所有的日志的记录，都只面向接口编程，至于今后怎么去实现，都要遵循这个接口就可以了。
那么在JAVA开发中，这正的日志系统是怎么演变的呢？简短地描述下日志发展，最先出现的是apache开源社区的log4j，这个日志确实是应用最广泛的日志工具，成为了java日志的事实上的标准。然而，当时Sun公司在jdk1.4中增加了JUL日志实现，企图对抗log4j，但是却造成了混乱，这个也是被人诟病的一点。当然也有其他日志工具的出现，这样必然造成开发者的混乱，因为这些日志系统互相没有关联，替换和统一也就变成了比较棘手的一件事。想象下你的应用使用log4j，然后使用了一个其他团队的库，他们使用了JUL，你的应用就得使用两个日志系统了，然后又有第二个库出现了，使用了simplelog。这个时候估计让你崩溃了，这是要闹哪样？这个状况交给你来想想办法，你该如何解决呢？进行抽象，抽象出一个接口层，对每个日志实现都适配或者转接，这样这些提供给别人的库都直接使用抽象层即可。不错，开源社区提供了commons-logging抽象，被称为JCL，也就是日志框架了，确实出色地完成了兼容主流的日志实现（log4j、JUL、simplelog），基本一统江湖，就连顶顶大名的spring也是依赖了JCL。看起来事物确实是美好，但是美好的日子不长，接下来另一个优秀的日志框架slf4j的加入导致了更加混乱的场面。比较巧的是slf4j的作者(Ceki Gülcü)就是log4j的作者，他觉得JCL不够优秀，所以他要自己搞一套更优雅的出来，于是slf4j日志体系诞生了，并为slf4j实现了一个亲子——logback，确实更加优雅，但是由于之前很多代码库已经使用JCL，虽然出现slf4j和JCL之间的桥接转换，但是集成的时候问题依然多多，对很多新手来说确实会很懊恼，因为比单独的log4j时代“复杂”多了，抱怨声确实很多。到此本来应该完了，但是Ceki Gülcü觉得还是得回头拯救下自己的“大阿哥”——log4j，于是log4j2诞生了，同样log4j2也参与到了slf4j日志体系中，想必将来会更加混乱。接下来详细解读日志系统的配合使用问题。slf4j的设计确实比较优雅，采用比较熟悉的方式——接口和实现分离，有个纯粹的接口层——slf4j-api工程，这个里边基本完全定义了日志的接口，所以对于开发来说，只需要使用这个即可。有接口就要有实现，比较推崇的实现是logback，logback完全实现了slf4j-api的接口，并且性能也比log4j更好，同时实现了变参占位符日志输出方式等等新特性。刚刚也提到log4j的使用比较普遍，所以支持这批用户依然是必须的，slf4j-log4j12也实现了slf4j-api，这个算是对log4j的适配器。同样推理，也会有对JUL的适配器slf4j-jdk14等等。为了使使用JCL等等其他日志系统后者实现的用户可以很简单地切换到slf4j上来，给出了各种桥接工程，比如：jcl-over-slf4j会把对JCL的调用都桥接到slf4j上来，可以看出jcl-over-slf4j的api和JCL是相同的，所以这两个jar是不能共存的。jul-to-slf4j是把对jul的调用桥接到slf4j上，log4j-over-slf4j是把对log4j的调用桥接到slf4j。
日志门面和日志实现
我们需要在左边选一个门面（抽象层）、右边来选一个实现。那么最优选择就是
日志门面： SLF4J，日志实现：Logback。
SpringBoot的底层是Spring框架，Spring框架默认是用JCL。但是SpringBoot选用 SLF4j和logback；
- slf4j使用原理规则
我们进入到slf4j的官网，打开用户手册，即可看到简单的用法案例：
slf4j简单用法
当然在使用之前，需要导入slf4j的jar和 logback的实现jar，但是如果是换做其他的日志实现，需要哪些jar包的依赖呢，官方网站给我们提供了一个图：
我们看一下这个图，上面的每一列都是讲如何把slf4j（日志门面）与其他日志的实现进行整合的过程。其中浅蓝色表示抽象的日志API，即我们说的日志门面（slf4j-api.jar），深蓝色是具体的日志实现，青色表示一个日志的适配器，灰色表示和slf4j没有直接关联的日志实现。
第一列：日志门面使用的是slf4j-api.jar，但是没有任何日志实现的话，那么日志讲不会输出任何内容。
第二列：说的是slf4j和logback如何绑定。日志门面使用的是slf4j-api.jar，那么日志的实现使用logback-classic.jar和logback-core.jar。我们之前讲过，logback是slf4j的亲儿子，所以slf4j可以和logback无缝连接。
第三列：说的是slf4j和log4j如何绑定，我们知道slf4j和log4j的作者是同一个人，但是作为借口出现的slf4j出现的要比log4j晚，所以slf4j和log4j并不能无缝连接，需要一个适配层slf4j-log4j12.jar。然后这个适配器实现了slf4j-api.jar中的接口和抽象类，但是是实现还是用的log4j的API去实现。由此解决了log4和slf4j整合的问题。
第四列：说的是slf4j和JUL（java.util.logging）如何绑定，原理同第三列。
第五列：slf4j本身也提供了一个简单实现，叫做slf4j-simple.jar。二者可以无缝连接。
第六列：slf4j本身也提供了一个没有任何实现的slf4j-nop.jar。这日志没有任何操作，不会输出日志。
看懂这个图，就了解了需要导入哪些jar文件的依赖了。每一个日志的实现框架都有自己的配置文件。但是以后的日志系统里面，这么多的日志实现，应该使用什么样的日志配置文件呢，我们有个原则就是：
使用slf4j以后，配置文件还是做成日志实现框架自己本身的配置文件。- 其他日志框架统一转换为slf4j
回想我们在做ssm框架整合的时候，spring和springmvc使用的是JCL（jarkart commons-logging），mybatis使用的是log4j日志框架，有可能其他的jar文件依赖的是JCL（Java util logging），那么怎么把这些不同的的日志框架转化为同意的slf4j的日志呢，官方网站里给我们提供了一个图：
第一块：
说的是一个系统中，如果要是用slf4j作统一的日志门面，并且用logback做日志的实现，但是此时还有commons-logging、log4j、jul等日志实现怎么办呢？此时需要用jcl-over-slfj.jar替代commons-logging，用log4j-over-slf4j.jar替代log4j.jar，并且添加jul-to-slf4j.jar（不能替换掉JUL，因为这是JDK自带的）
第二块：
说的是一个系统中，如果要是用slf4j作统一的日志门面，并且用log4j做日志的实现，但是此时还有commons-logging、jul等日志实现怎么办呢？此时需要用jcl-over-slfj.jar替代commons-logging，并且添加jul-to-slf4j.jar（不能替换掉JUL，因为这是JDK自带的），并且添加slf4j和log4j的适配层slf4j-log4j12.jar以及实现层log4j.jar。
第三块：
说的是一个系统中，如果要是用slf4j作统一的日志门面，并且用JUL做日志的实现，但是此时还有commons-logging、log4j等日志实现怎么办呢？此时需要用jcl-over-slfj.jar替代commons-logging，用log4j-over-slf4j.jar替代log4j.jar，并且添加slf-jdk14.jar作为适配层，最后是用JDK自带的JUL作为日志的实现。
总结：如何让系统中所有的日志都统一到slf4j；
1、将系统中其他日志框架先排除出去；
2、用中间包来替换原有的日志框架（根据上图）；
3、我们导入slf4j其他的实现
閱讀更多 JAVA老司機 的文章
