学习Java日志
本文公众号来源:程序猿阿星
作者:程序猿阿星
本文已收录至我的GitHub
今天来和大家聊聊Java
日志体系,Java
日志体系可以说是五花八门,眼花缭乱。
导致很多小伙伴因为日志标准库之间复杂的关系而感到烦恼,不知道统一系统的日志标准库需要依赖哪些jar
包,百度一下所谓的博客,照着人家复制,却无法弄懂原理,甚至还有搞了半天项目因jar
冲突跑不起来的,心态直接爆炸。
咳咳,淡定淡定,别慌,我带你们弄懂其中的原理,只要你静下心,跟着本文来,再给个一键三连,你就能随心所欲的更改日志标准库,统一日志输出。
发展史
我们要正确的配置好日志,让jar
相互生效,就要先理清关系,理清关系就得从它的发展史下手。
System.out和System.err
2001
年以前,Java
是没有日志库的,打印日志全凭System.out
和System.err
,我人都傻了,十分离谱。
缺点如下:
产生大量的IO操作 同时在生产环境中 无法合理的控制是否需要输出 输出的内容不能保存到文件 只打印在控制台,打印完就过去了,也就是说除非你一直盯着程序跑 无法定制化,且日志粒度不够细
Log4j
此时名为Ceki
的巨佬站出来,说你这个不好用,我这个好用,接着在2001
年掏出了Log4j
,用起来也确实比System
系列香,Log4j
一度成为业内日志标准。
后来Log4j
成为Apache
项目,Ceki
也加入Apache
组织(据说Apache
还曾经建议Sun
引入Log4j
到Java
的标准库中,但Sun
拒绝了)。
JUL(Java Util Logging)
原来Sun
也有自己的盘算,不就一个日志嘛,我自己也搞一个,2002
年2
月JDK1.4
发布,Sun
推出了自己的日志标准库JUL(Java Util Logging)
,其实是照着Log4j
抄的,而且还没抄好,还是在JDK1.5
以后性能和可用性才有所提升。
因为在JUL
出来以前,Log4j
就已经成为一项成熟的技术,使得Log4j
在选择上占据了一定的优势。
JCL(Jakarta Commons Logging)
现在市面上有两款Java
日志标准库,分别是Log4j
与JUL
,此时Apache
组织十分有想法,想统一抽象日志标准接口规范(就像JDBC
统一数据库访问层),让其他日志标准库去实现它的抽象接口,这样你的日志操作都是统一的接口。
于是JUL
刚出来不久,2002
年8
月Apache
推出了JCL(Jakarta Commons Logging)
,也就是日志抽象层,支持运行时动态加载日志组件的实现,当然也提供一个默认实现Simple Log
(在ClassLoader
中进行查找,如果能找到Log4j
则默认使用log4j
实现,如果没有则使用JUL
实现,再没有则使用JCL内部提供的Simple Log
实现)。
但是JUL
有三个缺点
效率较低 容易引发混乱 使用了自定义ClassLoader的程序中,使用JCL会引发内存泄露
总之就是问题也挺多~
Slf4j(Simple Logging Facade for Java)
2006
年巨佬Ceki
(Log4j
的作者)因为一些原因离开了Apache
组织,之后Ceki
觉得JCL
不好用,自己撸了一套新的日志标准接口规范Slf4j(Simple Logging Facade for Java)
,也可以称为日志门面,很明显Slf4j
是对标JCL
,后面也证明了Slf4j
比JCL
更优秀。
由于Slf4j
出来的较晚,光有一个接口,没有实现的日志库也很蛋疼,如JUL
和Log4j
都是没有实现Slf4j
,就算开发者想用Slf4j
也用不了。
这时候巨佬Ceki
发话了,Sum
和Apache
这两个组织不来实现我的接口没关系,我来实现就好了,只有魔法才能打败魔法。
后面巨佬Ceki
提供了一系列的桥接包来帮助Slf4j
接口与其他日志库建立关系,这种方式称为桥接设计模式。
有了桥接包配合,其他的问题都迎刃而解,我们先看看有那些问题吧~
从上图可以看出,不同时期的项目使用的日志标准库不一样,我们以Slf4j
接口作为划分线,考虑两个问题,一个是Slf4j
之前的项目怎么统一日志标准,另一个是Slf4j
之后的项目怎么统一日志标准。
先来看Slf4j
之后的项目怎么统一日志标准,项目D、E
都使用Slf4j
接口,首先在代码层已经统一了,如果要做到日志标准统一也十分简单,直接替换日志标准库与对应的桥接包即可,就如下图所示
好家伙,Slf4j
接口配合桥接包简直无敌了,灵活配置。。
再来看Slf4j
之前的项目怎么统一日志标准,项目A、B、C
都使用了不同的日志标准,所以它们的API
不一样,如果要统一标准,首先就要改动代码,这样侵入太强了,难道就没有办法在不改代码的情况下,让A、B、C
项目统一日志标准吗?
办法当然有,Slf4j
接口能通过桥接包勾搭上具体的日志标准库,为什么日志标准库不能通过桥接包勾搭Slf4j
接口呢?
想把A、B、C
项目都统一成Log4j
日志输出,只需要做如下调整
是不是很简单,引入Slf4j
与相关的桥接包,再引入具体的日志标准库,比如Log4j
,就完成了3
个项目的统一日志标准,对代码层是零入侵。
Logback
Ceki
巨佬觉得市场上的日志标准库都是间接实现Slf4j
接口,也就是说每次都需要配合桥接包,因此在2006
年,Ceki
巨佬基于Slf4j
接口撸出了Logback
日志标准库,做为Slf4j
接口的默认实现,Logback
也十分给力,在功能完整度和性能上超越了所有已有的日志标准库。
目前Java
日志体系关系图如下
Log4j2
自从Logback
出来后,可以说Slf4j+Logback
组合如日中天,很冲击JCL+Log4j
组合,Apache
眼看有被Logback
反超的势头。
于2012
年,Apache
直接推出新项目Log4j2
(不兼容Log4j
),Log4j2
全面借鉴Slf4j+Logback
(十分明显的抄袭嫌疑)。
因为Log4j2
不仅仅具有Logback
的所有特性,还做了分离设计,分为log4j-api
和log4j-core
,log4j-api
是日志接口,log4j-core
是日志标准库,并且Apache
也为Log4j2
提供了各种桥接包。。。
到目前为止Java
日志体系被划分为两大阵营,分别是Apache
阵营和Ceki
j阵营,如下图所示
至于系统中用那套体系,各位自行选择,个人偏向用Ceki
提供的Slf4j
那套
Slf4j的桥接包介绍
相信大家都对桥接包都有了基本概念,这里罗列下与Slf4j
配合使用的桥接包
Slf4j
转向某个日志标准库
slf4j-jdk14.jar
Slf4j
到JUL
的桥梁slf4j-log4j12.jar
Slf4j
到Log4j
的桥梁log4j-slf4j-impl.jar
Slf4j
到Log4j2
的桥梁slf4j-jcl.jar
Slf4j
到JCL
的桥梁
某个实际日志框架转向Slf4j
jul-to-slf4j.jar
JUL
到Slf4j
的桥梁log4j-over-slf4j.jar
Log4j
到Slf4j
的桥梁jcl-over-slf4j.jar
JCL
到Slf4j
的桥梁
小小实践
从事Java
开发的伙伴们都清楚,Spring
框架内部使用JCL
做日志输出标准,可是项目使用Slf4j + Logback
做日志输出标准,问题来了,怎样才能让项目内的Spring
保持统一日志输出标准呢?
其实非常简单,只需要引入正确的Slf4j
桥接包,去除无用的日志组件即可。
我没骗你们吧,引入jcl-over-slf4j.jar
或jul-to-slf4j.jar
问题就解决了,十分简单~
小结
本文到此就结束了,以上,通过Java
日志发展史一步一步的带大家理清Java
日志间的关系,并抛出问题以及解决问题,相信看完后,大家不会再因为日志标准库之间复杂的关系感到烦恼,同时也能知其所以然的统一日志标准。
《对线面试官》系列目前也已经连载21篇啦!有深度风趣的系列!
【对线面试官】Java注解 【对线面试官】Java泛型 【对线面试官】 Java NIO 【对线面试官】Java反射 && 动态代理 【对线面试官】多线程基础 【对线面试官】 CAS 【对线面试官】synchronized 【对线面试官】AQS&&ReentrantLock 【对线面试官】线程池 【对线面试官】ThreadLocal 【对线面试官】CountDownLatch和CyclicBarrier 【对线面试官】List 【对线面试官】Map 【对线面试官】SpringMVC 【对线面试官】Spring基础 【对线面试官】SpringBean生命周期 【对线面试官】Redis基础 【对线面试官】Redis持久化 【对线面试官】Kafka基础 【对线面试官】使用Kafka会考虑什么问题?