龙空技术网

一文看懂Java日志框架体系

51CTO 488

前言:

当前朋友们对“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日志