如何通过编译织入实现AspectJ仅对测试生效不影响主源码运行

问题解答 #

1. 能否不使用AspectJ类加载器，仅通过编译织入实现上述预期效果？ #

可以实现，需要调整编译流程规避之前的问题：
你首次编译织入方案失效的核心原因是：aspectj-maven-plugin执行compile目标织入主业务代码时，test目录的切面类尚未编译，且主代码编译阶段的类路径不包含test目录内容，根本找不到你定义的AspectB切面，因此只会在test-compile阶段织入测试类内部的方法调用点，主代码里A调用B.getB()的逻辑没有被增强。

调整方案如下：

• 正式编译打包阶段，禁用aspectj-maven-plugin的compile目标，仅走普通javac编译，保证输出到正式包的业务代码完全没有切面增强痕迹，也不依赖任何AspectJ相关包
• 测试运行前新增独立的织入步骤：用aspectj工具对已编译的主业务字节码、测试目录下的切面类做一次性织入，织入后的字节码仅用于测试运行，不会污染正式打包产物

如果可以接受正式包内保留织入代码但不生效，也可以将切面开关改为系统变量判断，正式环境默认不开启对应变量即可，无需拆分编译流程。

2. 上述加载时织入方案用到的AspectJ类加载器会对非测试环境的性能产生什么影响？ #

完全没有影响。
你配置的aspectjweaver javaagent仅绑定在maven-surefire-plugin的测试运行参数中，只有执行mvn test命令运行测试用例时，才会加载该agent启动AspectJ类增强逻辑。非测试环境（生产环境启动、本地直接运行main方法）既不会加载该agent，也不会触发任何AspectJ相关逻辑，对正式运行性能没有任何损耗。
哪怕你不小心将aspectj相关依赖包带入了生产环境，只要启动命令没有加对应的-javaagent参数，就不会有任何额外逻辑执行。

3. 加载时织入方案的类处理范围和工作逻辑是什么？ #

处理范围

默认会处理当前运行时类路径下所有符合切点规则的类。但因为你将切面类放在了test目录，只有测试运行时的类路径下才会存在该切面，正式运行时根本找不到切面定义，自然不会做任何增强处理。你也可以通过新增META-INF/aop.xml配置，指定仅增强特定包下的类，进一步缩小处理范围。

工作逻辑

1. 测试启动时，aspectjweaver javaagent会被JVM优先加载，注册全局类文件转换器
2. 所有类在被加载到JVM内存之前，都会先经过该转换器的预处理
3. 转换器会读取当前类路径下的所有切面定义，匹配当前加载的类是否符合切点规则
4. 如果匹配成功，就会动态修改类的字节码，植入切面的增强逻辑，再将修改后的字节码交给JVM完成类加载
5. 类加载完成后的运行阶段，增强后的代码和编译织入的代码性能表现完全一致，不会有额外损耗。

内容的提问来源于stack exchange，提问作者Taras Yatsura