扒一扒这个注解，我发现还有点意思。

你好呀，我是歪歪。

我上周我不是发了这篇文章嘛，《我也想说说日志，但是我不想说漏洞。》。

然后就有小伙伴来问我：我项目里面用的是 Lombok 的 @Slf4j 这个会有影响吗？

你说这事多巧，我也用的这个注解，所以我当时稍微的看了一下。

先说结论：有没有影响还是取决于你项目中依赖的 log4j2 包，和 Lombok 没有任何关系。

另外“求求你提问之前三思，不要浪费我们的时间，不要问那些你自己就能搞清楚的问题”这句话不是我说的，是 Lombok 的作者说的：

他为什么会说出这样的略带一丝丝气愤的话呢？

我带你看看。

从issue 说起

你在 github 上找到 Lombok 项目，然后查看它的 issue 会看到关于 log4j 的问题已经被置顶了：

所以关于这个问题，我就从这个 issue 说起吧，这里面有 Lombok 维护者的权威回答。

https://github.com/projectlombok/lombok/issues/3063

这个 issue 的标题翻译过来就是：

结论：关于 log4j 的 0day 问题，Lombok 本身不受影响。

注意啊，这个里面有个非常耐人寻味的单词：itself。

一般我们说 Lombok 不受影响就行了，为什么还得加个 itself(本身)呢？

这里面就是有故事的。

首先是 12 月 10 日下午 5 点 41 分，也就是漏洞被爆出的那个下午，有个哥们在 Lombok 的 issue 提出了这个问题：

他说：铁子们，出事了，log4j 爆出惊天大漏洞，赶紧补吧。

然后有个叫做 Rawi01 的老铁跳出来说：

老哥，你能解释一下这个漏洞 对 Lombok 有什么影响吗？据我所知，log4j 只是在运行测试时不出现编译错误时才需要。

这个老哥明显是对 Lombok 比较了解的，他其实已经指出关键的地方了：Lombok 并没有依赖 log4j。

但是紧接着有人指出：

Lombok 提供了一个注解，叫做 @log4j。这玩意使用了 Log4J 的库吧，毕竟要用它记录日志。

确实有这个注解啊，给大家看一下：

我一般是用 @Slf4j 这个注解，但是它确实是还提供了其他的日志注解，这个先按下不表，等下再说。

现在的主线任务是这个 issue，接着往下看。

接下来，来了一个控场的哥们，看一下他说了啥：

他先艾特了前面的说 @log4j 注解的这个哥们，给他解释说：虽然 Lombok 会生成代码来创建一个 logger 的实例，但我们并没有 ship, distribute or require 任何特定的版本，如果用户要用这个注解，需要他们自己提供对应的依赖。

这里我有三个词我还没翻译：ship, distribute or require。

request 其实很简单，就是要求。

意思是我们没有要求用户使用的时候必须给到指定版本的依赖。说白了就是，假设你要用 @Log4j，那就提供对应的依赖，至于这个依赖的版本是什么 Lombok 并不关心。

剩下的 ship 直译过来是“运送” 的意思，而 distribute 有“分发”的意思。

这个我用一张图片来解释吧：

可以看到，在项目中我引用了 Lombok，但是它并没有传递依赖进来任何其他的包。不像是 spring-boot-starter 后面跟着一大坨东西。

我理解这就是他想要表达的：we do not ship, distribute or require any specific version.

然后接着说：在我们的代码库中确实可以找到一个 log4j2 的版本，但那只是在测试代码里面使用，以便能够无错误地编译生成的代码。

最后这个哥们总结到：放心，老铁们，Lombok 仍然可以安全的使用。但我觉得虽然是测试代码中引用到了 Log4j ，也还是应该把依赖关系更新到安全的版本。

怎么样，是不是感觉这个老哥说话有一种不可置疑的自信感。

我读完这个回答之后就是有这样的感觉，隐隐觉得这就是个大佬。

于是我去扒了一下这个老哥的背景：

本来我是想从他的 github 主页上寻找答案，居然没有发现和 Lombok 相关的项目。

而且只有 49 个 followers，看着也不符合大佬的数据呀：

于是我转战浏览器，搜索了：Roel Spilker Lombok.

找到了这个：

才发现，好家伙，他是 Lombok 的爸爸啊，难怪说话这么硬气。

还发现了一个花边新闻：他们之前还把关于 Lombok 的想法贡献给了 Oracle，但是被拒绝了。官方不支持，他们只有揭竿而起，自己搞了。

现在 Lombok 的市场占有率还是很高的吧，算是把这事儿干成功了。

另外，其实这里就可以直接看到他的身份：

Collaborator，就是合作人。他的回答可以等同于官方回答了。

到这里事情还算是发展的比较顺利，官方亲自下场来解答这个问题，且已经明说了：

算是可以完结撒花了。

但是，就怕出现但是啊，后面发生的事情我就觉得有点离谱了。

首先是 SunriseChair 老哥献出了一杀：

他首先引用了作者的回复，然后说，如果你在你的 maven 或者 gradle 中声明 Lombok 这个依赖项，那么 Log4j 的依赖项不也会被包括在内吗？这可能是 classpath 上唯一的依赖，而 Lombok 生成的代码也会用到它？如果我说错了，请纠正我......

他想要表达的是什么意思呢。

首先我觉得是他读完作者的回答后觉得 Lombok 是依赖了 Log4j 的，所以他的核心问题就是，如果我引用了 Lombok 那么 Log4j 的依赖岂不是也会传递进来？

但是作者都说了：there is a version to be found in our code base, but that's 仅仅用于测试类中。

但凡你稍微了解一点开源项目的工作原理，也就知道测试相关的部分都不会提供出去，如果你要看测试类，你得把项目源码拉下来。

简单来说就是如果你通过 maven 依赖了 Lombok，测试相关的东西你肯定是看不到的。

接着一位叫做 RuanNunes 的老哥也出来补枪了，献上了二杀，他说他在整个项目里面搜索到了这个东西：

这个配置是存在漏洞的。

然后作者对这两个问题进行了一一回复：

首先，说 Lombok 依赖了 log4j 的老哥听着：Lombok 没有对 log4j 或任何其他库进行依赖。如果你在你的代码中使用 @Log4j 注解，但是又不直接或间接地依赖 log4j ，你的编译就会产生一个错误信息。

关于这一点，前面的依赖分析截图也已经说明了，我就不再贴一次了。

然后说找到漏洞的哥们听着：在你找到的这个漏洞的同一目录下有一个文本文件，但凡你去看一眼，你就知道我们不会将该文件作为我们发布的一部分。

所以我理解压根不会发布出去，即使有漏洞，对于 Lombok 的用户来说也没有任何毛病吧？

我也去找了一下作者说的这个文件，就是它：

https://github.com/projectlombok/lombok/blob/d3b763f9dab4a46e88ff10bc2132fb6f12fda639/src/support/info.txt

这个文件里面清清楚楚的说了：not part of lombok itself.

如果前面这两个问题，已经让作者有点点不爽的感觉的话，那么接下来这个问题，可能就是引爆点，完成三杀，一波带走：

这个哥们上来就说：老铁，我问个问题哈。我使用的是 @slf4j 注解，这个漏洞和我有关系吗？

不行了不行了，血压上来了。

我觉得这个哥们提问之前完全没有看前面的回复，如果他在作者进行了两次解释之前提出这个问题，那么我觉得完全可以理解。

但是在作者已经在这个 issue 里面解释了两次“Lombok 不受影响”的前提下，他哗一下，上来就是一个暴击：

老哥，我用的这个注解有问题吗？

我写到这里都有点血压上来了。

这特么特别像是之前有一次在一个群里和别人讨论事务失效的场景，已经讨论到尾声了，突然跳出来一个哥们，甩出来一个代码片段，这个片段的写法就是一个经典的 this 调用导致事务注解失效的场景，而这就是我们刚刚讨论中的一部分。

知道我们在讨论这个问题，哪怕你稍微往上翻一翻呢，了解一下上下文再提问不好吗？

不扯远了，也许是我过度解读把，反正我觉得提问的艺术大家都得好好学一下。

回到我们的主线剧情，看一下作者是怎么回答这个问题的：

他说：老铁，这个问题我帮不了你啊。我对于这个漏洞一无所知，我甚至不明白为什么你会认为它也会影响 @Slf4j。

我可以告诉你的是，Lombok 没有使用、传递、要求对这些库的依赖。

我们的工作原理是生成了你"看不见的源代码"。

如果你有任何理由怀疑类似的问题也可能发生在他们的产品中，请联系 Slf4j 的维护者。

不知道是不是我个人的感觉，我觉得作者回复这个问题的时候已经有一点怒气了：这都是些什么问题啊？前我已经回复了两次不受影响啊？怎么感觉我的项目使用者怎么都不了解 Lombok 的基本原理呢？

在作者回复完这个冒失的提问者之后，这个提问者还是很礼貌的回复了一下：

谢了老铁，我检查了，我使用的是 SpringBoot 默认的 logback。

作者也把这个问题给置顶了，且修改了这个 issue 的标题。

所以，经过前面的一番解读，现在你再看这个标题：

为什么作者要强调“itself”，因为 Lombok 确实是提供了日志的功能，但是至于引用什么包，哪个版本的包，和 Lombok 都没有任何关系。Lombok 本身(itself)是安全的。

最最后，作者给了 log4j 漏洞对于 Lombok 的 Latest assesment(最新评估)，算是总结性发言：

给大家翻译一下关键的东西。

这个漏洞只存在于 2.16.0 版本以下的 Log4j code 包中，而不存在于任何其他日志框架中。

Lombok 没有传递依赖任何 Log4j 包，也没有声明对任何东西的依赖。

如果你使用任何 Lombok 的注解，比如 @Log4j，Lombok 将生成使用这些库的代码，但是你的项目里面必须要包含对这些库的依赖，否则 Lombok 生成的代码将无法编译。

同样地，你要负责在你的运行时中拥有这些包，否则类的初始化可能会失败。

在 Lombok 测试代码中，我们曾经有一个包含这个漏洞的版本，但是由于测试不处理任何用户输入（测试是硬编码的），而且生成的代码甚至没有被执行，运行测试并没有导致执行测试的机器上出现 RCE(远程代码/命令执行漏洞)。

所以，老铁们，Lombok 本身不需要做任何改变，也不对你的项目负任何安全责任，毕竟包不是我们引进来的。

如果你不同意目前的评估，请在这个问题上添加评论。

但是，请确保你已经阅读了其他评论，并确保你理解了这个问题。

最后这两句话，单独拎出来，我可太喜欢这两句话了：

求求你提问之前三思，不要浪费我们的时间，不要问那些你自己就能搞清楚的问题。

如果你认为我们遗漏了什么，或者有新的信息，请大声的说出来。

然后，你注意这里作者用的小标题是：The balancing act.

翻译过来是“平衡的行为”，啥玩意？

NO，NO，NO：

一个小俚语送给大家，不必客气。

补充说明

前面把主线剧情过完了，现在我来几个补充说明吧。

先说前面按下不表的关于日志的注解。

其实 Lombok 里面关于日志的注解还真是挺多的，可以直接看官方的文档：

https://projectlombok.org/features/log

这么多注解，一个个的讲也没啥意思，我这里就挑  @Slf4j 、@Log4j2 这两个演示一下吧。

首先，我们可以搞个纯净的 SpringBoot 项目，只包含这两个依赖：

这个时候如果我什么都不动，只是稍微改一下启动类：

然后为了排除干扰项我把日志打印的级别调整到 Error：

logging.level.root=error

同时关闭 banner 输出：

spring.main.banner-mode=off

banner 就是这个玩意：

这个时候启动项目，日志输出是这样的：

可以看到我们这个时候使用的日志是 logback，原因我在之前的文章里面也讲过了，因为 Springboot 默认使用的日志实现是 logback。

这一点，从项目依赖上也可以看出来：

另外，你注意一下，我特意把 import 部分也截出来了，除了 @Slf4j 注解外，这里并没有引入任何日志相关的注解。

然后，我再关注一下这个时候编译出来的 class 文件：

自动引入了 slf4j 相关的包，然后生成了这行代码：

private static final Logger log = LoggerFactory.getLogger(LogdemoApplication.class);

这个时候不知道你有没有想到编译时注解相关的东西，但是不慌，这里还是先按下不表。

来，我问你：为什么它能引入 slf4j 相关的包？

因为我依赖了呀：

好，如果这个时候我把 logback 的核心依赖给拿掉，会出现什么事情，你觉得会不会编译不过呢？

不会编译不过，因为 Slf4j 包还在，它只是一个日志门面。

但是运行的时候会抛出异常，因为找不到日志相关的具体实现类：

然后，如果我想用 log4j2 日志实现怎么办呢？

之前的文章中也写过：

把 Springboot 默认的依赖拿掉，然后引入 Log4j2 的包。

这个时候项目依赖图是这样的，可以看到没有 logback-core 了，只有 log4j-core：

再次运行项目，日志实现就变成了 Log4j：

你发现了吗，我除了动了一下 pom 依赖外，其他的代码一行都没有动，日志框架就从 logback 变化为了 log4j。

而且 class 文件没有任何变化，所以我也就不去截图了。

这就是 Slf4j 的功劳，这就是“门面”的含义，这就是为什么都建议大家在项目中使用 Slf4j，而不是具体的诸如  logback、log4j 这样具体的日志实现。

接下来说一下 @Log4j2 这个注解。

我们还是把依赖恢复到最开始纯净的状态，也就是这样：

然后我们把注解修改为 @Log4j2，但是我们项目中这个时候并没有引入 Log4j-core 包，那么你觉得会有问题吗？

不会有问题的，我们可以看一下。

先看一下输出：

此时的日志实现类是 SLF4JLogger。

这玩意哪里来的？

看一下 class 文件：

这个两个类是来自于 log4j-api 包里面，同时由于 log4j-to-slf4j 包的存在，所以最后的实现类桥接到了 SLF4JLogger 中去：

如果我把 log4j-api 包移除掉，你说会不会编译不过呢？

肯定编译不过的，因为包都不存在了，搞不出来 class 文件：

如果我不想用 SLF4JLogger 这个类呢，我就想用真正的 log4j。

简单，把 log4j 的依赖搞进来：

好，我前面说了这么多的废话，不厌其烦的给你排除、引入日志相关的包，给你看输出啥的，而且整个过程中并不涉及到 Lombok 包的变化，都是为了再次印证这两句话：

如果你使用任何 Lombok 的注解，比如 @Log4j，Lombok 将生成使用这些库的代码，但是你的项目里面必须要包含对这些库的依赖，否则 Lombok 生成的代码将无法编译。

比如我前面把 log4j-api 包移除掉了，是不是编译就没有过？

同样地，你要负责在你的运行时中拥有这些包，否则类的初始化可能会失败。

比如我前面把 logback-core 的包移除了，编译的时候没有问题，但是服务运行的时候，是不是抛出找不到类的异常？

是不是再次证明：

聊聊原理

前面我提到了一句“编译时注解”，不知道大家对于这个玩意了不了解。

不了解其实也很正常，因为我们写业务代码的时候很少自定义编译时注解，顶天了搞个运行时注解就差不多了。

Lombok 的核心工作原理就是编译时注解。

其实我了解的也不算深入，只是大概知道它的工作原理是什么样的，对于源码没有深入研究。

但是我可以给你分享一下两个需要注意的地方和可以去哪里了解这个玩意。

首先第一个需要注意的地方是这里：

log 相关注解的源码位于这个部分，可以看到很奇怪啊，这些文件是以 SCL.lombok 结尾的，这是什么玩意？

这是 lombok 的小心思，其实这些都是 class 文件，但是为了避免污染用户项目，它做了特殊处理。

所以你打开这类文件的时候选择以 class 文件的形式打开就行了，就可以看到里面的具体内容。

比如你可以看看这个文件：

lombok.core.handlers.LoggingFramework

你会发现你们就像是枚举似的，写了很多日志的实现：

这个里面把每个注解需要生成的 log 都硬编码好了。正是因为这样，Lombok 才知道你用什么日志注解，应该给你生成什么样的 log。

比如 log4j 是这样的：

private static final org.apache.logging.log4j.Logger log = org.apache.logging.log4j.LogManager.getLogger(TargetType.class);

这也同时可以和我们前面的 class 文件对应起来：

而 SLF4J 是这样的：

private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(TargetType.class);

第二个需要注意的地方是找到入口:

这些 class 文件加载的入口在于这个地方，是基于 Java 的 SPI 机制：

AnnotationProcessorHider 这个类里面有两行静态内部类，我们看其中一个， AnnotationProcessor ，它是继承自 AbstractProcessor 抽象类：

javax.annotation.processing.AbstractProcessor

这个抽象类，就是入口中的入口，核心中的核心。

在这个入口里面，初始化了一个类加载器，叫做 ShadowClassLoader：

它干的事儿就是加载那些被标记为 SCL.lombok 的 class 文件。

然后我是怎么知道 Lombok 是基于编译时注解的呢？

其实这玩意在我看过的两本书里面都有写，有点模糊的印象，写文章的时候我又翻出来读了一遍。

首先是《深入理解 Java 虚拟机(第三版)》的第四部分程序编译与代码优化的第 10 章：前端编译与优化一节。

里面专门有一小节，说插入式注解的：

Lombok 的主要工作地盘，就在 javac 编译的过程中。

在书中的 361 页，提到了编译过程的几个阶段。

从Java代码的总体结构来看，编译过程大致可以分为一个准备过程和三个处理过程：

• 1.准备过程：初始化插入式注解处理器。
• 2.解析与填充符号表过程，包括：
• 词法、语法分析。将源代码的字符流转变为标记集合，构造出抽象语法树。
• 填充符号表。产生符号地址和符号信息。
• 3.插入式注解处理器的注解处理过程：插入式注解处理器的执行阶段，本章的实战部分会设计一个插入式注解处理器来影响Javac的编译行为。
• 4.分析与字节码生成过程，包括：
• 标注检查。对语法的静态信息进行检查。
• 数据流及控制流分析。对程序动态运行过程进行检查。
• 解语法糖。将简化代码编写的语法糖还原为原有的形式。（java中的语法糖包括泛型、变长参数、自动装拆箱、遍历循环foreach等，JVM运行时并不支持这些语法，所以在编译阶段需要还原。）
• 字节码生成。将前面各个步骤所生成的信息转换成字节码。

如果说 javac 编译的过程就是 Lombok 的工作地盘，那么其中的“插入式注解处理器的注解处理过程”就是它的工位了。

书中也提到了 Lombok 的工作原理：

第二本书是《深入理解 JVM 字节码》，在它的第 8 章，也详细的描述了插件化注解的处理原理，其中也提到了 Lombok：

最后画了一个示意图，是这样的：

如果你看懂了书中的前面的十几页的描述，那么看这个图就会比较清晰了。

总之，Lombok 的核心原理就是在编译期对于 class 文件的魔改，帮你生成了很多代码。

这也是作者提到的：

invisible source code，看不见的源码。

这里的看不见，指的是 java 文件中的看不见，在 class 文件中它还是无处遁形。

如果你有兴趣深入了解它的原理的话，可以去看看我前面提到的这两本书，里面都有手把手的实践开发。

我就不写了，一个原因是因为确实门槛较高，写出来生涩难懂。另外，一个原因那不是因为我懒嘛。

荒腔走板

我是这个月 6 号开始着手写《2021，我这一年》回忆录的。

按照前几年的经验来说，这算是一个开始的比较晚的时间了。

所以我必须按照截图上面的节奏去写，才能赶上 31 号的时候截稿。

目前来看计划进行的好像还算是顺利，但是其实我仔细想了一下，只留下 31 号一天的时间来收尾的话，是很有风险的。我这个人写文章，开头和过程都不算难，难的时候我不知道该怎么去收尾。

而且现在写出来的东西，由于有时间卡着的，让我有一种无形的压力，反而导致最终出来的东西自己不是特别满意。

我现在每写一个月，都要把那一个月拍的所有的照片都翻一遍，然后把值得记录的事情标记到思维导图里面，最后还得再筛一次，最终选几件我觉得真的值得记录的事情写下来，这是一个比较耗时的过程。

之前有人问过我：每一年的回忆录这么长，你是一个月写一次还是一年一起写呢？

当然是一年的一起写了，一般是 12 月初开始着手准备。

一个月写一次的想法我之前有过，但是我发现如果一个月写一次的话少了一点乐趣，多了一点事无巨细，毕竟跨过一个比较长的时间间隔之后，能再次很快就想起的事情，并且还能有细节在记忆中，才是真正应该被记录的事情。

但是一个月写一篇，这一篇里面要回忆这一整年，真特么是一件痛苦的事情。

现在距离 2022 年只有 13 天时间了，我觉得进度和当前写出来的东西我都不太满意，所以后面也许我会放缓一下更新的频率，先把《2021，我这一年》搞定了再说。毕竟这是十年计划的第九年，咬咬牙，得熬出来才行。

我看了一下，现在刚好写到了 6 月份，已经有 1.6w 字了，后面应该还会有一波修改：

而且写着写着我发现我变了。

头几年，我愤世嫉俗，就想要写点尖锐的东西，语不惊人死不休。现在，有些事情我不太敢写了，写了删，删了写，最后一大段话只留下一句模糊的描述。但是我知道多年以后自己看到的时候，还能想起其中的细节是什么。

这是成长，这是圆滑，也是异化。

最后说一句（求关注）

好了，看到了这里了， 转发、在看、点赞随便安排一个吧，要是你都安排上我也不介意。写文章很累的，需要一点正反馈。

给各位读者朋友们磕一个了：

··································

你好呀，我是歪歪。一个主要敲代码，经常怼文章，偶尔拍视频的成都人。

我没进过一线大厂，没创过业，也没写过书，更不是技术专家，所以也没有什么亮眼的title。

当年以超过二本线 13 分的优异成绩顺利进入某二本院校计算机专业，误打误撞，进入了程序员的行列，开始了运气爆棚的程序员之路。

说起程序员之路还是有点意思，可以看看。点击蓝字，查看我的程序员之路