JRockit JVM對AOP的支持，第1部分

2019-11-18 12:14:32

字體：大中小

來源：轉載

供稿：網友

　　面向方面編程（aspect-Oriented PRogramming，AOP）正在軟件社區和企業界中獲得強大的發展動力。自從20世紀90年代Xerox引入了AOP之后，AOP經過研究團體、開源社區和企業界的數次推動和革新，已經越來越成熟了。在java領域，近兩年開源運動已經獲得了極大的推動，這導致AspectWerkz和AspectJ最近合并在一起，現在它們都歸入Eclipse Foundation，代號為AspectJ 5。AspectJ是由BEA Systems公司和IBM公司發起的，可以認為它是使用Java實現AOP的事實標準。
　　
　　隨著AOP流行程度的逐漸增加和研究團體的不懈努力，詞匯表、概念和實現已經趨于一致，這得到了更完善的工具支持，答應更好的開發者體驗，比如，出現了AspectJ Eclipse插件AspectJ Development Tools (AJDT)。
　　
　　AOP已經經歷了多種實現技術，從源代碼操作到字節碼測試（這是Java中一種廣泛采用的技術，非凡是在Java 5 JVMTI出現之后）。如今，在應用程序治理和監視領域，有多種應用AOP的企業級產品采用了這種技術，并且最近隨著基于POJO（Plain Old Java Object）的中間件和透明集群的出現而變得越來越流行。
　　
　　因此，無論如何，字節碼測試越來越可能成為你最終必須把握的東西。你將不得不回答下面這些問題：字節碼測試技術究竟能夠把可治理性、透明性和效率擴展和實現到什么程度？依靠于字節碼測試的AOP實現會不會發展到盡頭，以至無法為更高的效率、易用性和動態性做進一步的革新？JVM對AOP的支持會解決這些問題嗎？能夠解決到什么程度？本系列文章通過揭示BEA JRockit JVM AOP支持的內幕以及激發在這個領域中的爭論，來提供這些問題的具體答案。
　　
　　第一篇文章介紹AOP概念并且簡單地說明為什么許多實現（比如AspectJ）要基于字節碼操作。它解釋了與字節碼測試技術相關的一些限制，以及它們為什么會在長期運行過程中影響可伸縮性和可用性。然后，最后一節介紹JRockit JVM對AOP的支持，這一技術的目標是克服這些限制，為AOP和其他截取機制提供一個高效率的后端。
　　
　　本系列文章的第2部分將通過具體的API細節和示例來說明這種支持的力度。
　　
　　什么是面向方面編程?
　　
　　面向對象的分析和設計引入了繼續、抽象和多態等概念，由此為我們提供了降低軟件復雜性的工具。但是，開發人員在軟件設計過程中仍然經常會面對無法用面向對象軟件開發技術輕易解決的問題。這些問題之一就是如何處理應用程序中的橫切關注點（Cross-cutting concerns）。
　　
　　橫切關注點
　　
　　關注點就是設計人員感愛好的某一概念或區域。例如，在一個訂貨系統中，核心關注點可能是訂單處理和生產，而系統關注點可能是事務處理和安全治理。
　　
　　橫切關注點是影響多個類或模塊的關注點，即未能很好地局部化和模塊化的關注點。
　　
　　橫切關注點的表現有：
　　
　　·代碼糾結——當一個模塊或代碼段同時治理多個關注點時發生這種情況。
　　
　　·代碼分散——當一個關注點分布在許多模塊中并且未能很好地局部化和模塊化時發生這種情況。
　　
　　這些現象會從幾個方面影響軟件；例如，它們會導致軟件難以維護和重用，并且難以編寫和理解。
　　
　　關注點的隔離
　　
　　面向方面編程試圖通過引入“關注點的隔離”這一概念來解決這些問題。采用這一概念，可以以一種模塊化而且適當局部化的方式實現關注點。AOP解決這個問題的辦法是在設計空間中增加額外一維，并且引入了一些構造，這些構造使我們能夠定義橫切關注點，將它們轉移進新的維，并且以模塊化方式將它們打包。
　　
　　AOP引入的新構造
　　
　　AOP引入了一些新的構造。聯結點（join point）構造準確反映了程序流中定義良好的點，例如調用方法的地方或者捕捉異常的地方。切點（pointcut）構造使我們能夠挑選出匹配某一標準的聯結點。建議（advice）構造使我們能夠添加應該在匹配的聯結點執行的代碼。引入（introdUCtion）構造使我們能夠向現有的類添加額外的代碼，例如，向現有的類添加方法、字段或接口。最后，AOP引入了方面（aspect）構造，這是模塊化的AOP單元。方面由聯結點、切點、建議和引入來定義（也稱為類型間聲明）。
　　
　　用AspectJ實現AOP的示例
　　
　　下面是一些簡單的AspectJ 5代碼示例，它們在一定程度上說明了如何在代碼中實現上面定義的概念。要想進一步了解特定的AOP語言細節，請參考AspectJ文檔。
　　
　　// using a dedicated syntax
　　// that compliments the Java language
　　public aspect Foo {
　　
　　pointcut someListOperation() : call(* List+.add(..));
　　
　　pointcut userScope() : within(com.biz..*);
　　
　　before() : someListOperation() && userScope() {
　　System.out.println("called: "
　　+ thisJoinPoint.getSignature()
　　);
　　}
　　}
　　以上代碼使用了一種專門的語法。可以使用Java注釋寫出等效的代碼。
　　
　　// the Java 5 annotations approach
　　@Aspect
　　public class Foo {
　　
　　@Pointcut("call(* java.util.List+.add(..))")
　　public void someListOperation() {}
　　
　　@Pointcut("within(com.biz..*)")
　　public void userScope() {}
　　
　　@Before("someListOperation() && userScope()")
　　public void before(JoinPoint thisJoinPoint) {
　　System.out.println("called: "
　　+ thisJoinPoint.getSignature()
　　);
　　}
　　}
　　以上代碼定義了一個方面Foo，它具有兩個切點someListOperation()和userScope()。這些切點將在應用程序中挑選出一組聯結點。它們組合在一起成為一個布爾表達式someListOperation() && userScope()，這樣在擴展List的任何類型實例上，在每次調用名為add的任何方法之前都會執行before建議，前提條件是：調用是從com.biz包（及其子包）中的某些代碼發出的。這樣，before建議會在所有這些聯結點上輸出將被調用的方法的簽名。第二個代碼示例定義了一個非常相似的方面，只是采用了一種依靠Java 5注釋的替代語法。
　　
　　什么是編織?
　　
　　正如前一節和代碼示例所描述的，方面可以對整個應用程序進行橫切。編織（waving）就是將方面和常規的面向對象應用程序“織”成一個單元（單個應用程序）的過程。
　　
　　編織可以在不同時期進行：
　　
　　編譯時編織：例如，在部署之前（因此也在運行時之前）進行代碼的后期處理（AspectJ 1.x中采用）。
　　
　　裝載時編織：在裝載類的時候（也就是在部署時）進行編織（AspectWerkz 2.0中采用）。
　　
　　運行時編織：編織可以在應用程序生命周期中的任何時候進行（JRockit 和SteamLoom中采用）。
　　
　　這個過程還能以多種不同方式進行：
　　
　　源代碼編織：輸入是已開發的源代碼，而輸出是經過修改的調用方面的源代碼（AspectJ 1.x中采用）。
　　
　　字節碼編織：輸入是編譯出來的應用程序類的字節碼，而輸出是經過調整的編織過的應用程序的字節碼（AspectWerkz 2.0和AspectJ 1.1以及更高版本中采用）。
　　
　　源代碼編織受到一定的限制，所有源代碼必須可用并提供給編織器，這樣才能應用方面。這就導致某些目標不可能實現，例如實現通用的監視服務。編譯時編織也受到同一問題的困擾：在編譯后進行部署之前，需要把將部署的所有字節碼預備好。
　　
　　本系列文章全面介紹了字節碼編織和JVM 編織，從下一節開始將討論這些內容。
　　
　　隨便提一下動態代理（Dynamic proxies），這是一種受限的編織方式，它在JVM中已經存在了一段時間了。這個API自從1.3版開始就是JDK的一部分，它答應為一個接口（和/或一系列接口）創建一個動態虛擬代理，這樣就有可能截取對這個代理的每個調用，并且將其重定向到你希望的任何地方。根據定義，這并不是真正的編織，但是它與編織類似的地方是它提供了進行方法截取的簡單方式。各種框架采用它來進行簡單的AOP，例如Spring Framework。
　　
　　基于字節碼測試進行編織的問題
　　
　　值得強調的是，下面提到的問題與字節碼測試相關，因此，當前的AOP實現（比如AspectJ）會受到它們的困擾。總的來說，這些問題會影響所有基于字節碼測試的產品，比如應用程序監視解決方案、分析工具或其他應用AOP的解決方案。
　　
　　測試是低效率的
　　
　　編織的實際測試部分往往非常消耗CPU，而且有時還會消耗大量內存。這會影響啟動時間。例如，要想截取所有對toString()方法的調用或者對某個字段的所有訪問，需要逐一分析所有類中的幾乎每一條字節碼指令。這還意味著字節碼測試框架將創建許多中間表示結構，以一種有用的方式公開字節碼指令。這可能意味著編織器需要分析整個應用程序（包括第三方庫等）中所有類中的所有字節碼指令。在糟糕的情況下，這可能會涵蓋超過10, 000個類。
　　
　　假如使用多個編織器，那么開銷就會成倍增加。
　　
　　雙重記錄：為編織器構建類數據庫是代價高昂的
　　
　　為了知道類、方法或字段是否應該被編織，編織器需要對這個類或成員的元數據進行匹配。大多數AOP框架和應用AOP的產品具有某種高級表達式語言（切點表達式），用于定義代碼塊（建議）應該被編織在哪里（在哪些聯結點上）。例如，這些表達式語言使你能夠挑選出具有某種返回類型的所有方法，這種類型實現了類型T的接口。在代表對特定方法M進行調用的字節碼指令中，這一信息是不可用的。了解這個特定方法M是否應該被編織的唯一辦法是，在某種形式的類數據

上一篇：Java的垃圾回收機制詳解和調優

下一篇：理論與實踐: 用弱引用堵住內存泄漏