前言:
当前朋友们对“java log日志”可能比较注意,咱们都需要分析一些“java log日志”的相关内容。那么小编也在网络上网罗了一些有关“java log日志””的相关资讯,希望小伙伴们能喜欢,各位老铁们快快来了解一下吧!1 简介
本文主要探究以下内容:
介绍 Java 日志体系发展历程介绍 slf4j 日志门面,并梳理现有日志体系之间的关系及依赖2 日志体系发展历程
在日常工作中可以看到项目中依赖的跟日志相关的 jar 包有很多,commons-logging.jar、log4j.jar、slf4j-api.jar、logback.jar 等等,眼花缭乱。要理清它们之间的关系,首先要从 Java Log 的发展历程说起。
1.log4j
log4j(作者 Ceki Gülcü)出来时就得到了广泛的应用,是 Java 日志事实上的标准,并成为了 Apache 的项目。
2.JUL
log4j 作为 Apache 基金会的一员,Apache 希望将 log4j 引入 jdk,不过被 sun 公司拒绝了。随后,sun 模仿 log4j,在 jdk1.4 中实现了 JUL 即 java.util.logging。
3.JCL
JUL 毕竟是 JDK 自带的,也有很多人用。同时还有其他日志组件,如 SimpleLog 等。这时如果有人想换成其他日志组件,如 log4j 换成 JUL,因为 API 完全不同,就需要改动代码。
为了将日志接口与实现解耦,Apache 推出了 JCL 即 Apache Commons Logging。JCL 只定义了一套日志接口,具体实现由 log4j 或 JUL 来完成。JCL 基于动态绑定来实现日志的记录,在使用时只需要用 JCL 定义的接口来编写代码即可,程序真正运行时会检查 classpath 中的具体实现,因此可以自由选择是由 log4j 还是 JUL 来实现日志功能。
4.slf4j&logback
这样看上去也挺美好的,但是 log4j 的作者(Ceki Gülcü)觉得 JCL 不好用,便接着开发出了 slf4j,它跟 JCL 类似,本身不替供日志具体实现,只对外提供接口或门面。目的就是为了替代 JCL。同时,还开发出 logback,一个比 log4j 拥有更高性能的组件,目的是为了替代 log4j。
5.log4j2
最后,Apache 为了避免 slf4j 和 logback 慢慢取代 JCL 和 log4j,推出了自己的反击之作 log4j2,相比 log4j 其性能获得了很大的提升。于是,我们就看到了如此多的日志框架并存的局面。
注:log4j2 目前是 Java 中最优秀的日志框架。
3 关系/依赖
大概了解了发展历程后,再详细看看它们之间的关系、依赖。
3.1 JCL
commons-logging 已经停止更新,最后的状态如下所示:
JCL 支持的日志组件不多,并且现在用的人越来越少,就不多讲了。
3.2 slf4j桥接到具体的日志框架
下图来自官方文档:
由上图可以看到 slf4j 几乎可以使用所有的具体日志框架。
上图释义如下:
绿色的 application:应用层,向下可直接调用 slf4j 提供的 API浅蓝色的 abstract logging api:抽象 API 层深蓝色的 native implementation of slf4j-api:具体日志框架实现层,不需要适配器,本身已经实现了 slf4j-api湖蓝色的 adaptation layer:适配层,也就是桥接器灰色的 non-native implementation of slf4j-api:具体日志框架实现层,本身没有实现 slf4j-api,需要桥接器
第三层所有灰色的 jar 包都带有红框,这表示它们都直接实现了 slf4j-api,只是湖蓝色的桥接器对 slf4j-api 的实现并不是直接输出日志,而是转去调用别的日志框架声明的 API。
slf4j-simple.jar 和 slf4j-nop.jar 这两个不用多说,看名字就知道一个是 slf4j 的简单实现,一个是 slf4j 的空实现,平时用处也不大。而 logback 之所以也实现了 slf4j-api,就是因为 logback 和 slf4j 出自同一人之手。
3.3 具体的日志框架桥接到slf4j
除了从 slf4j 到其他日志框架的桥接器,还有另外一类桥接器,它们的作用跟上面的恰好相反,它们能将其它日志框架的 API 转调到 slf4j 的 API 上。
下图来自官方文档:
上图展示了能安全地从别的日志框架 API 转调回 slf4j 的三种情形。要想实现转调,方法就是图上列出的用特定的桥接器 jar 替换掉原有的日志框架 jar。
以左上角第一种情形为例:当 slf4j 底层使用的具体实现是 logback 时,上层允许桥接到 slf4j 的日志框架 API 有 log4j 和 JUL。JCL 虽然不是什么日志框架的具体实现,但它的 API 仍然能够被转调回 slf4j。
看完三种情形以后,会发现几乎所有其他日志框架的 API,包括 JCL 的 API,都能够随意的转调回 slf4j。但是这里要十分注意,有一个限制就是转调回 slf4j 的日志框架不能跟 slf4j 当前使用的具体日志实现框架相同。这个限制主要为了防止 A-to-B.jar 跟 B-to-A.jar 同时出现在类路径中,从而导致 A 和 B 一直不停地互相递归调用,最后导致堆栈溢出。
举个栗子,假设日志框架采用 slf4j+log4j。一个具体的日志操作过程如下:
首先调用 slf4j 的 API 接口,然后 slf4j 将请求转发给 slf4j-log4j12 来处理,这个是在编译期间静态绑定好的。最后 slf4j-log4j12 通过 log4j 来完成日志操作。此时项目中如果再加一个 log4j-over-slf4j 会怎样?如下图,日志请求会重新打回给 slf4j,从而形成一个环形。
作者:_dhengyi
链接:
标签: #java log日志