Spring Cache
緩存是實際工作中非經常常使用的一種提高性能的方法, 我們會在很多場景下來使用緩存。
本文通過一個簡單的樣例進行展開，通過對照我們原來的自己定義緩存和 spring 的基於凝視的 cache 配置方法，展現了 spring cache 的強大之處，然后介紹了其主要的原理，擴展點和使用場景的限制。通過閱讀本文。你應該能夠短時間內掌握 spring 帶來的強大緩存技術。在非常少的配置下就可以給既有代碼提供緩存能力。
概述
Spring 3.1 引入了激動人心的基於凝視（annotation）的緩存（cache）技術，它本質上不是一個具體的緩存實現方案（比如EHCache 或者 OSCache），而是一個對緩存使用的抽象，通過在既有代碼中加入少量它定義的各種 annotation，即能夠達到緩存方法的返回對象的效果。
Spring 的緩存技術還具備相當的靈活性。不僅能夠使用 SpEL（Spring Expression Language）來定義緩存的 key 和各種 condition，還提供開箱即用的緩存暫時存儲方案，也支持和主流的專業緩存比如 EHCache 集成。
其特點總結例如以下：
- 通過少量的配置 annotation 凝視就可以使得既有代碼支持緩存
- 支持開箱即用 Out-Of-The-Box，即不用安裝和部署額外第三方組件就可以使用緩存
- 支持 Spring Express Language，能使用對象的不論什么屬性或者方法來定義緩存的 key 和 condition
- 支持 AspectJ，並通過事實上現不論什么方法的緩存支持
- 支持自己定義 key 和自己定義緩存管理者，具有相當的靈活性和擴展性
本文將針對上述特點對 Spring cache 進行具體的介紹，主要通過一個簡單的樣例和原理介紹展開，然后我們將一起看一個比較實際的緩存樣例。最后會介紹 spring cache 的使用限制和注意事項。
好吧。讓我們開始吧
我們曾經怎樣自己實現緩存的呢
這里先展示一個全然自己定義的緩存實現，即不用不論什么第三方的組件來實現某種對象的內存緩存。
場景例如以下：
對一個賬號查詢方法做緩存，以賬號名稱為 key，賬號對象為 value，當以同樣的賬號名稱查詢賬號的時候，直接從緩存中返回結果。否則更新緩存。賬號查詢服務還支持 reload 緩存（即清空緩存）
首先定義一個實體類：賬號類，具備主要的 id 和 name 屬性。且具備 getter 和 setter 方法
public class Account {
private int id;
private String name;
public Account(String name) {
this.name = name;
}
public int getId() {
return id;
}
public void setId(int id) {
this.id = id;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}然后定義一個緩存管理器，這個管理器負責實現緩存邏輯，支持對象的添加、改動和刪除，支持值對象的泛型。
例如以下：
import com.google.common.collect.Maps;
import java.util.Map;
/**
* @author wenchao.ren
* 2015/1/5.
*/
public class CacheContext<T> {
private Map<String, T> cache = Maps.newConcurrentMap();
public T get(String key){
return cache.get(key);
}
public void addOrUpdateCache(String key,T value) {
cache.put(key, value);
}
// 依據 key 來刪除緩存中的一條記錄
public void evictCache(String key) {
if(cache.containsKey(key)) {
cache.remove(key);
}
}
// 清空緩存中的全部記錄
public void evictCache() {
cache.clear();
}
}好，如今我們有了實體類和一個緩存管理器，還須要一個提供賬號查詢的服務類。此服務類使用緩存管理器來支持賬號查詢緩存。例如以下：
import com.google.common.base.Optional;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Service;
import javax.annotation.Resource;
/**
* @author wenchao.ren
* 2015/1/5.
*/
@Service
public class AccountService1 {
private final Logger logger = LoggerFactory.getLogger(AccountService1.class);
@Resource
private CacheContext<Account> accountCacheContext;
public Account getAccountByName(String accountName) {
Account result = accountCacheContext.get(accountName);
if (result != null) {
logger.info("get from cache... {}", accountName);
return result;
}
Optional<Account> accountOptional = getFromDB(accountName);
if (!accountOptional.isPresent()) {
throw new IllegalStateException(String.format("can not find account by account name : [%s]", accountName));
}
Account account = accountOptional.get();
accountCacheContext.addOrUpdateCache(accountName, account);
return account;
}
public void reload() {
accountCacheContext.evictCache();
}
private Optional<Account> getFromDB(String accountName) {
logger.info("real querying db... {}", accountName);
//Todo query data from database
return Optional.fromNullable(new Account(accountName));
}
}如今我們開始寫一個測試類，用於測試剛才的緩存是否有效
import org.junit.Before;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import static org.junit.Assert.*;
public class AccountService1Test {
private AccountService1 accountService1;
private final Logger logger = LoggerFactory.getLogger(AccountService1Test.class);
@Before
public void setUp() throws Exception {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("applicationContext1.xml");
accountService1 = context.getBean("accountService1", AccountService1.class);
}
@Test
public void testInject(){
assertNotNull(accountService1);
}
@Test
public void testGetAccountByName() throws Exception {
accountService1.getAccountByName("accountName");
accountService1.getAccountByName("accountName");
accountService1.reload();
logger.info("after reload ....");
accountService1.getAccountByName("accountName");
accountService1.getAccountByName("accountName");
}
}依照分析，運行結果應該是：首先從數據庫查詢，然后直接返回緩存中的結果，重置緩存后，應該先從數據庫查詢。然后返回緩存中的結果. 查看程序運行的日志例如以下：
00:53:17.166 [main] INFO c.r.s.cache.example1.AccountService - real querying db... accountName
00:53:17.168 [main] INFO c.r.s.cache.example1.AccountService - get from cache... accountName
00:53:17.168 [main] INFO c.r.s.c.example1.AccountServiceTest - after reload ....
00:53:17.168 [main] INFO c.r.s.cache.example1.AccountService - real querying db... accountName
00:53:17.169 [main] INFO c.r.s.cache.example1.AccountService - get from cache... accountName能夠看出我們的緩存起效了，可是這樣的自己定義的緩存方案有例如以下劣勢：
- 緩存代碼和業務代碼耦合度太高。如上面的樣例，AccountService 中的 getAccountByName（）方法中有了太多緩存的邏輯，不便於維護和變更
- 不靈活，這樣的緩存方案不支持依照某種條件的緩存，比方僅僅有某種類型的賬號才須要緩存，這樣的需求會導致代碼的變更
- 緩存的存儲這塊寫的比較死，不能靈活的切換為使用第三方的緩存模塊
假設你的代碼中有上述代碼的影子，那么你能夠考慮依照以下的介紹來優化一下你的代碼結構了，也能夠說是簡化。你會發現，你的代碼會變得優雅的多！
Spring cache是怎樣做的呢
我們對AccountService1 進行改動。創建AccountService2:
import com.google.common.base.Optional;
import com.rollenholt.spring.cache.example1.Account;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;
/**
* @author wenchao.ren
* 2015/1/5.
*/
@Service
public class AccountService2 {
private final Logger logger = LoggerFactory.getLogger(AccountService2.class);
// 使用了一個緩存名叫 accountCache
@Cacheable(value="accountCache")
public Account getAccountByName(String accountName) {
// 方法內部實現不考慮緩存邏輯，直接實現業務
logger.info("real querying account... {}", accountName);
Optional<Account> accountOptional = getFromDB(accountName);
if (!accountOptional.isPresent()) {
throw new IllegalStateException(String.format("can not find account by account name : [%s]", accountName));
}
return accountOptional.get();
}
private Optional<Account> getFromDB(String accountName) {
logger.info("real querying db... {}", accountName);
//Todo query data from database
return Optional.fromNullable(new Account(accountName));
}
}我們注意到在上面的代碼中有一行：
@Cacheable(value="accountCache")
這個凝視的意思是，當調用這種方法的時候。會從一個名叫 accountCache 的緩存中查詢，假設沒有，則運行實際的方法（即查詢數據庫），並將運行的結果存入緩存中。否則返回緩存中的對象。這里的緩存中的 key 就是參數 accountName，value 就是 Account 對象。“accountCache”緩存是在 spring*.xml 中定義的名稱。我們還須要一個 spring 的配置文件來支持基於凝視的緩存
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:cache="http://www.springframework.org/schema/cache"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/cache
http://www.springframework.org/schema/cache/spring-cache.xsd">
<context:component-scan base-package="com.rollenholt.spring.cache"/>
<context:annotation-config/>
<cache:annotation-driven/>
<bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager">
<property name="caches">
<set>
<bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean">
<property name="name" value="default"/>
</bean>
<bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean">
<property name="name" value="accountCache"/>
</bean>
</set>
</property>
</bean>
</beans>注意這個 spring 配置文件有一個關鍵的支持緩存的配置項：
<cache:annotation-driven />這個配置項缺省使用了一個名字叫 cacheManager 的緩存管理器，這個緩存管理器有一個 spring 的缺省實現，即 org.springframework.cache.support.SimpleCacheManager。這個緩存管理器實現了我們剛剛自己定義的緩存管理器的邏輯，它須要配置一個屬性 caches，即此緩存管理器管理的緩存集合，除了缺省的名字叫 default 的緩存，我們還自己定義了一個名字叫 accountCache 的緩存，使用了缺省的內存存儲方案 ConcurrentMapCacheFactoryBean，它是基於 java.util.concurrent.ConcurrentHashMap 的一個內存緩存實現方案。
然后我們編寫測試程序：
import org.junit.Before;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import static org.junit.Assert.*;
public class AccountService2Test {
private AccountService2 accountService2;
private final Logger logger = LoggerFactory.getLogger(AccountService2Test.class);
@Before
public void setUp() throws Exception {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("applicationContext2.xml");
accountService2 = context.getBean("accountService2", AccountService2.class);
}
@Test
public void testInject(){
assertNotNull(accountService2);
}
@Test
public void testGetAccountByName() throws Exception {
logger.info("first query...");
accountService2.getAccountByName("accountName");
logger.info("second query...");
accountService2.getAccountByName("accountName");
}
}以上測試代碼主要進行了兩次查詢。第一次應該會查詢數據庫，第二次應該返回緩存。不再查數據庫，我們運行一下。看看結果
01:10:32.435 [main] INFO c.r.s.c.example2.AccountService2Test - first query...
01:10:32.456 [main] INFO c.r.s.cache.example2.AccountService2 - real querying account... accountName
01:10:32.457 [main] INFO c.r.s.cache.example2.AccountService2 - real querying db... accountName
01:10:32.458 [main] INFO c.r.s.c.example2.AccountService2Test - second query...能夠看出我們設置的基於凝視的緩存起作用了，而在 AccountService.java 的代碼中。我們沒有看到不論什么的緩存邏輯代碼。僅僅有一行凝視：@Cacheable(value="accountCache")，就實現了主要的緩存方案，是不是非常強大？
怎樣清空緩存
好，到眼下為止，我們的 spring cache 緩存程序已經運行成功了。可是還不完美，由於還缺少一個重要的緩存管理邏輯：清空緩存.
當賬號數據發生變更，那么必須要清空某個緩存，另外還須要定期的清空全部緩存，以保證緩存數據的可靠性。
為了加入清空緩存的邏輯。我們僅僅要對 AccountService2.java 進行改動，從業務邏輯的角度上看，它有兩個須要清空緩存的地方
- 當外部調用更新了賬號，則我們須要更新此賬號相應的緩存
- 當外部調用說明又一次載入，則我們須要清空全部緩存
我們在AccountService2的基礎上進行改動，改動為AccountService3，代碼例如以下：
import com.google.common.base.Optional;
import com.rollenholt.spring.cache.example1.Account;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.cache.annotation.CacheEvict;
import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;
/**
* @author wenchao.ren
* 2015/1/5.
*/
@Service
public class AccountService3 {
private final Logger logger = LoggerFactory.getLogger(AccountService3.class);
// 使用了一個緩存名叫 accountCache
@Cacheable(value="accountCache")
public Account getAccountByName(String accountName) {
// 方法內部實現不考慮緩存邏輯，直接實現業務
logger.info("real querying account... {}", accountName);
Optional<Account> accountOptional = getFromDB(accountName);
if (!accountOptional.isPresent()) {
throw new IllegalStateException(String.format("can not find account by account name : [%s]", accountName));
}
return accountOptional.get();
}
@CacheEvict(value="accountCache",key="#account.getName()")
public void updateAccount(Account account) {
updateDB(account);
}
@CacheEvict(value="accountCache",allEntries=true)
public void reload() {
}
private void updateDB(Account account) {
logger.info("real update db...{}", account.getName());
}
private Optional<Account> getFromDB(String accountName) {
logger.info("real querying db... {}", accountName);
//Todo query data from database
return Optional.fromNullable(new Account(accountName));
}
}我們的測試代碼例如以下：
import com.rollenholt.spring.cache.example1.Account;
import org.junit.Before;
import org.junit.Test;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.support.ClassPathXmlApplicationContext;
public class AccountService3Test {
private AccountService3 accountService3;
private final Logger logger = LoggerFactory.getLogger(AccountService3Test.class);
@Before
public void setUp() throws Exception {
ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("applicationContext2.xml");
accountService3 = context.getBean("accountService3", AccountService3.class);
}
@Test
public void testGetAccountByName() throws Exception {
logger.info("first query.....");
accountService3.getAccountByName("accountName");
logger.info("second query....");
accountService3.getAccountByName("accountName");
}
@Test
public void testUpdateAccount() throws Exception {
Account account1 = accountService3.getAccountByName("accountName1");
logger.info(account1.toString());
Account account2 = accountService3.getAccountByName("accountName2");
logger.info(account2.toString());
account2.setId(121212);
accountService3.updateAccount(account2);
// account1會走緩存
account1 = accountService3.getAccountByName("accountName1");
logger.info(account1.toString());
// account2會查詢db
account2 = accountService3.getAccountByName("accountName2");
logger.info(account2.toString());
}
@Test
public void testReload() throws Exception {
accountService3.reload();
// 這2行查詢數據庫
accountService3.getAccountByName("somebody1");
accountService3.getAccountByName("somebody2");
// 這兩行走緩存
accountService3.getAccountByName("somebody1");
accountService3.getAccountByName("somebody2");
}
}在這個測試代碼中我們重點關注testUpdateAccount()方法。在測試代碼中我們已經凝視了在update完account2以后，再次查詢的時候。account1會走緩存，而account2不會走緩存，而去查詢db，觀察程序運行日志，運行日志為：
01:37:34.549 [main] INFO c.r.s.cache.example3.AccountService3 - real querying account... accountName1
01:37:34.551 [main] INFO c.r.s.cache.example3.AccountService3 - real querying db... accountName1
01:37:34.552 [main] INFO c.r.s.c.example3.AccountService3Test - Account{id=0, name='accountName1'}
01:37:34.553 [main] INFO c.r.s.cache.example3.AccountService3 - real querying account... accountName2
01:37:34.553 [main] INFO c.r.s.cache.example3.AccountService3 - real querying db... accountName2
01:37:34.555 [main] INFO c.r.s.c.example3.AccountService3Test - Account{id=0, name='accountName2'}
01:37:34.555 [main] INFO c.r.s.cache.example3.AccountService3 - real update db...accountName2
01:37:34.595 [main] INFO c.r.s.c.example3.AccountService3Test - Account{id=0, name='accountName1'}
01:37:34.596 [main] INFO c.r.s.cache.example3.AccountService3 - real querying account... accountName2
01:37:34.596 [main] INFO c.r.s.cache.example3.AccountService3 - real querying db... accountName2
01:37:34.596 [main] INFO c.r.s.c.example3.AccountService3Test - Account{id=0, name='accountName2'}我們會發現實際運行情況和我們預估的結果是一致的。
怎樣依照條件操作緩存
前面介紹的緩存方法，沒有不論什么條件，即全部對 accountService 對象的 getAccountByName 方法的調用都會起動緩存效果，無論參數是什么值。
假設有一個需求，就是僅僅有賬號名稱的長度小於等於 4 的情況下，才做緩存，大於 4 的不使用緩存
盡管這個需求比較坑爹，可是拋開需求的合理性，我們怎么實現這個功能呢？
通過查看CacheEvict注解的定義，我們會發現：
/**
* Annotation indicating that a method (or all methods on a class) trigger(s)
* a cache invalidate operation.
*
* @author Costin Leau
* @author Stephane Nicoll
* @since 3.1
* @see CacheConfig
*/
@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public @interface CacheEvict {
/**
* Qualifier value for the specified cached operation.
* <p>May be used to determine the target cache (or caches), matching the qualifier
* value (or the bean name(s)) of (a) specific bean definition.
*/
String[] value() default {};
/**
* Spring Expression Language (SpEL) attribute for computing the key dynamically.
* <p>Default is "", meaning all method parameters are considered as a key, unless
* a custom {@link #keyGenerator()} has been set.
*/
String key() default "";
/**
* The bean name of the custom {@link org.springframework.cache.interceptor.KeyGenerator} to use.
* <p>Mutually exclusive with the {@link #key()} attribute.
*/
String keyGenerator() default "";
/**
* The bean name of the custom {@link org.springframework.cache.CacheManager} to use to
* create a default {@link org.springframework.cache.interceptor.CacheResolver} if none
* is set already.
* <p>Mutually exclusive with the {@link #cacheResolver()} attribute.
* @see org.springframework.cache.interceptor.SimpleCacheResolver
*/
String cacheManager() default "";
/**
* The bean name of the custom {@link org.springframework.cache.interceptor.CacheResolver} to use.
*/
String cacheResolver() default "";
/**
* Spring Expression Language (SpEL) attribute used for conditioning the method caching.
* <p>Default is "", meaning the method is always cached.
*/
String condition() default "";
/**
* Whether or not all the entries inside the cache(s) are removed or not. By
* default, only the value under the associated key is removed.
* <p>Note that setting this parameter to {@code true} and specifying a {@link #key()}
* is not allowed.
*/
boolean allEntries() default false;
/**
* Whether the eviction should occur after the method is successfully invoked (default)
* or before. The latter causes the eviction to occur irrespective of the method outcome (whether
* it threw an exception or not) while the former does not.
*/
boolean beforeInvocation() default false;
}定義中有一個condition描寫敘述：
Spring Expression Language (SpEL) attribute used for conditioning the method caching.Default is "", meaning the method is always cached.
我們能夠利用這種方法來完畢這個功能，以下僅僅給出演示樣例代碼：
@Cacheable(value="accountCache",condition="#accountName.length() <= 4")// 緩存名叫 accountCache
public Account getAccountByName(String accountName) {
// 方法內部實現不考慮緩存邏輯，直接實現業務
return getFromDB(accountName);
}注意當中的 condition=”#accountName.length() <=4”，這里使用了 SpEL 表達式訪問了參數 accountName 對象的 length() 方法，條件表達式返回一個布爾值，true/false，當條件為 true。則進行緩存操作，否則直接調用方法運行的返回結果。
假設有多個參數，怎樣進行 key 的組合
我們看看CacheEvict注解的key()方法的描寫敘述：
Spring Expression Language (SpEL) attribute for computing the key dynamically. Default is "", meaning all method parameters are considered as a key, unless a custom {@link #keyGenerator()} has been set.
假設我們希望依據對象相關屬性的組合來進行緩存，比方有這么一個場景：
要求依據賬號名、password和是否發送日志查詢賬號信息
非常明顯。這里我們須要依據賬號名、password對賬號對象進行緩存，而第三個參數“是否發送日志”對緩存沒有不論什么影響。所以，我們能夠利用 SpEL 表達式對緩存 key 進行設計
我們為Account類添加一個password 屬性， 然后改動AccountService代碼：
@Cacheable(value="accountCache",key="#accountName.concat(#password)")
public Account getAccount(String accountName,String password,boolean sendLog) {
// 方法內部實現不考慮緩存邏輯。直接實現業務
return getFromDB(accountName,password);
}
注意上面的 key 屬性，當中引用了方法的兩個參數 accountName 和 password，而 sendLog 屬性沒有考慮。由於其對緩存沒有影響。
accountService.getAccount("accountName", "123456", true);// 查詢數據庫
accountService.getAccount("accountName", "123456", true);// 走緩存
accountService.getAccount("accountName", "123456", false);// 走緩存
accountService.getAccount("accountName", "654321", true);// 查詢數據庫
accountService.getAccount("accountName", "654321", true);// 走緩存怎樣做到：既要保證方法被調用。又希望結果被緩存
依據前面的樣例，我們知道，假設使用了 @Cacheable 凝視，則當反復使用同樣參數調用方法的時候，方法本身不會被調用運行。即方法本身被略過了，取而代之的是方法的結果直接從緩存中找到並返回了。
現實中並不總是如此，有些情況下我們希望方法一定會被調用，由於其除了返回一個結果，還做了其它事情。比如記錄日志。調用接口等。這個時候。我們能夠用 @CachePut 凝視，這個凝視能夠確保方法被運行，同一時候方法的返回值也被記錄到緩存中。
@Cacheable(value="accountCache")
public Account getAccountByName(String accountName) {
// 方法內部實現不考慮緩存邏輯，直接實現業務
return getFromDB(accountName);
}
// 更新 accountCache 緩存
@CachePut(value="accountCache",key="#account.getName()")
public Account updateAccount(Account account) {
return updateDB(account);
}
private Account updateDB(Account account) {
logger.info("real updating db..."+account.getName());
return account;
}我們的測試代碼例如以下
Account account = accountService.getAccountByName("someone");
account.setPassword("123");
accountService.updateAccount(account);
account.setPassword("321");
accountService.updateAccount(account);
account = accountService.getAccountByName("someone");
logger.info(account.getPassword()); 如上面的代碼所看到的。我們首先用 getAccountByName 方法查詢一個人 someone 的賬號。這個時候會查詢數據庫一次。可是也記錄到緩存中了。然后我們改動了password，調用了 updateAccount 方法。這個時候會運行數據庫的更新操作且記錄到緩存，我們再次改動password並調用 updateAccount 方法。然后通過 getAccountByName 方法查詢，這個時候。由於緩存中已經有數據，所以不會查詢數據庫，而是直接返回最新的數據，所以打印的password應該是“321”
@Cacheable、@CachePut、@CacheEvict 凝視介紹
- @Cacheable 主要針對方法配置。能夠依據方法的請求參數對其結果進行緩存
- @CachePut 主要針對方法配置，能夠依據方法的請求參數對其結果進行緩存，和 @Cacheable 不同的是，它每次都會觸發真實方法的調用
-@CachEvict 主要針對方法配置。能夠依據一定的條件對緩存進行清空
基本原理
一句話介紹就是Spring AOP的動態代理技術。 假設讀者對Spring AOP不熟悉的話，能夠去看看官方文檔
擴展性
直到如今，我們已經學會了怎樣使用開箱即用的 spring cache，這基本能夠滿足一般應用對緩存的需求。
但現實總是非常復雜。當你的用戶量上去或者性能跟不上。總須要進行擴展，這個時候你也許對其提供的內存緩存不愜意了。由於其不支持高可用性。也不具備持久化數據能力。這個時候，你就須要自己定義你的緩存方案了。
還好，spring 也想到了這一點。我們先不考慮怎樣持久化緩存，畢竟這樣的第三方的實現方案非常多。
我們要考慮的是，怎么利用 spring 提供的擴展點實現我們自己的緩存，且在不改原來已有代碼的情況下進行擴展。
���先，我們須要提供一個 CacheManager 接口的實現，這個接口告訴 spring 有哪些 cache 實例，spring 會依據 cache 的名字查找 cache 的實例。
另外還須要自己實現 Cache 接口。Cache 接口負責實際的緩存邏輯。比如添加鍵值對、存儲、查詢和清空等。
利用 Cache 接口，我們能夠對接不論什么第三方的緩存系統。比如 EHCache、OSCache，甚至一些內存數據庫比如 memcache 或者 redis 等。以下我舉一個簡單的樣例說明怎樣做。
import java.util.Collection;
import org.springframework.cache.support.AbstractCacheManager;
public class MyCacheManager extends AbstractCacheManager {
private Collection<? extends MyCache> caches;
/**
* Specify the collection of Cache instances to use for this CacheManager.
*/
public void setCaches(Collection<? extends MyCache> caches) {
this.caches = caches;
}
@Override
protected Collection<? extends MyCache> loadCaches() {
return this.caches;
}
}上面的自己定義的 CacheManager 實際繼承了 spring 內置的 AbstractCacheManager，實際上僅僅管理 MyCache 類的實例。
以下是MyCache的定義：
import java.util.HashMap;
import java.util.Map;
import org.springframework.cache.Cache;
import org.springframework.cache.support.SimpleValueWrapper;
public class MyCache implements Cache {
private String name;
private Map<String,Account> store = new HashMap<String,Account>();;
public MyCache() {
}
public MyCache(String name) {
this.name = name;
}
@Override
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
@Override
public Object getNativeCache() {
return store;
}
@Override
public ValueWrapper get(Object key) {
ValueWrapper result = null;
Account thevalue = store.get(key);
if(thevalue!=null) {
thevalue.setPassword("from mycache:"+name);
result = new SimpleValueWrapper(thevalue);
}
return result;
}
@Override
public void put(Object key, Object value) {
Account thevalue = (Account)value;
store.put((String)key, thevalue);
}
@Override
public void evict(Object key) {
}
@Override
public void clear() {
}
}
上面的自己定義緩存僅僅實現了非常easy的邏輯，但這是我們自己做的，也非常令人激動是不是，主要看 get 和 put 方法，當中的 get 方法留了一個后門，即全部的從緩存查詢返回的對象都將其 password 字段設置為一個特殊的值。這樣我們等下就能演示“我們的緩存確實在起作用！”了。
這還不夠，spring 還不知道我們寫了這些東西，須要通過 spring*.xml 配置文件告訴它
<cache:annotation-driven />
<bean id="cacheManager" class="com.rollenholt.spring.cache.MyCacheManager">
<property name="caches">
<set>
<bean
class="com.rollenholt.spring.cache.MyCache"
p:name="accountCache" />
</set>
</property>
</bean>
接下來我們來編寫測試代碼：
Account account = accountService.getAccountByName("someone");
logger.info("passwd={}", account.getPassword());
account = accountService.getAccountByName("someone");
logger.info("passwd={}", account.getPassword()); 以上測試代碼主要是先調用 getAccountByName 進行一次查詢。這會調用數據庫查詢，然后緩存到 mycache 中，然后我打印password，應該是空的；以下我再次查詢 someone 的賬號，這個時候會從 mycache 中返回緩存的實例。記得上面的后門么？我們改動了password。所以這個時候打印的password應該是一個特殊的值
注意和限制
基於 proxy 的 spring aop 帶來的內部調用問題
上面介紹過 spring cache 的原理。即它是基於動態生成的 proxy 代理機制來對方法的調用進行切面。這里關鍵點是對象的引用問題.
假設對象的方法是內部調用（即 this 引用）而不是外部引用，則會導致 proxy 失效，那么我們的切面就失效，也就是說上面定義的各種凝視包含 @Cacheable、@CachePut 和 @CacheEvict 都會失效，我們來演示一下。
public Account getAccountByName2(String accountName) {
return this.getAccountByName(accountName);
}
@Cacheable(value="accountCache")// 使用了一個緩存名叫 accountCache
public Account getAccountByName(String accountName) {
// 方法內部實現不考慮緩存邏輯，直接實現業務
return getFromDB(accountName);
}
上面我們定義了一個新的方法 getAccountByName2。其自身調用了 getAccountByName 方法，這個時候，發生的是內部調用（this），所以沒有走 proxy。導致 spring cache 失效
要避免這個問題，就是要避免對緩存方法的內部調用，或者避免使用基於 proxy 的 AOP 模式，能夠使用基於 aspectJ 的 AOP 模式來解決問題。
@CacheEvict 的可靠性問題
我們看到。@CacheEvict 凝視有一個屬性 beforeInvocation。缺省為 false，即缺省情況下。都是在實際的方法運行完畢后。才對緩存進行清空操作。期間假設運行方法出現異常，則會導致緩存清空不被運行。我們演示一下
// 清空 accountCache 緩存
@CacheEvict(value="accountCache",allEntries=true)
public void reload() {
throw new RuntimeException();
}
我們的測試代碼例如以下：
accountService.getAccountByName("someone");
accountService.getAccountByName("someone");
try {
accountService.reload();
} catch (Exception e) {
//...
}
accountService.getAccountByName("someone");
注意上面的代碼，我們在 reload 的時候拋出了運行期異常，這會導致清空緩存失敗。
以上測試代碼先查詢了兩次，然后 reload。然后再查詢一次，結果應該是僅僅有第一次查詢走了數據庫，其它兩次查詢都從緩存，第三次也走緩存由於 reload 失敗了。
那么我們怎樣避免這個問題呢？我們能夠用 @CacheEvict 凝視提供的 beforeInvocation 屬性。將其設置為 true，這樣，在方法運行前我們的緩存就被清空了。
能夠確保緩存被清空。
非 public 方法問題
和內部調用問題相似，非 public 方法假設想實現基於凝視的緩存，必須採用基於 AspectJ 的 AOP 機制
Dummy CacheManager 的配置和作用
有的時候，我們在代碼遷移、調試或者部署的時候。恰好沒有 cache 容器，比方 memcache 還不具備條件，h2db 還沒有裝好等，假設這個時候你想調試代碼，豈不是要瘋掉？這里有一個辦法。在不具備緩存條件的時候，在不改代碼的情況下。禁用緩存。
方法就是改動 spring*.xml 配置文件，設置一個找不到緩存就不做不論什么操作的標志位，例如以下
<cache:annotation-driven />
<bean id="simpleCacheManager" class="org.springframework.cache.support.SimpleCacheManager">
<property name="caches">
<set>
<bean
class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean"
p:name="default" />
</set>
</property>
</bean>
<bean id="cacheManager" class="org.springframework.cache.support.CompositeCacheManager">
<property name="cacheManagers">
<list>
<ref bean="simpleCacheManager" />
</list>
</property>
<property name="fallbackToNoOpCache" value="true" />
</bean> 注意曾經的 cacheManager 變為了 simpleCacheManager。且沒有配置 accountCache 實例，后面的 cacheManager 的實例是一個 CompositeCacheManager，他利用了前面的 simpleCacheManager 進行查詢。假設查詢不到。則依據標志位 fallbackToNoOpCache 來推斷是否不做不論什么緩存操作。
使用 guava cache
<bean id="cacheManager" class="org.springframework.cache.guava.GuavaCacheManager">
<property name="cacheSpecification" value="concurrencyLevel=4,expireAfterAccess=100s,expireAfterWrite=100s" />
<property name="cacheNames">
<list>
<value>dictTableCache</value>
</list>
</property>
</bean>