从一个Aspectj织入失效问题的解决说起
事出反常必有妖
组里兄弟领了个任务，维护一个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类验证切面是否正确：
编译时，切面被正常的编织进方法中了~
说明正常场景下是没问题的，接下来，打包，发布，让第三方项目引用。
引用第三方切面实现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插件将我们的目标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文件。
这种编译时织入的方式，总的来说是最简单的。
但是，在很多时候，我们希望框架可以足够灵活，也希望切面组件和业务代码可以被独立开发，所以，更适合的编织时机，其实应该是在class被载入虚拟机时。
- Load-Time-Weaving Load时织入
既然对编织提出了更高的要求，那实现起来也必然更复杂。
Load-Time Weaving 官网介绍
JVM是一个相对封闭的容器，内部定义了一系列既定操作，比如类加载、解析、初始化等等。
但是，说封闭也并不是绝对的，他预留了很多的口子，供给容器的使用者在特殊场景下对JVM的内部实现进行干预。但是因为JVM的重要性，任何口子都需要通过代理Java agent 才能被干预。
针对类加载这个模块，JVM预留的口子叫做Java Instrumentation , 而Aspectj为了干预JVM而提供的Agent 则是aspectjweaver.jar
那么，具体怎么干预的呢？
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调用该方法时传入的，并且在方法内部，给其添加了一个字节码转换器
看到这里，应该就大概其明白其工作原理了。
吾日三省吾身
本篇文章从一个日常的小问题入手，将aspectj的编织问题、依赖的maven生命周期和切面编织时机及其实现原理进行了阐述。
其实这都不是重点，重点只有一个：遇到问题，看官网文档才是真正有效的解决之道~