Spring Cache簡單介紹和使用

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>