引言
眾所周知，一旦提到AOP，相信大家都是條件反射的想到JDK代理和CGLib代理，沒錯，這兩個代理都是在運行時內(nèi)存中臨時生成代理類，故而又稱作運行時增強——動態(tài)代理。世間萬物都不是絕對的，既然有動態(tài)代理，那么，是否有想過：是不是存在靜態(tài)代理呢？
LTW（Load Time Weaving）
其實，除了運行時織入切面的方式外，我們還有一種途徑進行切面織入，它可以在類加載期通過字節(jié)碼轉換，進而將目標織入切入點（目標類），這種方式就是LTW，即靜態(tài)代理（靜待代理也被稱作編譯時增強，后面會有相關代碼樣例）。
LTW在Java5的時候就被引入了，想要了解其原理，先要了解一個知識——Instrument包。
java.lang.instrument包的工作原理
JDK5.0時引入了此包，目的就是為了能對JVM底層組建進行訪問。如何訪問？其實說來個人覺得還挺麻煩的，就是需要通過JVM的啟動參數(shù)-javaagent在啟動時獲取JVM內(nèi)部組件的引用。參數(shù)格式如下：
-javaagent:<jarpath>[=options]
此處先賣個關子，不急著解釋參數(shù)中的jarpath和options，后面的運行代碼及結果的樣例中會進行針對使用紅框標記說明，效果更好。
那么，它和AOP有和關系呢？因為它在JVM啟動時會裝配并應用ClassTransformer，對類字節(jié)碼進行轉換，進而實現(xiàn)AOP的功能。
下面說一下instrument包下的兩個重要接口：
- ClassFileTransformer
它是Class文件轉換器接口，這個接口有且僅有一個方法，如圖所示：
注意：transform方法會有一個返回值，類型是byte[]，表示轉換后的字節(jié)碼，但是如果返回為空，則表示不進行節(jié)碼轉換處理，千萬不要當作是把原先類的字節(jié)碼清空。
- Instrumentation
這個接口提供了很多方法，我們主要注意一個方法即可，即：addTransformer方法，它的作用就是把一些ClassFileTransformer注冊到JVM內(nèi)部，接口如圖所示：
具體工作原理是這樣的：
① ClassFileTransformer實例注冊到JVM之后，JVM在加載Class文件時，就會先調(diào)用ClassFileTransformer的transform()方法進行字節(jié)碼轉換；
② 若注冊了多個ClassFileTransformer實例，則按照注冊時的順序進行一次調(diào)用。
這樣也就實現(xiàn)了從JVM層面截獲字節(jié)碼，進而織入操作者自己希望添加的邏輯，即實現(xiàn)AOP效果。
代碼及演示效果
說了這么多，來點干貨，下面用代碼給大家演示一下如何向JVM中注冊轉換器實現(xiàn)AOP的。為了方便大家閱讀，重要的說明筆者已經(jīng)寫在代碼的注釋上或者圖片空白處，大家注意查看。
- 首先，我們實現(xiàn)一個自己的轉換器，用于模擬需要切入的功能
注意，這里再強調(diào)下，代碼中的return null;并不是將加載類的字節(jié)碼置空。
- 其次，我們再實現(xiàn)一個代理類
為什么要實現(xiàn)代理類內(nèi)，因為不是動態(tài)代理呀。。。
- 最后，我們寫一個主函數(shù)，代表程序入口
到此為止，我們的Demo算是完成了，先來看一下運行的結果：
打jar的時候需要注意的地方
大家看到執(zhí)行結果的截圖中，cmd界面下運行javaagent參數(shù)時指定了一個myTransformer.jar，這個jar是我們自己需要打出來的，可以直接使用eclipse具體步驟如下圖所示，注意圖中說明：
總結
大家可以看到，其實使用此類代理并沒有動態(tài)代理方便，甚至轉換器可能會對JVM所有類都產(chǎn)生影響，操作起來更新相對麻煩，實際生產(chǎn)部署時會有很多不便。
但是，寫這些是為了讓大家更好、更多的去了解AOP，我們所熟知的AOP其實還有很多東西有待我們自身去學習和發(fā)現(xiàn)，其實Spring在"操作麻煩"這方面還是做了不少事的，提供了一些xml的配置化管理（此處就不再說了，因為感覺一說又是一大長篇，有興趣的大家可以自己去看看，多了解寫東西總沒有壞處），很多情況下已經(jīng)不需要再配置javaagent參數(shù)了。
最后提一句，如果在面試中提到了這些，相信面試官也會有加分吧。
