Spring Cache介绍和使用

2024-05-26 11:03:05 191

本文内容纲要：

-SpringCache

-概述

-我们曾经怎样自己实现缓存的呢

-Springcache是怎样做的呢

-怎样清空缓存

-怎样依照条件操作缓存

-假设有多个參数，怎样进行key的组合

-怎样做到：既要保证方法被调用。又希望结果被缓存

-@Cacheable、@CachePut、@CacheEvict凝视介绍

-基本原理

-扩展性

-注意和限制

-基于proxy的springaop带来的内部调用问题

-@CacheEvict的可靠性问题

-非public方法问题

-DummyCacheManager的配置和作用

-使用guavacache

SpringCache

缓存是实际工作中非经常常使用的一种提高性能的方法,我们会在很多场景下来使用缓存。

本文通过一个简单的样例进行展开，通过对照我们原来的自己定义缓存和spring的基于凝视的cache配置方法，展现了springcache的强大之处，然后介绍了其主要的原理，扩展点和使用场景的限制。通过阅读本文。你应该能够短时间内掌握spring带来的强大缓存技术。在非常少的配置下就可以给既有代码提供缓存能力。

概述

Spring3.1引入了激动人心的基于凝视（annotation）的缓存（cache）技术，它本质上不是一个具体的缓存实现方案（比如EHCache或者OSCache），而是一个对缓存使用的抽象，通过在既有代码中加入少量它定义的各种annotation，即能够达到缓存方法的返回对象的效果。

Spring的缓存技术还具备相当的灵活性。不仅能够使用SpEL（SpringExpressionLanguage）来定义缓存的key和各种condition，还提供开箱即用的缓存暂时存储方案，也支持和主流的专业缓存比如EHCache集成。

其特点总结例如以下：

通过少量的配置annotation凝视就可以使得既有代码支持缓存
支持开箱即用Out-Of-The-Box，即不用安装和部署额外第三方组件就可以使用缓存
支持SpringExpressLanguage，能使用对象的不论什么属性或者方法来定义缓存的key和condition
支持AspectJ，并通过事实上现不论什么方法的缓存支持
支持自己定义key和自己定义缓存管理者，具有相当的灵活性和扩展性

本文将针对上述特点对Springcache进行具体的介绍，主要通过一个简单的样例和原理介绍展开，然后我们将一起看一个比較实际的缓存样例。最后会介绍springcache的使用限制和注意事项。

好吧。让我们開始吧

我们曾经怎样自己实现缓存的呢

这里先展示一个全然自己定义的缓存实现，即不用不论什么第三方的组件来实现某种对象的内存缓存。

场景例如以下：

对一个账号查询方法做缓存，以账号名称为key，账号对象为value，当以同样的账号名称查询账号的时候，直接从缓存中返回结果。否则更新缓存。账号查询服务还支持reload缓存（即清空缓存）

首先定义一个实体类：账号类，具备主要的id和name属性。且具备getter和setter方法

publicclassAccount{

privateintid;
privateStringname;

publicAccount(Stringname){
this.name=name;
}
publicintgetId(){
returnid;
}
publicvoidsetId(intid){
this.id=id;
}
publicStringgetName(){
returnname;
}
publicvoidsetName(Stringname){
this.name=name;
}

}

然后定义一个缓存管理器，这个管理器负责实现缓存逻辑，支持对象的添加、改动和删除，支持值对象的泛型。

例如以下：

importcom.google.common.collect.Maps;

importjava.util.Map;

/**
*@authorwenchao.ren
*2015/1/5.
*/
publicclassCacheContext<T>{

privateMap<String,T>cache=Maps.newConcurrentMap();

publicTget(Stringkey){
returncache.get(key);
}

publicvoidaddOrUpdateCache(Stringkey,Tvalue){
cache.put(key,value);
}

//依据key来删除缓存中的一条记录
publicvoidevictCache(Stringkey){
if(cache.containsKey(key)){
cache.remove(key);
}
}

//清空缓存中的全部记录
publicvoidevictCache(){
cache.clear();
}

}

好，如今我们有了实体类和一个缓存管理器，还须要一个提供账号查询的服务类。此服务类使用缓存管理器来支持账号查询缓存。例如以下：

importcom.google.common.base.Optional;
importorg.slf4j.Logger;
importorg.slf4j.LoggerFactory;
importorg.springframework.stereotype.Service;

importjavax.annotation.Resource;

/**
*@authorwenchao.ren
*2015/1/5.
*/
@Service
publicclassAccountService1{

privatefinalLoggerlogger=LoggerFactory.getLogger(AccountService1.class);

@Resource
privateCacheContext<Account>accountCacheContext;

publicAccountgetAccountByName(StringaccountName){
Accountresult=accountCacheContext.get(accountName);
if(result!=null){
logger.info("getfromcache...{}",accountName);
returnresult;
}

Optional<Account>accountOptional=getFromDB(accountName);
if(!accountOptional.isPresent()){
thrownewIllegalStateException(String.format("cannotfindaccountbyaccountname:[%s]",accountName));
}

Accountaccount=accountOptional.get();
accountCacheContext.addOrUpdateCache(accountName,account);
returnaccount;
}

publicvoidreload(){
accountCacheContext.evictCache();
}

privateOptional<Account>getFromDB(StringaccountName){
logger.info("realqueryingdb...{}",accountName);
//Todoquerydatafromdatabase
returnOptional.fromNullable(newAccount(accountName));
}

}

如今我们開始写一个測试类，用于測试刚才的缓存是否有效

importorg.junit.Before;
importorg.junit.Test;
importorg.slf4j.Logger;
importorg.slf4j.LoggerFactory;
importorg.springframework.context.support.ClassPathXmlApplicationContext;

importstaticorg.junit.Assert.*;

publicclassAccountService1Test{

privateAccountService1accountService1;

privatefinalLoggerlogger=LoggerFactory.getLogger(AccountService1Test.class);

@Before
publicvoidsetUp()throwsException{
ClassPathXmlApplicationContextcontext=newClassPathXmlApplicationContext("applicationContext1.xml");
accountService1=context.getBean("accountService1",AccountService1.class);
}

@Test
publicvoidtestInject(){
assertNotNull(accountService1);
}

@Test
publicvoidtestGetAccountByName()throwsException{
accountService1.getAccountByName("accountName");
accountService1.getAccountByName("accountName");

accountService1.reload();
logger.info("afterreload....");

accountService1.getAccountByName("accountName");
accountService1.getAccountByName("accountName");
}
}

依照分析，运行结果应该是：首先从数据库查询，然后直接返回缓存中的结果，重置缓存后，应该先从数据库查询。然后返回缓存中的结果.查看程序运行的日志例如以下：

00:53:17.166[main]INFOc.r.s.cache.example1.AccountService-realqueryingdb...accountName
00:53:17.168[main]INFOc.r.s.cache.example1.AccountService-getfromcache...accountName
00:53:17.168[main]INFOc.r.s.c.example1.AccountServiceTest-afterreload....
00:53:17.168[main]INFOc.r.s.cache.example1.AccountService-realqueryingdb...accountName
00:53:17.169[main]INFOc.r.s.cache.example1.AccountService-getfromcache...accountName

能够看出我们的缓存起效了，可是这样的自己定义的缓存方案有例如以下劣势：

缓存代码和业务代码耦合度太高。如上面的样例，AccountService中的getAccountByName（）方法中有了太多缓存的逻辑，不便于维护和变更
不灵活，这样的缓存方案不支持依照某种条件的缓存，比方仅仅有某种类型的账号才须要缓存，这样的需求会导致代码的变更
缓存的存储这块写的比較死，不能灵活的切换为使用第三方的缓存模块

假设你的代码中有上述代码的影子，那么你能够考虑依照以下的介绍来优化一下你的代码结构了，也能够说是简化。你会发现，你的代码会变得优雅的多！

Springcache是怎样做的呢

我们对AccountService1进行改动。创建AccountService2:

importcom.google.common.base.Optional;
importcom.rollenholt.spring.cache.example1.Account;
importorg.slf4j.Logger;
importorg.slf4j.LoggerFactory;
importorg.springframework.cache.annotation.Cacheable;
importorg.springframework.stereotype.Service;

/**
*@authorwenchao.ren
*2015/1/5.
*/
@Service
publicclassAccountService2{

privatefinalLoggerlogger=LoggerFactory.getLogger(AccountService2.class);

//使用了一个缓存名叫accountCache
@Cacheable(value="accountCache")
publicAccountgetAccountByName(StringaccountName){

//方法内部实现不考虑缓存逻辑，直接实现业务
logger.info("realqueryingaccount...{}",accountName);
Optional<Account>accountOptional=getFromDB(accountName);
if(!accountOptional.isPresent()){
thrownewIllegalStateException(String.format("cannotfindaccountbyaccountname:[%s]",accountName));
}

returnaccountOptional.get();
}

privateOptional<Account>getFromDB(StringaccountName){
logger.info("realqueryingdb...{}",accountName);
//Todoquerydatafromdatabase
returnOptional.fromNullable(newAccount(accountName));
}

}

我们注意到在上面的代码中有一行：

@Cacheable(value="accountCache")

这个凝视的意思是，当调用这种方法的时候。会从一个名叫accountCache的缓存中查询，假设没有，则运行实际的方法（即查询数据库），并将运行的结果存入缓存中。否则返回缓存中的对象。这里的缓存中的key就是參数accountName，value就是Account对象。“accountCache”缓存是在spring*.xml中定义的名称。我们还须要一个spring的配置文件来支持基于凝视的缓存

<beansxmlns="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-scanbase-package="com.rollenholt.spring.cache"/>

<context:annotation-config/>

<cache:annotation-driven/>

<beanid="cacheManager"class="org.springframework.cache.support.SimpleCacheManager">
<propertyname="caches">
<set>
<beanclass="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean">
<propertyname="name"value="default"/>
</bean>
<beanclass="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean">
<propertyname="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的一个内存缓存实现方案。

然后我们编写測试程序：

importorg.junit.Before;
importorg.junit.Test;
importorg.slf4j.Logger;
importorg.slf4j.LoggerFactory;
importorg.springframework.context.support.ClassPathXmlApplicationContext;

importstaticorg.junit.Assert.*;

publicclassAccountService2Test{

privateAccountService2accountService2;

privatefinalLoggerlogger=LoggerFactory.getLogger(AccountService2Test.class);

@Before
publicvoidsetUp()throwsException{
ClassPathXmlApplicationContextcontext=newClassPathXmlApplicationContext("applicationContext2.xml");
accountService2=context.getBean("accountService2",AccountService2.class);
}

@Test
publicvoidtestInject(){
assertNotNull(accountService2);
}

@Test
publicvoidtestGetAccountByName()throwsException{
logger.info("firstquery...");
accountService2.getAccountByName("accountName");

logger.info("secondquery...");
accountService2.getAccountByName("accountName");
}
}

以上測试代码主要进行了两次查询。第一次应该会查询数据库，第二次应该返回缓存。不再查数据库，我们运行一下。看看结果

01:10:32.435[main]INFOc.r.s.c.example2.AccountService2Test-firstquery...
01:10:32.456[main]INFOc.r.s.cache.example2.AccountService2-realqueryingaccount...accountName
01:10:32.457[main]INFOc.r.s.cache.example2.AccountService2-realqueryingdb...accountName
01:10:32.458[main]INFOc.r.s.c.example2.AccountService2Test-secondquery...

能够看出我们设置的基于凝视的缓存起作用了，而在AccountService.java的代码中。我们没有看到不论什么的缓存逻辑代码。仅仅有一行凝视：@Cacheable(value="accountCache")，就实现了主要的缓存方案，是不是非常强大？

怎样清空缓存

好，到眼下为止，我们的springcache缓存程序已经运行成功了。可是还不完美，由于还缺少一个重要的缓存管理逻辑：清空缓存.

当账号数据发生变更，那么必须要清空某个缓存，另外还须要定期的清空全部缓存，以保证缓存数据的可靠性。

为了加入清空缓存的逻辑。我们仅仅要对AccountService2.java进行改动，从业务逻辑的角度上看，它有两个须要清空缓存的地方

当外部调用更新了账号，则我们须要更新此账号相应的缓存
当外部调用说明又一次载入，则我们须要清空全部缓存

我们在AccountService2的基础上进行改动，改动为AccountService3，代码例如以下：

importcom.google.common.base.Optional;
importcom.rollenholt.spring.cache.example1.Account;
importorg.slf4j.Logger;
importorg.slf4j.LoggerFactory;
importorg.springframework.cache.annotation.CacheEvict;
importorg.springframework.cache.annotation.Cacheable;
importorg.springframework.stereotype.Service;

/**
*@authorwenchao.ren
*2015/1/5.
*/
@Service
publicclassAccountService3{

privatefinalLoggerlogger=LoggerFactory.getLogger(AccountService3.class);

//使用了一个缓存名叫accountCache
@Cacheable(value="accountCache")
publicAccountgetAccountByName(StringaccountName){

//方法内部实现不考虑缓存逻辑，直接实现业务
logger.info("realqueryingaccount...{}",accountName);
Optional<Account>accountOptional=getFromDB(accountName);
if(!accountOptional.isPresent()){
thrownewIllegalStateException(String.format("cannotfindaccountbyaccountname:[%s]",accountName));
}

returnaccountOptional.get();
}

@CacheEvict(value="accountCache",key="#account.getName()")
publicvoidupdateAccount(Accountaccount){
updateDB(account);
}

@CacheEvict(value="accountCache",allEntries=true)
publicvoidreload(){
}

privatevoidupdateDB(Accountaccount){
logger.info("realupdatedb...{}",account.getName());
}

privateOptional<Account>getFromDB(StringaccountName){
logger.info("realqueryingdb...{}",accountName);
//Todoquerydatafromdatabase
returnOptional.fromNullable(newAccount(accountName));
}
}

我们的測试代码例如以下：

importcom.rollenholt.spring.cache.example1.Account;
importorg.junit.Before;
importorg.junit.Test;
importorg.slf4j.Logger;
importorg.slf4j.LoggerFactory;
importorg.springframework.context.support.ClassPathXmlApplicationContext;

publicclassAccountService3Test{


privateAccountService3accountService3;

privatefinalLoggerlogger=LoggerFactory.getLogger(AccountService3Test.class);

@Before
publicvoidsetUp()throwsException{
ClassPathXmlApplicationContextcontext=newClassPathXmlApplicationContext("applicationContext2.xml");
accountService3=context.getBean("accountService3",AccountService3.class);
}

@Test
publicvoidtestGetAccountByName()throwsException{

logger.info("firstquery.....");
accountService3.getAccountByName("accountName");

logger.info("secondquery....");
accountService3.getAccountByName("accountName");

}

@Test
publicvoidtestUpdateAccount()throwsException{
Accountaccount1=accountService3.getAccountByName("accountName1");
logger.info(account1.toString());
Accountaccount2=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
publicvoidtestReload()throwsException{
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]INFOc.r.s.cache.example3.AccountService3-realqueryingaccount...accountName1
01:37:34.551[main]INFOc.r.s.cache.example3.AccountService3-realqueryingdb...accountName1
01:37:34.552[main]INFOc.r.s.c.example3.AccountService3Test-Account{id=0,name='accountName1'}
01:37:34.553[main]INFOc.r.s.cache.example3.AccountService3-realqueryingaccount...accountName2
01:37:34.553[main]INFOc.r.s.cache.example3.AccountService3-realqueryingdb...accountName2
01:37:34.555[main]INFOc.r.s.c.example3.AccountService3Test-Account{id=0,name='accountName2'}
01:37:34.555[main]INFOc.r.s.cache.example3.AccountService3-realupdatedb...accountName2
01:37:34.595[main]INFOc.r.s.c.example3.AccountService3Test-Account{id=0,name='accountName1'}
01:37:34.596[main]INFOc.r.s.cache.example3.AccountService3-realqueryingaccount...accountName2
01:37:34.596[main]INFOc.r.s.cache.example3.AccountService3-realqueryingdb...accountName2
01:37:34.596[main]INFOc.r.s.c.example3.AccountService3Test-Account{id=0,name='accountName2'}

我们会发现实际运行情况和我们预估的结果是一致的。

怎样依照条件操作缓存

前面介绍的缓存方法，没有不论什么条件，即全部对accountService对象的getAccountByName方法的调用都会起动缓存效果，无论參数是什么值。

假设有一个需求，就是仅仅有账号名称的长度小于等于4的情况下，才做缓存，大于4的不使用缓存

尽管这个需求比較坑爹，可是抛开需求的合理性，我们怎么实现这个功能呢？

通过查看CacheEvict注解的定义，我们会发现：

/**
*Annotationindicatingthatamethod(orallmethodsonaclass)trigger(s)
*acacheinvalidateoperation.
*
*@authorCostinLeau
*@authorStephaneNicoll
*@since3.1
*@seeCacheConfig
*/
@Target({ElementType.METHOD,ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
public@interfaceCacheEvict{

/**
*Qualifiervalueforthespecifiedcachedoperation.
*<p>Maybeusedtodeterminethetargetcache(orcaches),matchingthequalifier
*value(orthebeanname(s))of(a)specificbeandefinition.
*/
String[]value()default{};

/**
*SpringExpressionLanguage(SpEL)attributeforcomputingthekeydynamically.
*<p>Defaultis"",meaningallmethodparametersareconsideredasakey,unless
*acustom{@link#keyGenerator()}hasbeenset.
*/
Stringkey()default"";

/**
*Thebeannameofthecustom{@linkorg.springframework.cache.interceptor.KeyGenerator}touse.
*<p>Mutuallyexclusivewiththe{@link#key()}attribute.
*/
StringkeyGenerator()default"";

/**
*Thebeannameofthecustom{@linkorg.springframework.cache.CacheManager}touseto
*createadefault{@linkorg.springframework.cache.interceptor.CacheResolver}ifnone
*issetalready.
*<p>Mutuallyexclusivewiththe{@link#cacheResolver()}attribute.
*@seeorg.springframework.cache.interceptor.SimpleCacheResolver
*/
StringcacheManager()default"";

/**
*Thebeannameofthecustom{@linkorg.springframework.cache.interceptor.CacheResolver}touse.
*/
StringcacheResolver()default"";

/**
*SpringExpressionLanguage(SpEL)attributeusedforconditioningthemethodcaching.
*<p>Defaultis"",meaningthemethodisalwayscached.
*/
Stringcondition()default"";

/**
*Whetherornotalltheentriesinsidethecache(s)areremovedornot.By
*default,onlythevalueundertheassociatedkeyisremoved.
*<p>Notethatsettingthisparameterto{@codetrue}andspecifyinga{@link#key()}
*isnotallowed.
*/
booleanallEntries()defaultfalse;

/**
*Whethertheevictionshouldoccurafterthemethodissuccessfullyinvoked(default)
*orbefore.Thelattercausestheevictiontooccurirrespectiveofthemethodoutcome(whether
*itthrewanexceptionornot)whiletheformerdoesnot.
*/
booleanbeforeInvocation()defaultfalse;
}

定义中有一个condition描写叙述：

SpringExpressionLanguage(SpEL)attributeusedforconditioningthemethodcaching.Defaultis"",meaningthemethodisalwayscached.

我们能够利用这种方法来完毕这个功能，以下仅仅给出演示样例代码：

@Cacheable(value="accountCache",condition="#accountName.length()<=4")//缓存名叫accountCache
publicAccountgetAccountByName(StringaccountName){
//方法内部实现不考虑缓存逻辑，直接实现业务
returngetFromDB(accountName);
}

注意当中的condition=”#accountName.length()<=4”，这里使用了SpEL表达式訪问了參数accountName对象的length()方法，条件表达式返回一个布尔值，true/false，当条件为true。则进行缓存操作，否则直接调用方法运行的返回结果。

假设有多个參数，怎样进行key的组合

我们看看CacheEvict注解的key()方法的描写叙述：

SpringExpressionLanguage(SpEL)attributeforcomputingthekeydynamically.Defaultis"",meaningallmethodparametersareconsideredasakey,unlessacustom{@link#keyGenerator()}hasbeenset.

假设我们希望依据对象相关属性的组合来进行缓存，比方有这么一个场景：

要求依据账号名、password和是否发送日志查询账号信息

非常明显。这里我们须要依据账号名、password对账号对象进行缓存，而第三个參数“是否发送日志”对缓存没有不论什么影响。所以，我们能够利用SpEL表达式对缓存key进行设计

我们为Account类添加一个password属性，然后改动AccountService代码：

@Cacheable(value="accountCache",key="#accountName.concat(#password)")
publicAccountgetAccount(StringaccountName,Stringpassword,booleansendLog){
//方法内部实现不考虑缓存逻辑。直接实现业务
returngetFromDB(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")
publicAccountgetAccountByName(StringaccountName){
//方法内部实现不考虑缓存逻辑，直接实现业务
returngetFromDB(accountName);
}

//更新accountCache缓存
@CachePut(value="accountCache",key="#account.getName()")
publicAccountupdateAccount(Accountaccount){
returnupdateDB(account);
}
privateAccountupdateDB(Accountaccount){
logger.info("realupdatingdb..."+account.getName());
returnaccount;
}

我们的測试代码例如以下

Accountaccount=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主要针对方法配置。能够依据一定的条件对缓存进行清空

基本原理

一句话介绍就是SpringAOP的动态代理技术。假设读者对SpringAOP不熟悉的话，能够去看看官方文档

扩展性

直到如今，我们已经学会了怎样使用开箱即用的springcache，这基本能够满足一般应用对缓存的需求。

但现实总是非常复杂。当你的用户量上去或者性能跟不上。总须要进行扩展，这个时候你也许对其提供的内存缓存不惬意了。由于其不支持高可用性。也不具备持久化数据能力。这个时候，你就须要自己定义你的缓存方案了。

还好，spring也想到了这一点。我们先不考虑怎样持久化缓存，毕竟这样的第三方的实现方案非常多。

我们要考虑的是，怎么利用spring提供的扩展点实现我们自己的缓存，且在不改原来已有代码的情况下进行扩展。

��先，我们须要提供一个CacheManager接口的实现，这个接口告诉spring有哪些cache实例，spring会依据cache的名字查找cache的实例。

另外还须要自己实现Cache接口。Cache接口负责实际的缓存逻辑。比如添加键值对、存储、查询和清空等。

利用Cache接口，我们能够对接不论什么第三方的缓存系统。比如EHCache、OSCache，甚至一些内存数据库比如memcache或者redis等。以下我举一个简单的样例说明怎样做。

importjava.util.Collection;

importorg.springframework.cache.support.AbstractCacheManager;

publicclassMyCacheManagerextendsAbstractCacheManager{
privateCollection<?extendsMyCache>caches;

/**
*SpecifythecollectionofCacheinstancestouseforthisCacheManager.
*/
publicvoidsetCaches(Collection<?extendsMyCache>caches){
this.caches=caches;
}

@Override
protectedCollection<?extendsMyCache>loadCaches(){
returnthis.caches;
}

}

上面的自己定义的CacheManager实际继承了spring内置的AbstractCacheManager，实际上仅仅管理MyCache类的实例。

以下是MyCache的定义：

importjava.util.HashMap;
importjava.util.Map;

importorg.springframework.cache.Cache;
importorg.springframework.cache.support.SimpleValueWrapper;

publicclassMyCacheimplementsCache{
privateStringname;
privateMap<String,Account>store=newHashMap<String,Account>();;

publicMyCache(){
}

publicMyCache(Stringname){
this.name=name;
}

@Override
publicStringgetName(){
returnname;
}

publicvoidsetName(Stringname){
this.name=name;
}

@Override
publicObjectgetNativeCache(){
returnstore;
}

@Override
publicValueWrapperget(Objectkey){
ValueWrapperresult=null;
Accountthevalue=store.get(key);
if(thevalue!=null){
thevalue.setPassword("frommycache:"+name);
result=newSimpleValueWrapper(thevalue);
}
returnresult;
}

@Override
publicvoidput(Objectkey,Objectvalue){
Accountthevalue=(Account)value;
store.put((String)key,thevalue);
}

@Override
publicvoidevict(Objectkey){
}

@Override
publicvoidclear(){
}
}

上面的自己定义缓存仅仅实现了非常easy的逻辑，但这是我们自己做的，也非常令人激动是不是，主要看get和put方法，当中的get方法留了一个后门，即全部的从缓存查询返回的对象都将其password字段设置为一个特殊的值。这样我们等下就能演示“我们的缓存确实在起作用！”了。

这还不够，spring还不知道我们写了这些东西，须要通过spring*.xml配置文件告诉它

<cache:annotation-driven/>

<beanid="cacheManager"class="com.rollenholt.spring.cache.MyCacheManager">
<propertyname="caches">
<set>
<bean
class="com.rollenholt.spring.cache.MyCache"
p:name="accountCache"/>
</set>
</property>
</bean>

接下来我们来编写測试代码：

Accountaccount=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的springaop带来的内部调用问题

上面介绍过springcache的原理。即它是基于动态生成的proxy代理机制来对方法的调用进行切面。这里关键点是对象的引用问题.

假设对象的方法是内部调用（即this引用）而不是外部引用，则会导致proxy失效，那么我们的切面就失效，也就是说上面定义的各种凝视包含@Cacheable、@CachePut和@CacheEvict都会失效，我们来演示一下。

publicAccountgetAccountByName2(StringaccountName){
returnthis.getAccountByName(accountName);
}

@Cacheable(value="accountCache")//使用了一个缓存名叫accountCache
publicAccountgetAccountByName(StringaccountName){
//方法内部实现不考虑缓存逻辑，直接实现业务
returngetFromDB(accountName);
}

上面我们定义了一个新的方法getAccountByName2。其自身调用了getAccountByName方法，这个时候，发生的是内部调用（this），所以没有走proxy。导致springcache失效

要避免这个问题，就是要避免对缓存方法的内部调用，或者避免使用基于proxy的AOP模式，能够使用基于aspectJ的AOP模式来解决问题。

@CacheEvict的可靠性问题

我们看到。@CacheEvict凝视有一个属性beforeInvocation。缺省为false，即缺省情况下。都是在实际的方法运行完毕后。才对缓存进行清空操作。期间假设运行方法出现异常，则会导致缓存清空不被运行。我们演示一下

//清空accountCache缓存
@CacheEvict(value="accountCache",allEntries=true)
publicvoidreload(){
thrownewRuntimeException();
}

我们的測试代码例如以下：

accountService.getAccountByName("someone");
accountService.getAccountByName("someone");
try{
accountService.reload();
}catch(Exceptione){
//...
}
accountService.getAccountByName("someone");

注意上面的代码，我们在reload的时候抛出了运行期异常，这会导致清空缓存失败。

以上測试代码先查询了两次，然后reload。然后再查询一次，结果应该是仅仅有第一次查询走了数据库，其它两次查询都从缓存，第三次也走缓存由于reload失败了。

那么我们怎样避免这个问题呢？我们能够用@CacheEvict凝视提供的beforeInvocation属性。将其设置为true，这样，在方法运行前我们的缓存就被清空了。

能够确保缓存被清空。

非public方法问题

和内部调用问题相似，非public方法假设想实现基于凝视的缓存，必须採用基于AspectJ的AOP机制

DummyCacheManager的配置和作用

有的时候，我们在代码迁移、调试或者部署的时候。恰好没有cache容器，比方memcache还不具备条件，h2db还没有装好等，假设这个时候你想调试代码，岂不是要疯掉？这里有一个办法。在不具备缓存条件的时候，在不改代码的情况下。禁用缓存。

方法就是改动spring*.xml配置文件，设置一个找不到缓存就不做不论什么操作的标志位，例如以下

<cache:annotation-driven/>

<beanid="simpleCacheManager"class="org.springframework.cache.support.SimpleCacheManager">
<propertyname="caches">
<set>
<bean
class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean"
p:name="default"/>
</set>
</property>
</bean>

<beanid="cacheManager"class="org.springframework.cache.support.CompositeCacheManager">
<propertyname="cacheManagers">
<list>
<refbean="simpleCacheManager"/>
</list>
</property>
<propertyname="fallbackToNoOpCache"value="true"/>
</bean>

注意曾经的cacheManager变为了simpleCacheManager。且没有配置accountCache实例，后面的cacheManager的实例是一个CompositeCacheManager，他利用了前面的simpleCacheManager进行查询。假设查询不到。则依据标志位fallbackToNoOpCache来推断是否不做不论什么缓存操作。

使用guavacache

<beanid="cacheManager"class="org.springframework.cache.guava.GuavaCacheManager">
<propertyname="cacheSpecification"value="concurrencyLevel=4,expireAfterAccess=100s,expireAfterWrite=100s"/>
<propertyname="cacheNames">
<list>
<value>dictTableCache</value>
</list>
</property>
</bean>

本文内容总结：SpringCache，概述，我们曾经怎样自己实现缓存的呢，Springcache是怎样做的呢，怎样清空缓存，怎样依照条件操作缓存，假设有多个參数，怎样进行key的组合，怎样做到：既要保证方法被调用。又希望结果被缓存，@Cacheable、@CachePut、@CacheEvict凝视介绍，基本原理，扩展性，注意和限制，基于proxy的springaop带来的内部调用问题，@CacheEvict的可靠性问题，非public方法问题，DummyCacheManager的配置和作用，使用guavacache，

原文链接：https://www.cnblogs.com/snake23/p/9675703.html