【开发经验】日志框架分类和选择

1、起源

        在很多开发者都会有一个习惯，在程序的重要步骤打印关键的信息。通过这种方式可以在看出程序的执行状态，在程序遇到问题时，可以进行快速定位。在没有日志框架出现之前，开发者是通过System.out等方式进行日志信息的打印。这种方式有一些很明显的弊端：

1. 效率低下，如果打印的日志较多会影响程序速度
2. 不灵活，日志的格式，日志文件保存的位置不好修改。
3. 也许想在测试环境打印较多的日志，在生产环境会去掉部分日志。

        就如上的一些列问题，慢慢的出现了日志框架。日志框架的功能很简单，无非是打印日志。于是作者变想到了门面模式。在开发的时候，开发者选用门面进行调用方法，即可进行打印。通过引用不同的jar包进行不同的实现。

2、日志框架选择

日志门面（抽象层）	实现类
JCL（Jakarta Commons Logging）、 SLF4j（Simple Logging Facade for Java）、 jboss-logging	Log4j、 JUL（java.util.logging）、Log4j2 、Logback

        展示了常有的日志门面和日志实现，由于JCL 现在已经不在更新。jboss-logging 一般不在业务开发中使用此框架。因此一般SpringBoot业务开发中会优先去使用SLF4j门面。

        SLF4j、Log4j、Logback是出自同一个人之手，Logback是Log4j的升级版本。因此，一般在SpringBoot开发中，一般会使用SLF4j+Logback进行日志打印。

注：Log4j2和Log4j只是名字类似一样，其实并没有特别大的联系。

3、SLF4j使用问题

        在SpringBoot开发中，需要调用SLF4j的门面方法进行日志打印，否则这种门面模式就毫无意义。

        就上图来说，application为我们的应用程序，在此可以认为是SpringBoot工程。从左到右依次解释：

1. 当引用SLF4j的包时，虽然是可以进行日志的打印，但是最终会打印到一个空的位置，/dev/null是linux的一个空的文件夹，这个会在稍后解释，总之就是不保存。
2. 如果想使用logback为项目的日志框架时，可以应用logback的jar即可。SLF4j和logback就是一个配套使用的。
3. 如果想使用log4j，这就有点尴尬了，因为log4j出生比较早，在log4j编码的时候，就没有想过要适配SLF4j。因此，如果想使用SLF4j+log4j时，需要加一个适配层，引入slf4j-log412.jar进行适配。
4. 后面三个用的不多，不在过多阐述。

4、兼容性问题

        也许我们的项目中使用logback日志框架，但是并不能要求其它的代码也用这个框架。就好比 Spring（commons-logging）、Hibernate（jboss-logging）还有MyBatis等等。这种千奇百怪的日志框架，肯定都要被我们项目中使用的日志框架适配。

如何让系统中所有的日志都统一到slf4j？

1、将系统中其他日志框架先排除出去；如果使用commons-logging.jar则替换为jcl-over-slf4j.jar以此类推。
2、用中间包来替换原有的日志框架；
3、我们导入slf4j其他的实现

问题：如果使用commons-logging.jar则替换为jcl-over-slf4j.jar，编译的时候不会报错吗？

        像jcl-over-slf4j.jar是一个适配的jar，通过这个jar有commons-logging.jar的所有类和方法，但是修改了其实现。如下图，jcl的包名和类名与commons-logging的一样，这样就不会编译报错了。

通过这种偷梁换柱的方式，将核心jar的代码进行替换，达到替换其原有日志框架的实现。

附录

门面模式

        在一个接口有多种实现方式的时候，使用门面模式可以很好的划分代码。比如，数据库连接类javax.sql.DataSource，这是一个官方的连接接口。各个数据库的厂家想要通过java代码连接数据库时，可以实现这个接口。如：mysql的实现类为com.mysql.cj.jdbc.MysqlDataSource。