从一个Aspectj织入失效问题的解决说起

发表于 2年以前 | 总阅读数：559 次

事出反常必有妖

组里兄弟领了个任务，维护一个common工具包，用于精简和规范组内编码的公共事项，其中一个功能是AOP拦截。提供了基于Aspectj的自定义枚举AOP拦截jar包，但使用方使用时编织不进去，让帮瞅瞅。

这，应该不难才对呀，日志AOP不是经常写么? 很多实现方式的哇~

我：为啥不搞个spring 组件包？不管你的切面在哪，Component 扫描不是无往不利么？答：不行，组内项目基本没有依托spring的，都是纯Java项目，不带任何框架~ 我：黑人问号~

我：搞个动态代理？答：不好，使用方接入成本大，最好只加个注解，而且希望更节省性能我：黑人问号~

这是非得用AspectJ编译期编织了？

不管会不会，都得先支棱起来

解决问题是关键，为啥会出现使用方引了jar包却编织不生效的情况呢?

先复现下再说。

定义注解

先搞一个注解LogAnnotation , 供使用方标注需要拦截的方法，也给Aspectj提供切点:

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface LogAnnotation {
}

定义切面

来个简单的切面，以上述的自定义注解为切点，拦截所有标注了的方法，随便打个日志：

public class LogAspect {
    @Pointcut("@annotation(com.test.aop.LogAnnotation)")
    public void LogStartTimePointcut() {
    }

    @Around("LogStartTimePointcut()")
    public Object around(JoinPoint joinPoint) throws Throwable {
        System.out.println("进来了~");
        ProceedingJoinPoint pjp = (ProceedingJoinPoint)joinPoint;
        Object result = pjp.proceed();
        System.out.println("要出去了：" + result);
        return result;
    }
}

普通场景验证

先本系统来个Test类验证切面是否正确：

POM中引入aspectj-maven-plugin 打包插件

编译时，切面被正常的编织进方法中了~

说明正常场景下是没问题的，接下来，打包，发布，让第三方项目引用。

引用第三方切面实现AOP拦截

另起一个项目引入上述Jar包，随便找个方法，添加LogAnnotation注解：

public class ConsumerHookImpl implements ConsumerHook {
    @Override
    @LogAnnotation
    public boolean prepare(DTEngineRequest engineRequest) throws Exception {
        return true;
    }
}

在pom中添加了相同配置的aspectj-maven-plugin插件后进行编译，居然真的没有编织切面~ 好神奇~

排查和解决

问题不大，肯定是扫描范围和路径的问题，只要能找到把我们jar放在mvn编译默认范围内的方法，问题应该就解决了。

怎么办呢？上网一搜，一水的都在说用Spring的ComponentScan ~

要是能用Spring, 还有这些破事么，没办法了，祭出法宝--官方网站！

aspectj-maven-plugin 官网

都不用仔细看，打眼一看，发现了什么~

如果AspectJ 连jar包中被编译过的类都可以重新编织切面，把我们的jar包引入默认环境，还不是手拿把掐？

按说明向aspectj-maven-plugin插件的配置中添加weaveDependencies（编织依赖）属性，填入我们的jar包。

再执行编译，居然，就真的，可以正常编织切面了~

刨根问底儿拦不住

weaveDependencies 配置怎么起作用

Aspectj 作为一个专业的、完备的切面解决方案，支持了编译时编织、运行时编织、编译后编织多种切面实现策略，上述的新增配置，其实属于编译后编织的功能。

对比下添加前后的编译日志：

aspectJ配置加载相关日志

编织过程相关日志

过滤出关键信息，可以看到，在添加了编织依赖包的配置之后，aspectj插件将我们的目标Jar 添加到了classpath下。切点和切面被纳入aspectj编译范围，因此可以生效。

Aspectj 怎么和 Maven 相结合

我们知道，Aspectj之所以可以在maven项目的编译阶段进行切面编织，是因为maven plugin的存在。

maven的生命周期

实际上，对于Maven来说，只是定义了一套抽象的生命周期，就像我们平时定义的模板方法，而要想每个方法真正为我们所用，则需要通过具体插件来对每个方法进行绑定。这里的方法，其实就是上图中的phase，也可以叫做目标。

摘自：segmentfault.com/a/1190000038973480

比如，我们最常用的maven-compiler-plugin，是用来编译Java代码的，而我们本文涉及到的插件aspectj-maven-plugin，则是用来编织Aspectj切面的。

Aspectj的编织原理

- 编译时织入

通过上述分析，可以知道，aspectj编译时织入，是在编译期，获取被切点标识的class源文件，并进行重构，将切面逻辑写入并重新生成class文件。

摘自：csdn woshimalingyi/article/details/73252013

这种编译时织入的方式，总的来说是最简单的。

但是，在很多时候，我们希望框架可以足够灵活，也希望切面组件和业务代码可以被独立开发，所以，更适合的编织时机，其实应该是在class被载入虚拟机时。

- Load-Time-Weaving Load时织入

既然对编织提出了更高的要求，那实现起来也必然更复杂。

Load-Time Weaving 官网介绍

JVM是一个相对封闭的容器，内部定义了一系列既定操作，比如类加载、解析、初始化等等。

但是，说封闭也并不是绝对的，他预留了很多的口子，供给容器的使用者在特殊场景下对JVM的内部实现进行干预。但是因为JVM的重要性，任何口子都需要通过代理Java agent 才能被干预。

针对类加载这个模块，JVM预留的口子叫做Java Instrumentation , 而Aspectj为了干预JVM而提供的Agent 则是aspectjweaver.jar

官网对load-time-weaving的说明

那么，具体怎么干预的呢？

public class Agent { 
     ...其他略
    /**
     * JSR-163 preMain Agent entry method
     * @param options
     * @param instrumentation
     */
    public static void premain(String options, Instrumentation instrumentation) {
        /* Handle duplicate agents */
        if (s_instrumentation != null) {
            return;
        }
        s_instrumentation = instrumentation;
        s_instrumentation.addTransformer(s_transformer);
    }
}

可以看到，最重要的一个类Agent，提供了一个premain方法，其注释关注下，JSR-xxx ,表示这是一个Java规范，是标准，只能这么写。

而方法入参中的Instrumentation,是JVM调用该方法时传入的，并且在方法内部，给其添加了一个字节码转换器

看到这里，应该就大概其明白其工作原理了。