lombok通过java注解处理器在编译期修改ast实现代码自动生成。1. 编译时，javac扫描源码并加载lombok注解处理器；2. 处理器获取被注解标记的元素及其ast；3. 直接在ast中插入新节点如getter/setter；4. 修改后的ast交由编译器生成含完整代码的.class文件。与运行时反射相比，lombok无性能损耗、类型安全，但需ide插件支持且可能影响代码可读性及调试。
Java注解处理器在Lombok中的应用原理，核心在于Lombok巧妙地利用了Java编译器提供的标准注解处理API（Annotation Processing API），在代码编译阶段，而非运行时，对源代码的抽象语法树（AST）进行修改和增强，从而自动生成那些我们日常编写中重复性极高的样板代码，比如getter、setter、构造函数等。这就像是给编译器装了一个“外挂”，让它在编译前替你把代码写好，再进行编译。
Lombok的工作流程可以概括为以下几步：
当Java编译器（javac）开始编译源代码时，它会扫描所有的源文件，发现其中使用了Lombok的注解（如@Data, @Getter, @Setter等）。根据Java的注解处理规范（JSR 269），javac会查找并加载所有注册的注解处理器。Lombok的核心就是一个实现了javax.annotation.processing.Processor接口的注解处理器。
立即学习“Java免费学习笔记（深入）”；
一旦Lombok的处理器被激活，它会获得当前编译轮次中所有被特定注解标记的元素信息。这些信息不仅仅是注解本身，更重要的是，处理器能够访问到这些代码元素的抽象语法树（AST）。AST是源代码的树形表示，编译器在将源代码转换为字节码之前，会先将其解析成AST。
Lombok的处理器会遍历这个AST，识别出被Lombok注解修饰的类、字段等。然后，它不会生成新的.java文件，而是直接在内存中对AST进行“手术”——它会动态地向AST中添加新的节点，比如代表getter方法的MethodDeclaration节点，或者代表无参构造函数的ConstructorDeclaration节点。这些新添加的节点在结构上与你手动编写的代码所生成的AST节点是完全一致的。
当Lombok完成对AST的修改后，它会将修改后的AST交还给编译器。对于编译器而言，它看到的AST已经是包含了所有Lombok“生成”代码的完整版本。编译器会继续后续的编译流程，将这个修改后的AST转换为字节码（.class文件）。因此，最终生成的.class文件中包含了Lombok自动生成的代码，而你的源代码文件本身并没有被改动。这就是为什么你在IDE里看不到那些方法，但编译后的字节码却实实在在包含它们的原因。这种方式，我认为是相当优雅且高效的，它避免了运行时反射带来的性能开销，也保证了代码的类型安全。
说起Lombok如何利用AST来生成代码，这其实是它最核心也最“魔法”的部分。AST，也就是抽象语法树，它是编译器在解析源代码后，构建出来的一种数据结构，用树的形式表示程序的语法结构。可以把它想象成源代码的骨架，每一个节点都代表着代码中的一个语法元素，比如一个类、一个方法、一个变量声明，甚至是一个表达式。
Lombok的聪明之处在于，它并没有去解析你的文本源代码，而是直接在编译器已经解析好的AST上动刀子。当Lombok的注解处理器被触发时，它会拿到当前编译单元的AST。比如，你有一个类User，里面有个字段name，你给User类加了@Data注解。Lombok的处理器会找到User类对应的AST节点，然后找到name字段对应的AST节点。接着，它会根据@Data注解的语义，在User类的AST节点下，动态地“插入”一个新的方法节点，比如一个getname()方法。这个新插入的方法节点，包含了方法的修饰符（public）、返回类型（String）、方法名（getname）、以及方法体内的语句（return this.name;）。
这个过程，就像是你在一个已经画好骨架的图纸上，直接添加新的结构。编译器后续的工作，就是基于这个被Lombok修改过的“图纸”来生成最终的二进制文件。这意味着，Lombok生成的方法，对于Java虚拟机来说，和我们手写的方法没有任何区别。它们都是实实在在存在于.class文件中的字节码。这种直接操作AST的方式，避免了生成临时源文件再编译的复杂性，也让Lombok的侵入性降到了最低，因为它直接在编译器的内部流程中完成了所有工作。这与那些通过文本替换或生成新源文件的方式相比，无疑是更高级、更底层的玩法。
编译期代码注入（如Lombok）和运行时反射，虽然都能实现一定程度上的“代码动态性”，但它们在本质上是截然不同的，就好比一个是“预制件工厂”和一个是“现场改造队”。
编译期代码注入，Lombok就是典型代表。它的核心在于“编译期”，即在你的Java源代码被javac编译成.class文件的这个阶段。Lombok的注解处理器在这个阶段介入，直接修改了编译器内部的抽象语法树（AST）。这意味着，Lombok生成的代码，在.class文件形成的那一刻，就已经实实在在地存在于其中了。这些代码和我们手写然后编译的代码没有任何区别，它们是硬编码在字节码里的。
运行时反射，则完全是另一回事。它发生在“运行时”，即你的.class文件已经被JVM加载并执行之后。Java的反射API允许程序在运行时检查类、方法、字段的信息，甚至在运行时动态调用方法、访问或修改字段。它不是在编译时修改字节码，而是在程序运行起来后，通过JVM提供的机制去“看”和“操作”已经存在的类结构。
所以，你看，Lombok是在“建房子”之前就把房间结构调整好了，而反射则是在“房子建好”之后，通过特殊工具去改变房间的布局。Lombok的目的是减少样板代码，提升开发效率，它追求的是编译时的确定性和性能；反射则更多用于框架、工具或需要高度动态性的场景，它追求的是运行时的灵活性。两者服务的目标和工作机制完全不同。
尽管Lombok带来了巨大的便利，但在实际项目中运用时，你确实可能会遇到一些小小的“别扭”或者说需要注意的地方，这就像任何一个强大的工具一样，总有一些它自己的脾气。
首先，最常见也最让人头疼的，可能就是IDE的支持问题。因为Lombok是在编译期修改AST，你的IDE（比如IntelliJ IDEA、Eclipse）在编辑代码时，它自己的内部编译器或语言服务并不会像javac那样自动加载Lombok的处理器。这就导致你可能在IDE里看到一堆“找不到符号”、“方法不存在”的红色波浪线，尽管你的代码编译运行是完全正常的。为了解决这个问题，你几乎总是需要安装Lombok的IDE插件。安装后，IDE才能“理解”Lombok的魔术，正确地解析并显示那些被Lombok生成的方法。如果忘记安装或者插件版本不匹配，那开发体验就有点糟糕了。
其次，是关于代码的可读性与调试。对于不熟悉Lombok的团队成员来说，初次接触时可能会觉得有些“魔法”。他们可能会疑惑，为什么一个类里没有getter/setter方法，但代码却能调用它们？这在一定程度上增加了新成员的学习曲线。更进一步，当出现运行时异常，比如空指针异常，堆栈跟踪（stack trace）可能会指向L一个被Lombok生成的方法，而这个方法在你的源代码里是看不到的。这给调试带来了一点点不便，你可能需要借助delombok工具来查看Lombok到底生成了哪些代码，或者依赖IDE的良好支持来“透视”这些隐式代码。
再来，是与序列化框架的兼容性。一些序列化框架（如Jackson、Gson）在进行JSON序列化/反序列化时，可能会依赖于默认的无参构造函数或者特定的getter/setter命名规范。Lombok的@NoArgsConstructor、@AllArgsConstructor等注解通常能很好地解决这些问题，但如果你同时使用了@Builder或者自定义了构造函数，就得特别注意这些框架的要求，确保Lombok生成的构造函数或方法符合它们的期望，避免出现序列化失败的问题。
还有一点，虽然不常见，但值得一提的是与其他注解处理器的潜在冲突。如果你的项目同时使用了多个注解处理器，并且它们都尝试修改或生成同一个类的AST节点，理论上存在冲突的可能性。不过，Lombok的设计通常比较健壮，这种冲突发生的概率很低，但如果真的遇到了奇怪的编译错误，这可能是一个排查方向。
最后，一个更偏哲学层面的问题：对Lombok的过度依赖。Lombok确实能减少大量样板代码，但如果一个项目离开了Lombok就寸步难行，所有的getter/setter、构造函数都需要手动补齐，那在某些极端情况下（比如Lombok不再维护，或者需要移除它），迁移成本会非常高。所以，在使用Lombok享受便利的同时，也要对其带来的隐性依赖有所认识。
以上就是Java注解处理器在Lombok中的应用原理的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
821
收藏
