JSR-107（JCache）正在制定當中，將成為Java EE 7的一部分

分布式緩存在提升性能和可伸縮性時舉足輕重，但Java目前還沒有任何完整、標準的緩存機制。JSR-107（JCache API）正在緊鑼密鼓的制定當中，以后會成為Java EE 7的一部分。 JSR-107這些年有些聲名狼藉，因為它是一個很老的規范，但到現在還沒有完成，不過隨著對緩存的需求越來越多，JSR-107最終是要問世的。

Greg Luck是JSR-107規范的共同牽頭人，長期參與領先的開源Java緩存實現Ehcache的開發和維護。InfoQ有幸對Greg進行了采訪。

InfoQ：JCache真的會成為Java EE 7的一部分么？

是的，Java EE 7（JSR-342）已經把JCache（JSR-107）引入為候選者了。 JSR-342規范的領導者已經對JSR-107展開了評測。JSR-107規范有一個強制的功能集和兩個可選功能：注解和JTA。我們想讓Java EE 7引入的正是這個完整版本。同時，我們還和Java EE 7規范的領導者Linda DeMichiel，以及Oracle的Java EE 7團隊進行著密切的協調合作。

InfoQ：緩存對Java EE和Java來說，似乎是一個重要卻缺失的功能，你覺得JCache為什么會花這么長時間呢？

JSR-107的規范號比較小，從這可以看出來，這個規范十年前就被想到了。它最初由Oracle開始做，但后來被擱置了好幾年。過去三年里我一直參與其中，Terracotta和Oracle在去年加強了對JSR-107的投入。

緩存向來都不是規劃在架構里，而是企業應用在生產環境里出問題之后才添加到企業應用里的。有一個例外是ORM，因為它本身的方法就需要一個緩存。

Greg接著說，Java EE 7是針對云的，規范領導者也看到了緩存的價值。可以推斷一下：一旦開發人員開始用緩存解決性能問題，他們就能看到緩存的價值。然后，認為緩存很不錯的開發人員在新項目和解決方案一開始就會引入緩存，而不是等到出現性能問題的時候才加以引入。

這已經讓緩存成為架構里公認的一部分，而不僅僅是性能補丁。Greg對NoSQL和Ehcache等緩存解決方案進行了對比，Ehcache這些緩存解決方案在很多方面都試圖解決同樣的伸縮性問題，只是采用了不同的方式。Ehcahe和Java里的memcached，以及整個行業內的緩存，兩者的應用都急劇增長。比如說，Memcached是個容錯的分布式緩存，從消費者的注意力份額（Mindshare）來講，2007年它還相對默默無聞，現在則超越了位列第一的商業分布式緩存Oracle Coherence（Coherence自身也在增長），這表明緩存的市場有很大潛力。

Greg就職的Terracotta已經開始在Ehcache里實現規范，其中包括BigMemory、Cache資源預留等功能，同時會支持獨立模式和分布式模式。Ehcache是眾所周知的開源Java緩存，尤其被使用過Hibernate的用戶所熟知。

和大多數Java緩存實現一樣，Ehcache有一個本地內存復制模式，這種模式和純粹的分布式版本相比具有顯著的性能優勢。雖然Memcached激發了大家對緩存解決方案的興趣和需求，但更快、符合標準的實現也會有一席之地。有了標準API，供應商就可以有自己的實現，開源實現也能在性能、易用性、對彈性云的支持、可伸縮性等更多方面和供應商的產品展開競爭。

緩存現在似乎愈發成為企業和云解決方案的特定組件，因此很多供應商目前都正在實現或是打算實現JCache，包括Terracotta、Oracle、JBoss、Caucho、IBM、Google App Engine等。

針對JSR-107和幾個月前才推出的JSR-347（數據網格JSR），大家似乎有一些爭議。

InfoQ：如果JSR-107和JSP-347有重疊的內容怎么辦？JSR-107和JSR-347的范圍是怎樣劃定的？

JSR-347定義為JSR-107的超集，它對JSR-107有一個依賴，額外增加了數據網格功能。JSR-107進行了精心設計，同時支持獨立緩存和分布式緩存，與分布式緩存實現的拓撲結構沒有關系。JSR-107已接近尾聲，我們希望這對JSR-347的定義有所幫助。

JSR-347定義了回收、復制、分發和事務的行為。JSR-347花費了更多的精力去定義一套健壯的異步非阻塞API，這對數據網格來說是很重要的。JSR-347會增加更多的API，也會同時支持JSR-107的API。

InfoQ：JSR-107是不是只關注Java EE？對Java SE有關注么？

JCache是針對Java EE的，但并不妨礙Java SE使用它。Ehcache等實現在Java SE、Java EE和Spring上都能運行。

API分成兩部分：沒有依賴的基本Profile，這在Java SE上就可以使用；添加了JTA和緩存方法注解的完整Profile。完整版本是針對Java EE 6、Spring和其他企業環境的，在現有的企業環境里都能工作。被納入Java EE 7之后，Java開發人員就會意識到可以使用它。我們希望JSR 166組能為JDK 8構建一個簡單的進程內緩存。

InfoQ：JCache的進展、過程和設計有哪些主要的變化和改進？

我們已經構建了API、RI（參考實現）和TCK（技術兼容性套件），正在把它們發布到oss.sonatype.org上。所有的源代碼都放在GitHub上。GitHub上的Readme給出了完整的介紹和鏈接。整個過程和規范都是開放的，源代碼和社區也都是開放的。

從設計的角度看，基本組成部分有一個CacheManager，用來持有、控制緩存集合。緩存有一些條目。我們還有一個類似API的映射，可以和以下附加功能進行交互：

1. 原子操作
2. 通過緩存讀取
3. 通過緩存寫入
4. 緩存事件監聽器
5. 統計
6. 事務
7. 注解

緩存很多地方都用了泛型。我們不限制分布式緩存的拓撲結構，處理分布式緩存時也比較謹慎。Terracotta和Oracle都出售分布式緩存產品，我們打算讓這套API有助于這些產品的應用。

開發人員會發現這套API簡單而強大，并且涵蓋了大多數情況。

JSR-107公開了它的郵件列表，把規范也發布為公開的Google文件，對JSR如何公開來說，這已經達到一定高的標準了。和過去的一些JSR相比，JSR-107的做法是一個里程碑。

JSR-107姍姍來遲，但最終會問世。分布式緩存在提升性能和可伸縮性時舉足輕重，好在Java將有用于緩存的標準API。Java世界里，分布式緩存的需求有非常大的潛力，JSR-107最有可能為Java的前景錦上添花。

查看英文原文：JSR-107, JCache: Alive and Going to be Part of Java EE 7

譯者 王麗娟 一致從事Java EE中間件和Java EE企業應用的開發，關注軟件架構技術，有志成長為一名優秀的架構師。
來自: InfoQ