缓存是实际工作中非经常常使用的一种提高性能的方法,我们会在很多场景下来使用缓存。
本文通过一个简单的样例进行展开，通过对照我们原来的自己定义缓存和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（）方法中有了太多缓存的逻辑，不便于维护和变更 不灵活，这样的缓存方案不支持依照某种条件的缓存，比方仅仅有某种类型的账号才须要缓存，这样的需求会导致代码的变更 缓存的存储这块写的比較死，不能灵活的切换为使用第三方的缓存模块假设你的代码中有上述代码的影子，那么你能够考虑依照以下的介绍来优化一下你的代码结构了，也能够说是简化。你会发现，你的代码会变得优雅的多！
我们对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。则进行缓存操作，否则直接调用方法运行的返回结果。
我们看看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主要针对方法配置，能够依据方法的请求參数对其结果进行缓存，和@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应该是一个特殊的值
上面介绍过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凝视有一个属性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方法假设想实现基于凝视的缓存，必须採用基于AspectJ的AOP机制
有的时候，我们在代码迁移、调试或者部署的时候。恰好没有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来推断是否不做不论什么缓存操作。
本文内容总结：SpringCache，概述，我们曾经怎样自己实现缓存的呢，Springcache是怎样做的呢，怎样清空缓存，怎样依照条件操作缓存，假设有多个參数，怎样进行key的组合，怎样做到：既要保证方法被调用。又希望结果被缓存，@Cacheable、@CachePut、@CacheEvict凝视介绍，基本原理，扩展性，注意和限制，基于proxy的springaop带来的内部调用问题，@CacheEvict的可靠性问题，非public方法问题，DummyCacheManager的配置和作用，使用guavacache，
原文链接：https://www.cnblogs.com/zsychanpin/p/7191021.html相关推荐
数学中有许多类型的级数，可以在C编程中轻松解决。该程序是在C程序中找到系列后继的和。Tn = n2 - (n-1 2...
要从全部四列中找到最低分，请使用MySQLLEAST( 函数。让我们首先创建一个表-create table DemoTable( Score1 int,...
