spring Boot必用依赖框架

Logback和log4j是非常相似的，如果你对log4j很熟悉，那对logback很快就会得心应手。下面列了logback相对于log4j的一些优点：

更快的实现

Logback的内核重写了，在一些关键执行路径上性能提升10倍以上。而且logback不仅性能提升了，初始化内存加载也更小了。

非常充分的测试

Logback经过了几年，数不清小时的测试。Logback的测试完全不同级别的。在作者的观点，这是简单重要的原因选择logback而不是log4j。

Logback-classic非常自然实现了SLF4j

Logback-classic实现了SLF4j。在使用SLF4j中，你都感觉不到logback-classic。而且因为logback-classic非常自然地实现了SLF4J，所以切换到log4j或者其他，非常容易，只需要提供成另一个jar包就OK，根本不需要去动那些通过SLF4JAPI实现的代码。

非常充分的文档

官方网站有两百多页的文档。

自动重新加载配置文件

当配置文件修改了，Logback-classic能自动重新加载配置文件。扫描过程快且安全，它并不需要另外创建一个扫描线程。这个技术充分保证了应用程序能跑得很欢在JEE环境里面。

Lilith

Lilith是log事件的观察者，和log4j的chainsaw类似。而lilith还能处理大数量的log数据

谨慎的模式和非常友好的恢复

在谨慎模式下，多个FileAppender实例跑在多个JVM下，能够安全地写道同一个日志文件。RollingFileAppender会有些限制。Logback的FileAppender和它的子类包括RollingFileAppender能够非常友好地从I/O异常中恢复。

配置文件可以处理不同的情况

开发人员经常需要判断不同的Logback配置文件在不同的环境下（开发，测试，生产）。而这些配置文件仅仅只有一些很小的不同，可以通过,和来实现，这样一个配置文件就可以适应多个环境。

Filters（过滤器）

有些时候，需要诊断一个问题，需要打出日志。在log4j，只有降低日志级别，不过这样会打出大量的日志，会影响应用性能。在Logback，你可以继续保持那个日志级别而除掉某种特殊情况，如alice这个用户登录，她的日志将打在DEBUG级别而其他用户可以继续打在WARN级别。要实现这个功能只需加4行XML配置。可以参考MDCFIlter

SiftingAppender（一个非常多功能的Appender）

它可以用来分割日志文件根据任何一个给定的运行参数。如，SiftingAppender能够区别日志事件跟进用户的Session，然后每个用户会有一个日志文件。

自动压缩已经打出来的log

RollingFileAppender在产生新文件的时候，会自动压缩已经打出来的日志文件。压缩是个异步过程，所以甚至对于大的日志文件，在压缩过程中应用不会受任何影响。

堆栈树带有包版本

Logback在打出堆栈树日志时，会带上包的数据。

自动去除旧的日志文件

通过设置TimeBasedRollingPolicy或者SizeAndTimeBasedFNATP的maxHistory属性，你可以控制已经产生日志文件的最大数量。如果设置maxHistory为12，那那些log文件超过12个月的都会被自动移除。

总之，logback比log4j太优秀了，让我们的应用全部建立logback上吧

<configuration>

<property name="USER_HOME" value="/home/sebastien" />

<appender name="FILE" class="chqoslogbackcoreFileAppender">

<file>${USER_HOME}/myApplog</file>

<encoder>

<pattern>%msg%n</pattern>

</encoder>

</appender>

<appender name="FILEBACK" class="chqoslogbackcoreFileAppender">

<file>${USER_HOME}/myApp_baklog</file>

<encoder>

<pattern>%msg%n</pattern>

</encoder>

</appender>

<root level="debug">

<appender-ref ref="FILE" />

<appender-ref ref="FILEBACK" />

</root>

</configuration>

2场景二：想将一个web项目部署在同一台机器上的两个web容器中，但是同时日志又想单独输出。

解决办法：给web容器启动脚本一个不同的参数，设置输出目录，让logback去读

启动脚本加入 java -DUSER_HOME="/home/sebastien" JavaWeb

<configuration>

<appender name="FILE" class="chqoslogbackcoreFileAppender">

<file>${USER_HOME}/myApplog</file>

<encoder>

<pattern>%msg%n</pattern>

</encoder>

</appender>

<root level="debug">

<appender-ref ref="FILE" />

</root>

</configuration>

3场景三：想给日志文件每次一个相对唯一的名字。

解决办法：使用时间戳作为文件名

<configuration>

<!-- Insert the current time formatted as "yyyyMMdd'T'HHmmss" under

the key "bySecond" into the logger context This value will be

available to all subsequent configuration elements -->

<timestamp key="bySecond" datePattern="yyyyMMdd'T'HHmmss"/>

<appender name="FILE" class="chqoslogbackcoreFileAppender">

<!-- use the previously created timestamp to create a uniquely

named log file -->

<file>log-${bySecond}txt</file>

<encoder>

<pattern>%logger{35} - %msg%n</pattern>

</encoder>

</appender>

<root level="DEBUG">

<appender-ref ref="FILE" />

</root>

</configuration>

一次典型的日志冲突排查

问题背景

在 A 工程中，日志框架配置选用了 Log4j2，master 分支上日志打印正常，但开发分支增加了代码之后日志打印不出来。项目的依赖中包含了 Log4j2、Logback 等日志框架。

排查思路与过程

排查问题的时候首先必须要有明确的思路，即大胆假设，小心求证，不能像无头苍蝇一样乱试。从问题的现象看，直觉上可以得出几个假设：

服务器环境有问题

开发分支的 Log4j2 配置有问题

接下来就是验证假设，首先多申请几台机器部署项目分支，发现问题仍然存在，可以排除第一个假设。其次找到另一个工程 B 跟 A 工程对比 Log4j2 的配置，也没有发现明细的差异，可以排除第二个假设。

在已有假设都验证失败的情况下，需要收集更多的信息作出判断，接下来就是要用对照实验收集信息。于是我分别断点了 A 和 B 两个工程，观察它们日志实体的类型是否一致。结果发现两者的日志实体类型不一样，A 的日志实现是 Logback，B 的日志实现是 Log4j2，很明显 A 打印不出日志是因为日志实体不对，但是两者都是用的同一个 LoggerFactory 创建 Logger 的。

从对照实验的结果来看，可以得出一个假设：依赖冲突导致了 A 运行时使用日志实体不是 Log4j2。

至此我们已经找到了问题的大致方向，接下来就是要排包。排包一般有两种思路：

暴力求解：把所有可能冲突的日志包排掉，一个个试。

精准爆破：利用类加载的信息判断运行时加载的具体是哪个 jar

暴力求解的方式太花费时间了，所以我用的第二种方式。

获取日志实体的方式如下：

private static final Logger LOGGER = LoggerFactory getLogger(xxxclass);

复制

LoggerFactory 的代码如下：

从代码上可以发现，getLog方法是来自父类LogFactory，当我去尝试获取LogFactory的实现时候，发现竟然有 3 个 jar 中都有同样包名的LogFactory实现。于是我断点了 A 和 B 工程的代码，用 IDEA 的运行代码功能执行以下命令获取LogFactory的加载信息。

结果发现 B 工程使用是spring-jcl，A 使用的是jcl-over-slf4j，然后排除掉 A 中jcl-over-slf4j，问题解决。

上面的排查过程中，关键的地方有两点：

定位到问题的根源是类加载冲突，确定排查方向。

通过断点获取冲突类的加载信息，快速定位到冲突的 jar。

为什么日志框架会冲突

问题至此就解决了，但是还有一个更深入的问题没有解决：为什么同时存在多个日志框架的时候就会出现冲突呢？在解决完问题之后，我深入研究了日志框架的历史和设计，发现原来这跟日志框架的实现机制有关系。

日志框架的历史

首先要从日志框架的发展历史开始说起。

首先登场是Java Util Log，简称JUL，是JDK 中自带的 log 功能。虽然是官方自带的，JUL 的使用却不广泛，主要是因为功能比较简单，不好用。

然后Log4j 1x就登场了：它是 Gülcü 设计实现的日志框架，设计非常优秀，是非常广泛使用的框架。

Commons Logging：简称 JCL，是 Apache 的项目。JCL 是一个 Log Facade，只提供 Log API，不提供实现，用 Adapter 来使用 Log4j 或者 JUL 作为 Log Implementation。目的是统一日志接口规范，适配多种日志实现。

SLF4J/Logback：SLF4J(The Simple Logging Facade for Java) 和 Logback 也是 Gülcü 创立的项目，其创立主要是为了提供更高性能的实现。其中，SLF4j 是类似于JCL 的Log Facade，Logback 是类似于Log4j 的 Log Implementation。这老哥觉得 JCL 的接口设计不好，所以重新设计了一套。

Log4j2：维护 Log4j 的人为了不让 Log4j 的用户被 SLF4J/Logback 抢走，所以搞出了新的日志框架。Log4j2 和 Log4j1x 并不兼容，设计上很大程度上模仿了 SLF4J/Logback，性能上也获得了很大的提升。Log4j2 也做了 Facade/Implementation 分离的设计，分成了 log4j-api 和 log4j-core。

至此我们已经有了三个的 Log 接口和四个 Log 实现，果然程序员真的是爱造轮子。出现这么多框架之后，有人开始搞各个框架之间的桥接，你兼容我，我兼容你，如下图所示。

因为很多 jar 使用的日志框架不同，所以经常会出现引入 jar 包之后导致日志类冲突，前面我们排查的那个问题就是因为引入了 jcl-over-slf4j 的桥接包。

动态加载日志实现

前面我们提到日志框架分为日志接口和日志实现，只要我们代码中使用的是日志接口(JCL、SLF4J)，我们可以随时替换日志的实现。

SLF4J 加载日志实现的方式

SLF4J 加载日志实现分为两个步骤：

获取 ILoggerFactory 日志工厂

根据 ILoggerFactory 获取 Logger

SLF4J 要求日志实现 jar 包都要实现 StaticLoggerBinder 这个类，而且要放在指定目录：org/slf4j/impl/StaticLoggerBinderclass，SLF4J 的LoggerFactory会去扫描所有 jar 包中的这个地址，参考下面的代码。

虽然它扫描了多个日志实现，但实际上同名类 JVM 只能存在一个，它这里扫描的目的是为了打印日志告诉用户有多少个日志实现在依赖包中。下面的代码返回的是最终使用的日志实现。

你可能要问了，同时存在多个日志实现类的时候，到底是用的是哪个？答案很简单，因为 SLF4J 利用了静态类来加载日志工程，实际上就是让 JVM 决定使用哪个类：哪个被先加载到 JVM 中就用哪个。为了搞清楚这个问题的答案，我特地去看了URLClassPath加载类的实现，它就是按照 jar 加入到 URLClassPath的顺序遍历扫描，找到第一个符合条件的就返回。

JCL 加载日志实现的方式

相比 SLF4J 比较任性的加载方式(依赖 JVM 加载类的顺序)，JCL 提供了更多的配置能力，可以指定使用哪一个日志工程类。

类似的，JCL 也分为两个步骤加载日志实现：

获取 LogFactory 日志工厂类

根据 LogFactory 获取 Logger

首先是获取 LogFactory：

先从系统属性中读取系统属性SystemgetProperty("orgapachecommonsloggingLogFactory")

使用 Java 的 SPI 机制，来搜寻对应的实现：META-INF/services/orgapachecommonsloggingLogFactory，这里就不对 SPI 进行过多介绍了，简单来说就是搜寻哪些 jar 包中含有搜寻含有上述文件，该文件中指明了对应的 LogFactory 实现

从 commons-logging 的配置文件中 commons-loggingproperties 寻找orgapachecommonsloggingLogFactory的值

最后还没找到的话，使用默认的orgapachecommonsloggingimplLogFactoryImpl

找到 LogFactory 之后就根据 LogFactory 获取 Logger，这个根据不同的 LogFactory 实现有不同的方式。前面我遇到那个问题就是因为类冲突导致使用了 SLJ4J 的 LogFactory ，加载了错误的 Logger。

这几天让IT从业人员忙的不可开交的头等大事便是Log4j的远程执行漏洞了，我们先看一个简单的PoC：

先前往dnslog网站，申请一个子域名，假如是“subdomaindnslogcn”。

然后执行java Main ${jndi:ldap://subdomaindnslogcn/any}，我们在dnslog网站上刷新请求记录，便会看到申请的子域名被访问了。

如果你是一个开发者，你会知道我们的代码里面毫无疑问充斥着大量这种用法。如果你是一个安全人员，自然知道当恶意访问人员输入时可不只是访问个域名就完事，很有可能把主机密码就传到指定网站了。

那解决的办法在各大厂、安全公司等也已经公布了，无非以下几种：

WAF或防火墙规则，我们先不聊，这个大公司都会做，但并不能完全解除问题。

我们把升级JDK、升级logback、替换成logback以及移除log4j的JNDI相关类都可以看作类库升级。一方面，这些方案都需要一个应用一个应用去执行（甚至有些需要一个一个实例去处理），重复劳动，投入较大；另一方面，兼容性存疑，在升级前必然要做一定的回归测试。此处的兼容性，可以略举一些例子：比如代码里写死了log4j的实现类，而不是slf4j的api时，想要直接替换成logback就不现实。有人可能会说代码规范不允许，但他们忘了，规范和执行是2个相关的事情，但不是必然的因果关系。比如一些只做维护的老系统，存在时间比很多人工龄都长，还有一些是外包产商开发维护的系统，这种情况就是稳定重于一切。

其余几个都是修改配置，但其中略有差异。比如环境变量影响 *** 作系统上所有的应用，如果某个应用JDK版本较高，又刚好需要这个特性，那么就容易产生bug了。修改PatternLayout容易遗漏，比如通常在自己应用的log4j配置文件，但也有可能内部框架做了封装，在jar包有配置，甚至在代码里做了配置。而在log4j2componentproperties添加配置同修改PatternLayout，也还是需要重新打包构建（除非有统一配置中心，并魔改log4j）。

综上来看，我们要避免开发人员修改、避免再次构建，只做重启的话，只能是修改环境变量或添加启动参数了。当然，每个公司有它自己的体系，某些时候大众意义的不好用对于它而言，反而是最简单的。比如，没有自动化（尤其是k8s）的公司，想要改启动参数，运维一个个实例去修改，那简直痛不欲生。

如果我们是log4j的开发人员，当产品经理提出一个需求，即碰到由“${”开头、“}”结尾的日志时，自动做替换，这个需求我们要不要做，怎么做。

刚入行的我是不会问要不要做的，只会想着怎么做，那自然是匹配、解析了。

有一定经验的我则会问这个需求为了解决什么问题，有没有比产品经理提的刚恰当的方式来解决（产品经理资历较浅，或者对产品不够熟悉时）。那我们可以看下log4j这个需求的提交记录最早可以追溯到2013年了，提交记录较多，可以通过代码反向推测需求：类似slf4j，将日志中的占位符替换成真实值，真实值可以延迟计算，计算来源支持扩展。

从代码看，目前已有的扩展包括ctx（日志事件的上下文）、date（日志事件产生的时间）、env（系统环境）、jndi（JNDI上下文获取）、map、sd（结构化事件类型中获取）、sys（系统属性）、web（从webxml等取ServletContext）

需求是实现了，那还有吗？

如果是一个资深的研发人员就会问了，有预计的使用频率吗，如果使用频率非常高，性能就需要注意不能拖后腿；这个特性如果出现问题，需要关闭，最好能动态关闭；这个特性实际使用了多少次，耗时多少，报错多少；这个是否会在多线程环境下执行，这段代码是否线程安全；用户的输入能否对服务器产生破坏，保存后对其他用户是否产生安全问题。

在一个成熟的企业中，需要考虑诸如此类的问题。当然，很多东西可以模板化，减少开发人员心智，比如CI/CD实践中的自动化测试和DevSecOps。

为什么这次的影响这么大，因为它是基础库，比如dubbo、kafka、flink等很多框架和中间件都用到了它。同时，这从侧面说明log4j2是一个比较值得选取的日志库。

那回到技术选型，以日志为例，我们需要考虑哪些方面呢？

功能。功能是否契合企业需求，缺失功能是否在未来计划，或者扩展实现难度。如果功能都不满足，那自然pass。log4j、logback、log4j2都提供了将日志输出的功能，功能上都能满足，细节根据各企业自身情况而定了。

性能。性能自然是非常重要的，生产是没法debug的，只能通过日志来跟踪某一个事务的情况，如果日志耗时太多，TPS自然受影响，用户体验变差，还可能导致硬件成本上升。log4j2的性能就比logback要出色，logback比log4j要出色。

群众基础和易用性。如果没人会用，使用起来也困难，大概率很难被接受，也很难流行。文档是否介绍了架构设计，也有使用文档，文档是否支持多种语言（本土语言）。log4j2的配置就比较多，特别是想要较高性能时，配置更是复杂。

稳定性与活跃度。生产上使用，肯定要求稳，不可能三五天做一次修复升级。如果功能还未按计划完全实现，那么迭代升级过程中会碰到诸多问题，需要有较多的人提前使用反馈意见做改进，出现问题时，能够通过搜索引擎或其他社群解决。

开源协议。如果不开源，那么使用时心中便会有诸多不安，万一哪个地方有雷都不知道，出了问题，自己能解决的概率也极低。比如MySQL的双协议，要求要么交费，要么开源改动，不如Apache Licence等宽松，导致很多公司开始选择PostgreSQL。

生态。与企业的整套框架是否有冲突，开发流程上是否需要做额外的事情。比如很多框架用了log4j2，贸然引进logback，势必多出工作量来排除log4j2的依赖。比如开发流程工具只支持logback（当然这种场景基本没有），那么使用log4j2就需要再仔细想想了。

架构设计与代码质量。如果代码的架构设计较差，扩展性没设计好，那么企业内部做扩展（二次开发）时，只能修改代码，与源头分叉，后续几乎没法合并，无法反哺开源社区，企业内部后续升级也十分困难。如果代码质量太差，一步一坑，大家直接用脚投票的。

前瞻性。架构设计要有一定的前瞻性，以应对未来的变化。功能建设上也要有一定的前瞻性，实现、验证、上线三者之间还是需要一定时间的。比起等待，大部分人都是想我现在要。

以上就是关于spring Boot必用依赖框架全部的内容，包括:spring Boot必用依赖框架、如何开启Dubbo框架内部的日志、logback里面可以写log4j的配置吗等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！