本篇文章给大家带来的内容是关于spring cache是什么？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. */@servicepublic 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... accountname00:53:17.168 [main] info c.r.s.cache.example1.accountservice - get from cache... accountname00: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... accountname00: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. */@servicepublic 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... accountname01:10:32.457 [main] info c.r.s.cache.example2.accountservice2 - real querying db... accountname01: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. */@servicepublic 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... accountname101:37:34.551 [main] info c.r.s.cache.example3.accountservice3 - real querying db... accountname101: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... accountname201:37:34.553 [main] info c.r.s.cache.example3.accountservice3 - real querying db... accountname201: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...accountname201: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... accountname201:37:34.596 [main] info c.r.s.cache.example3.accountservice3 - real querying db... accountname201: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@documentedpublic @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>
以上就是spring cache是什么？spring cache的使用介绍的详细内容。