目前最全的日志框架详解，你要的全都有

日志框架概述

什么是日志

1. 在日常开发中，程序并不会每一次都向着我们设想的方向运行出结果，这个时候就想搞清楚程序哪一步具体是什么状态，便于我们排查问题。你可能会想到直接在控制台 system.out 输出结果，但如果系统上线， system.out 会带来严重的新能问题。显然是不可取的
2. 已经上线的系统，如果发生令人意想不到的bug，我们需要一些信息为我们排查追溯复现问题提供依据。

日志文件是用于记录系统操作事件的文件集合，很多时候，日志可能是我们了解应用程序如何执行的唯一方式。

现有的日志框架

JUL（java util logging）、logback、log4j、log4j2

JCL（Jakarta Commons Logging）、slf4j（ Simple Logging Facade for Java）

日志门面

JCL、slf4j

日志实现

JUL、logback、log4j、log4j2

JCL目前已被slf4j代替，JUL是java原生的日志一般不用，log4j一些老系统还在使用

重点关注slf4j，logback，log4j2

这里我已经给大家整理了目前常用的日志框架详解

1. [日志框架]JCL
2. [日志框架]JUL
3. [日志框架]og4j
4. [日志框架]log4j2
5. [日志框架]logback
6. [日志框架]slf4j
7. [日志框架]springboot中使用的log框架

日志门面技术

什么是门面模式

计算机程序设计中有一句至理名言：没有什么是抽象一层不能解决的，如果有那就再抽象一层。

当我们的系统变的更加复杂的时候，我们的日志就容易发生混乱。随着系统开发的进行，可能会更新不同的日志框架，造成当前系统中存在不同的日志依赖，让我们难以统一的管理和控制。就算我们强制要求所有的模块使用相同的日志框架，系统中也难以避免使用其他类似spring,mybatis等其他的第三方框架，它们依赖于我们规定不同的日志框架，而且他们自身的日志系统就有着不一致性，依然会出来日志体系的混乱。

所以我们需要借鉴JDBC的思想，为日志系统也提供一套门面，那么我们就可以面向这些接口规范来开发，避免了直接依赖具体的日志框架。这样我们的系统在日志中，就存在了日志的门面和日志的实现。

核心为外部与一个子系统的通信必须通过一个统一的外观对象进行，使得子系统更易于使用。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-u74CvuQz-1615384752611)(…/resources/801753-20180321204740208-1670144043.png)]

为什么使用门面模式

1. 面向接口开发，不再依赖具体的实现类。减少代码耦合
2. 项目通过导入不同的日志实现类，可以灵活的切换日志实现框架
3. 统一API，方便开发者学习和使用
4. 统一配置便于项目日志的管理

日志门面的一个比较重要的好处解耦

场景一：

我们自己的系统中使用了logback这个日志系统
我们的系统使用了A.jar，A.jar中使用的日志系统为log4j
我们的系统又使用了B.jar，B.jar中使用的日志系统为slf4j-simple

这样，我们的系统就不得不同时支持并维护logback、log4j、slf4j-simple三种日志框架，非常不便。

如果能有一个适配层，我们直接操作适配层，由适配层决定使用哪一种日志系统，而调用端只需要做的事情就是打印日志而不需要关心如何打印日志。

场景二：

一些比较老的系统任然使用的log4j
由于业务发展，我们不得不把日志框架升级到logBack
但是log4j和logback的配置和使用不完全相同，每个地方都修改将会是一个庞大的需求。

如果有个框架，无论我们更换怎样的底层日志实现，只要遵循一定的使用规则，就能自动做到日志的切换，那就是slf4j

​ 为了解决这写问题，就是在日志框架和应用程序之间架设一个沟通的桥梁，对于应用程序来说，无论底层的日志框架如何变，都不需要有任何感知。只要门面服务做的足够好，随意换另外一个日志框架，应用程序不需要修改任意一行代码，就可以直接上线。

下面是SLF4j与各种日志框架的绑定规则

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LoBLvQgh-1615384752613)(…/resources/Image-1615305788412.png)]

任意一行代码，就可以直接上线。

下面是SLF4j与各种日志框架的绑定规则

SLF4j具体如何使用，请见slf4j详解