參考鏈接：https://blog.csdn.net/dm_vincent/article/details/57526325
https://blog.csdn.net/javazejian/article/details/56267036?utm_source=app
AspectJ
AspectJ是Eclipse旗下的一個項目。至於它和Spring AOP的關係，不妨可將Spring AOP看成是Spring這個龐大的集成框架爲了集成AspectJ而出現的一個模塊。
畢竟很多地方都是直接用到AspectJ裏面的代碼。典型的比如@Aspect，@Around，@Pointcut註解等等。而且從相關概念以及語法結構上而言，兩者其實非常非常相似。比如Pointcut的表達式語法以及Advice的種類，都是一樣一樣的。
那麼，它們的區別在哪裏呢？
最大的區別在於兩者實現AOP的底層原理不太一樣：
Spring AOP: 基於代理(Proxying)
AspectJ: 基於字節碼操作(Bytecode Manipulation)
通過編織階段(Weaving Phase)，對目標Java類型的字節碼進行操作，將需要的Advice邏輯給編織進去，形成新的字節碼。畢竟JVM執行的都是Java源代碼編譯後得到的字節碼，所以AspectJ相當於在這個過程中做了一點手腳，讓Advice能夠參與進來。
而編織階段可以有兩個選擇，分別是加載時編織(也可以成爲運行時編織)和編譯時編織：
哪種方式更好
先下結論：It Depends.
得根據具體需求，不過我個人認爲在對AOP的需求不那麼深入和迫切的時候，使用Spring AOP足矣。
畢竟Spring作爲一個以集成起家的框架，在設計Spring AOP的時候也是爲了減輕開發人員負擔而做了不少努力的。它提供的開箱即用(Out-of-the-box)的衆多AOP功能讓很多開發人員甚至都不知道什麼是AOP，就算知道了AOP是Spring的一大基石或者@Transactional和@Cacheable等等常用註解是藉助了AOP的力量，但是再深入恐怕就有點勉爲其難了。這是優點也是缺點，當需要對AOP的實現做出精細化調整的時候，就會有力不從心的感覺。
這個時候，就可以考慮使用AspectJ。AspectJ的功能更加全面和強大。支持全部的Pointcut類型。
這裏進行了一個簡單的比較，摘錄並簡單翻譯(括號內是我添加的補充)如下：
Spring-AOP Pros
比AspectJ更簡單，不需要使用Load-Time Weaving以及AspectJ編譯器(爲了Compile-Time Weaving)
當使用@Aspect註解時可以很方便的遷移到AspectJ AOP實現
使用代理模式和裝飾模式
Spring-AOP Cons
由於是基於代理的AOP，所以基本上只能選擇方法execution這一個Pointcut原語
在類本身中調用另一個方法的時候Aspects不會生效
有一點運行時的額外開銷
無法爲不是從Spring Factory中創建的對象添加Aspect(只對Spring Bean有效)