写在前面
日志记录组件是日常开发过程中的重要组件。正确登录系统至少可以带来以下好处：
调试：在程序开发过程中，必须不断进行调试，以保证程序处于可以正确运行的状态。日志记录使开发人员能够清楚地了解程序执行状态并识别信息收集问题。在DT时代，谁管理数据，谁就掌握了控制权。目前主流的日志系统可以非常方便地记录用户行为数据，并将其格式化为方便大数据分析的格式。应用程序部署到生产中后，生产事故不可避免地是由系统日志工程师和工程师造成的。根据日志快速定位问题。当然，每枚硬币都有两个面。部署日志组件并非没有缺点。
代码冗余：从业务逻辑实现的角度来看，无需在应用程序中插入任何日志代码来打印大量日志。这在一定程度上降低了代码的可读性，降低了系统性能。由于需要进行日志输出处理，系统运行速度肯定会变慢。综合比较日志组件的优缺点后，我们发现日志组件的引入还是非常有必要的。
平时开发过程中常用的日志组件有Log4J、Log4J2、LogBack等。在您的代码中，您通常像这样使用它：
导入org.slf4j.Logger;导入org.slf4j.LoggerFactory;导入org.springframework.boot.SpringApplication;导入org.springframework.boot.autoconfigure.SpringBootApplication;@SpringBootApplication@EnableAdminServerpublic 类AppQuickStart { 私有静态Logger 记录器=LoggerFactory.getLogger( AppQuickStart.class); public static void main(String[] args) { System.out.println(Thread.currentThread().getName()); run(AppQuickStart.class, args);'）; 或者：
导入org.apache.commons.logging.Log;导入org.apache.commons.logging.LogFactory;导入org.springframework.boot.SpringApplication;导入org.springframework.boot.autoconfigure.SpringBootApplication;@SpringBootApplication@EnableAdminServerpublic 类AppQuickStart { 私有静态最终日志记录器=LogFactory.getLog(AppQuickStart.class); public static void main(String[] args) { System.out.println(Thread.currentThread().getName());run(AppQuickStart.class, args); logger.info('app start success.'); 上面的两段代码非常相似。唯一的区别是，第一段代码引入了SLF4J Jar包，第二段代码引入了common-logging Jar包（以下简称JCL）。
当我第一次接触日志组件时，我对如何使用它感到非常困惑。我不应该使用Log4J 或LogBack 进行日志记录吗？为什么我没有看到Log4J和LogBack的踪影，却看到了两个新的？ SLF4J 框架和通用日志记录怎么样？
那么这两个框架到底是做什么的呢？Log4J、Log4J2和LogBack之间有什么关系呢？如果你也有这样的疑问，那就不是你还在思考的了。今天的文章，我会介绍一下JCL、SLF4J、Log4J、Log4J2、LogBacky、JUL之间的关系（JUL的存在感很低，哈哈）。
门面模式
如果你学过设计模式，你就会知道23种设计模式之一叫做门面模式。
上面是门面模式的配置图。
这个结构图展示了两个角色：
Facade角色：客户端可以调用该角色的方法。该角色识别相关子系统的功能和职责。一般情况下，该角色将所有客户端发送的请求委托给相应的子系统。子系统角色：一个或多个子系统可以同时存在。每个子系统都是类的集合而不是单个类（例如，上面的子系统由三个类组成：ModuleA、ModuleB 和ModuleC）。每个子系统都可以由客户端或外观角色直接调用。子系统不知道外观的存在。对于子系统来说，外观只是另一个客户端。使用外观模式的好处包括：
松耦合的：门面模式放松了客户端与子系统之间的耦合关系，使得子系统内的模块的扩展和维护更加容易。门面模式简单易用，客户端无需了解子系统的内部实现，无需与子系统的众多内部模块进行交互。门面类。更好地划分访问级别： 合理使用Facade可以更好地划分访问级别。有些方法在系统外部使用，而另一些则在系统内部使用。将需要对外暴露的功能集中到立面中，不仅更方便客户端使用，也能更好地隐藏内部细节。
JCL 和 SLF4J
为什么上面要介绍facade模式呢？因为现在所有主流的日志组件都是使用facade模式实现的。 JCL和SLF4J是门面模式中的门面角色。
JCL官网JCL介绍：
Logging 包是不同日志记录实现之间的超薄桥梁。使用commons-logging API 的库可以在运行时被任何日志记录实现使用，并且支持许多常见的日志记录实现和适配器创建。对于其他人来说，这是一项相当容易的任务。 ——JCL官网。
上面的英文的一般意思是： JCL是不同日志记录实现之间的“桥梁”，支持许多主流日志记录实现。而且，自己编写JCL适配代码也非常容易。
SLF4J概述：
Simple Logging Facade for Java (SLF4J) 充当各种日志框架（例如java.util.logging、logback、log4j 等）的简单外观或抽象，允许最终用户在部署期间插入他们所需的日志框架。允许您进入。网站
上面的英文的一般意思是： SLF4J 充当各种日志框架的外观，允许用户在底层日志实现之间自由切换。
从上面的讨论可以看出，JCL和SLF4J都是日志门面，而Log4J、Log4J2和LogBack都是子系统角色（SunSystem）和具体的日志实现框架。他们的关系是：
使用日志门面部署日志组件的最大优点是系统和具体日志实现框架之间的分离。
如果您不使用日志外观，而是直接使用特定日志框架（例如Log4J）的API 进行编程，并且您的系统始终使用Log4j 作为日志实现，则必须在每个类中组合Log4J API。你必须这样做。没关系。有一天，你的老板一时兴起，觉得Log4J不能满足你的系统需求（这只是个栗子，Log4J还是很强大的^_^），他告诉你用其他一些日志实现来替换Log4J。我想你现在有点困惑。这是因为您需要修改每个类中组合的Log4J API。
如果使用JCL 或SLF4J 等日志外观有助于解决此问题，则无需更改代码，只需更改日志实现框架即可。
Log4J、Log4J2和LogBack的有趣历史
使用过Log4J和LogBack的同学无疑会发现，这两个框架的设计理念非常相似，使用方式也一模一样。
事实上，这两个框架的创建者是一位名叫Ceki Glc 的俄罗斯程序员。
Log4J最初是一个基于Java开发的日志框架。经过一段时间的开发，作者Ceki Glc 将Log4j 捐赠给了Apache 软件基金会，并将其作为Apache Logging Service 的子项目。 Log4J 的卓越性能从此催生了支持C、C++、C#、Perl、Python、Ruby 和其他语言的子框架。
但优秀的程序员似乎更有个性。 Ceki Glc 对Apache 对Log4J 的管理感到不满，决定不再参与Log4J 的开发和维护。 “退休”后，Ceki Glc 重新开始并开发了LogBack 框架（SLF4J 是与LogBack 一起开发的）。
LogBack改进了Log4J的许多缺点，显着提高了性能。与此同时，许多用户开始使用LogBack。
由于LogBack的影响，Log4J开始衰落。最后，2015 年9 月，Apache 软件基金会宣布Log4j 已达到维护结束，并建议所有相关项目升级到Log4j2。
Log4J2是Apache开发的一个新的日志框架，改进了Log4J的许多缺点，据说在性能方面优于LogBack。有兴趣的朋友可以测试一下两者的性能。
顺便说一下，这里提到了JUL日志组件。这个日志组件是JDK自带的日志框架。由于其易用性和较差的性能，它的存在感一直不高。
简单总结
JCL和SLF4J都是日志门面，使用它们引入日志组件的目的是Log4J、Log4J2、LogBack和JUL都是具体的日志实现。如果使用，请与立面原木一起使用。
版权声明：本文由今日头条转载，如有侵犯您的版权，请联系本站编辑删除。