注释驱动的Springcache缓存介绍
介绍spring3.1激动人心的新特性：注释驱动的缓存，本文通过一个简单的例子进行展开，通过对比我们原来的自定义缓存和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的使用限制和注意事项。OK，Let’sbegin!
回页首
原来我们是怎么做的
这里先展示一个完全自定义的缓存实现，即不用任何第三方的组件来实现某种对象的内存缓存。
场景是：对一个账号查询方法做缓存，以账号名称为key，账号对象为value，当以相同的账号名称查询账号的时候，直接从缓存中返回结果，否则更新缓存。账号查询服务还支持reload缓存（即清空缓存）。
首先定义一个实体类：账号类，具备基本的id和name属性，且具备getter和setter方法
清单1.Account.java
packagecacheOfAnno;
publicclassAccount{
privateintid;
privateStringname;
publicAccount(Stringname){
this.name=name;
}
publicintgetId(){
returnid;
}
publicvoidsetId(intid){
this.id=id;
}
publicStringgetName(){
returnname;
}
publicvoidsetName(Stringname){
this.name=name;
}
}
然后定义一个缓存管理器，这个管理器负责实现缓存逻辑，支持对象的增加、修改和删除，支持值对象的泛型。如下：
清单2.MyCacheManager.java
packageoldcache;
importjava.util.Map;
importjava.util.concurrent.ConcurrentHashMap;
publicclassMyCacheManager{
privateMapcache=
newConcurrentHashMap();
publicTgetValue(Objectkey){
returncache.get(key);
}
publicvoidaddOrUpdateCache(Stringkey,Tvalue){
cache.put(key,value);
}
publicvoidevictCache(Stringkey){//根据key来删除缓存中的一条记录
if(cache.containsKey(key)){
cache.remove(key);
}
}
publicvoidevictCache(){//清空缓存中的所有记录
cache.clear();
}
}
好，现在我们有了实体类和一个缓存管理器，还需要一个提供账号查询的服务类，此服务类使用缓存管理器来支持账号查询缓存，如下：
清单3.MyAccountService.java
packageoldcache;
importcacheOfAnno.Account;
publicclassMyAccountService{
privateMyCacheManagercacheManager;
publicMyAccountService(){
cacheManager=newMyCacheManager();//构造一个缓存管理器
}
publicAccountgetAccountByName(StringacctName){
Accountresult=cacheManager.getValue(acctName);//首先查询缓存
if(result!=null){
System.out.println("getfromcache..."+acctName);
returnresult;//如果在缓存中，则直接返回缓存的结果
}
result=getFromDB(acctName);//否则到数据库中查询
if(result!=null){//将数据库查询的结果更新到缓存中
cacheManager.addOrUpdateCache(acctName,result);
}
returnresult;
}
publicvoidreload(){
cacheManager.evictCache();
}
privateAccountgetFromDB(StringacctName){
System.out.println("realqueryingdb..."+acctName);
returnnewAccount(acctName);
}
}
现在我们开始写一个测试类，用于测试刚才的缓存是否有效
清单4.Main.java
packageoldcache;
publicclassMain{
publicstaticvoidmain(String[]args){
MyAccountServices=newMyAccountService();
//开始查询账号
s.getAccountByName("somebody");//第一次查询，应该是数据库查询
s.getAccountByName("somebody");//第二次查询，应该直接从缓存返回
s.reload();//重置缓存
System.out.println("afterreload...");
s.getAccountByName("somebody");//应该是数据库查询
s.getAccountByName("somebody");//第二次查询，应该直接从缓存返回
}
}
按照分析，执行结果应该是：首先从数据库查询，然后直接返回缓存中的结果，重置缓存后，应该先从数据库查询，然后返回缓存中的结果，实际的执行结果如下：
清单5.运行结果
realqueryingdb...somebody//第一次从数据库加载
getfromcache...somebody//第二次从缓存加载
afterreload...//清空缓存
realqueryingdb...somebody//又从数据库加载
getfromcache...somebody//从缓存加载
可以看出我们的缓存起效了，但是这种自定义的缓存方案有如下劣势：
缓存代码和业务代码耦合度太高，如上面的例子，AccountService中的getAccountByName（）方法中有了太多缓存的逻辑，不便于维护和变更
不灵活，这种缓存方案不支持按照某种条件的缓存，比如只有某种类型的账号才需要缓存，这种需求会导致代码的变更
缓存的存储这块写的比较死，不能灵活的切换为使用第三方的缓存模块
如果你的代码中有上述代码的影子，那么你可以考虑按照下面的介绍来优化一下你的代码结构了，也可以说是简化，你会发现，你的代码会变得优雅的多！
回页首
HelloWorld，注释驱动的SpringCache
HelloWorld的实现目标
本HelloWorld类似于其他任何的HelloWorld程序，从最简单实用的角度展现springcache的魅力，它基于刚才自定义缓存方案的实体类Account.java，重新定义了AccountService.java和测试类Main.java（注意这个例子不用自己定义缓存管理器，因为spring已经提供了缺省实现）
需要的jar包
为了实用springcache缓存方案，在工程的classpath必须具备下列jar包。
图1.工程依赖的jar包图
图1.工程依赖的jar包图
注意这里我引入的是最新的spring3.2.0.M1版本jar包，其实只要是spring3.1以上，都支持springcache。其中spring-context-.jar包含了cache需要的类。
定义实体类、服务类和相关配置文件
实体类就是上面自定义缓存方案定义的Account.java，这里重新定义了服务类，如下：
清单6.AccountService.java
packagecacheOfAnno;
importorg.springframework.cache.annotation.CacheEvict;
importorg.springframework.cache.annotation.Cacheable;
publicclassAccountService{
@Cacheable(value="accountCache")//使用了一个缓存名叫accountCache
publicAccountgetAccountByName(StringuserName){
//方法内部实现不考虑缓存逻辑，直接实现业务
System.out.println("realqueryaccount."+userName);
returngetFromDB(userName);
}
privateAccountgetFromDB(StringacctName){
System.out.println("realqueryingdb..."+acctName);
returnnewAccount(acctName);
}
}
注意，此类的getAccountByName方法上有一个注释annotation，即@Cacheable(value=”accountCache”)，这个注释的意思是，当调用这个方法的时候，会从一个名叫accountCache的缓存中查询，如果没有，则执行实际的方法（即查询数据库），并将执行的结果存入缓存中，否则返回缓存中的对象。这里的缓存中的key就是参数userName，value就是Account对象。“accountCache”缓存是在spring.xml中定义的名称。
好，因为加入了spring，所以我们还需要一个spring的配置文件来支持基于注释的缓存
清单7.Spring-cache-anno.xml
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cache="http://www.springframework.org/schema/cache"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/cache
http://www.springframework.org/schema/cache/spring-cache.xsd">
class="org.springframework.cache.support.SimpleCacheManager">
class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean"
p:name="default"/>
class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean"
p:name="accountCache"/>
注意这个spring配置文件有一个关键的支持缓存的配置项：，这个配置项缺省使用了一个名字叫cacheManager的缓存管理器，这个缓存管理器有一个spring的缺省实现，即org.springframework.cache.support.SimpleCacheManager，这个缓存管理器实现了我们刚刚自定义的缓存管理器的逻辑，它需要配置一个属性caches，即此缓存管理器管理的缓存集合，除了缺省的名字叫default的缓存，我们还自定义了一个名字叫accountCache的缓存，使用了缺省的内存存储方案ConcurrentMapCacheFactoryBean，它是基于java.util.concurrent.ConcurrentHashMap的一个内存缓存实现方案。
OK，现在我们具备了测试条件，测试代码如下：
清单8.Main.java
packagecacheOfAnno;
importorg.springframework.context.ApplicationContext;
importorg.springframework.context.support.ClassPathXmlApplicationContext;
publicclassMain{
publicstaticvoidmain(String[]args){
ApplicationContextcontext=newClassPathXmlApplicationContext(
"spring-cache-anno.xml");//加载spring配置文件
AccountServices=(AccountService)context.getBean("accountServiceBean");
//第一次查询，应该走数据库
System.out.print("firstquery...");
s.getAccountByName("somebody");
//第二次查询，应该不查数据库，直接返回缓存的值
System.out.print("secondquery...");
s.getAccountByName("somebody");
System.out.println();
}
}
上面的测试代码主要进行了两次查询，第一次应该会查询数据库，第二次应该返回缓存，不再查数据库，我们执行一下，看看结果
清单9.执行结果
firstquery...realqueryaccount.somebody//第一次查询
realqueryingdb...somebody//对数据库进行了查询
secondquery...//第二次查询，没有打印数据库查询日志，直接返回了缓存中的结果
可以看出我们设置的基于注释的缓存起作用了，而在AccountService.java的代码中，我们没有看到任何的缓存逻辑代码，只有一行注释：@Cacheable(value="accountCache")，就实现了基本的缓存方案，是不是很强大？
如何清空缓存
好，到目前为止，我们的springcache缓存程序已经运行成功了，但是还不完美，因为还缺少一个重要的缓存管理逻辑：清空缓存，当账号数据发生变更，那么必须要清空某个缓存，另外还需要定期的清空所有缓存，以保证缓存数据的可靠性。
为了加入清空缓存的逻辑，我们只要对AccountService.java进行修改，从业务逻辑的角度上看，它有两个需要清空缓存的地方
当外部调用更新了账号，则我们需要更新此账号对应的缓存
当外部调用说明重新加载，则我们需要清空所有缓存
清单10.AccountService.java
点击查看代码清单
清单11.Main.java
点击查看代码清单
清单12.运行结果
firstquery...realqueryingdb...somebody
secondquery...
starttestingclearcache...
realqueryingdb...somebody1
realqueryingdb...somebody2
realupdatedb...somebody1
realqueryingdb...somebody1
realqueryingdb...somebody1
realqueryingdb...somebody2
结果和我们期望的一致，所以，我们可以看出，springcache清空缓存的方法很简单，就是通过@CacheEvict注释来标记要清空缓存的方法，当这个方法被调用后，即会清空缓存。注意其中一个@CacheEvict(value=”accountCache”,key=”#account.getName()”)，其中的Key是用来指定缓存的key的，这里因为我们保存的时候用的是account对象的name字段，所以这里还需要从参数account对象中获取name的值来作为key，前面的#号代表这是一个SpEL表达式，此表达式可以遍历方法的参数对象，具体语法可以参考Spring的相关文档手册。
如何按照条件操作缓存
前面介绍的缓存方法，没有任何条件，即所有对accountService对象的getAccountByName方法的调用都会起动缓存效果，不管参数是什么值，如果有一个需求，就是只有账号名称的长度小于等于4的情况下，才做缓存，大于4的不使用缓存，那怎么实现呢？
Springcache提供了一个很好的方法，那就是基于SpEL表达式的condition定义，这个condition是@Cacheable注释的一个属性，下面我来演示一下
清单13.AccountService.java（getAccountByName方法修订，支持条件）
@Cacheable(value="accountCache",condition="#userName.length()<=4")//缓存名叫accountCache
publicAccountgetAccountByName(StringuserName){
//方法内部实现不考虑缓存逻辑，直接实现业务
returngetFromDB(userName);
}
注意其中的condition=”#userName.length()<=4”，这里使用了SpEL表达式访问了参数userName对象的length()方法，条件表达式返回一个布尔值，true/false，当条件为true，则进行缓存操作，否则直接调用方法执行的返回结果。
清单14.测试方法
s.getAccountByName("somebody");//长度大于4，不会被缓存
s.getAccountByName("sbd");//长度小于4，会被缓存
s.getAccountByName("somebody");//还是查询数据库
s.getAccountByName("sbd");//会从缓存返回
清单15.运行结果
realqueryingdb...somebody
realqueryingdb...sbd
realqueryingdb...somebody
可见对长度大于4的账号名(somebody)没有缓存，每次都查询数据库。
如果有多个参数，如何进行key的组合
假设AccountService现在有一个需求，要求根据账号名、密码和是否发送日志查询账号信息，很明显，这里我们需要根据账号名、密码对账号对象进行缓存，而第三个参数“是否发送日志”对缓存没有任何影响。所以，我们可以利用SpEL表达式对缓存key进行设计
清单16.Account.java（增加password属性）
privateStringpassword;
publicStringgetPassword(){
returnpassword;
}
publicvoidsetPassword(Stringpassword){
this.password=password;
}
清单17.AccountService.java（增加getAccount方法，支持组合key）
@Cacheable(value="accountCache",key="#userName.concat(#password)")
publicAccountgetAccount(StringuserName,Stringpassword,booleansendLog){
//方法内部实现不考虑缓存逻辑，直接实现业务
returngetFromDB(userName,password);
}
注意上面的key属性，其中引用了方法的两个参数userName和password，而sendLog属性没有考虑，因为其对缓存没有影响。
清单18.Main.java
publicstaticvoidmain(String[]args){
ApplicationContextcontext=newClassPathXmlApplicationContext(
"spring-cache-anno.xml");//加载spring配置文件
AccountServices=(AccountService)context.getBean("accountServiceBean");
s.getAccount("somebody","123456",true);//应该查询数据库
s.getAccount("somebody","123456",true);//应该走缓存
s.getAccount("somebody","123456",false);//应该走缓存
s.getAccount("somebody","654321",true);//应该查询数据库
s.getAccount("somebody","654321",true);//应该走缓存
}
上述测试，是采用了相同的账号，不同的密码组合进行查询，那么一共有两种组合情况，所以针对数据库的查询应该只有两次。
清单19.运行结果
realqueryingdb...userName=somebodypassword=123456
realqueryingdb...userName=somebodypassword=654321
和我们预期的一致。
如何做到：既要保证方法被调用，又希望结果被缓存
根据前面的例子，我们知道，如果使用了@Cacheable注释，则当重复使用相同参数调用方法的时候，方法本身不会被调用执行，即方法本身被略过了，取而代之的是方法的结果直接从缓存中找到并返回了。
现实中并不总是如此，有些情况下我们希望方法一定会被调用，因为其除了返回一个结果，还做了其他事情，例如记录日志，调用接口等，这个时候，我们可以用@CachePut注释，这个注释可以确保方法被执行，同时方法的返回值也被记录到缓存中。
清单20.AccountService.java
@Cacheable(value="accountCache")//使用了一个缓存名叫accountCache
publicAccountgetAccountByName(StringuserName){
//方法内部实现不考虑缓存逻辑，直接实现业务
returngetFromDB(userName);
}
@CachePut(value="accountCache",key="#account.getName()")//更新accountCache缓存
publicAccountupdateAccount(Accountaccount){
returnupdatewww.wang027.comDB(account);
privateAccountupdateDB(Accountaccount){
System.out.println("realupdatingdb..."+account.getName());
returnaccount;
}
清单21.Main.java
publicstaticvoidmain(String[]args){
ApplicationContextcontext=newClassPathXmlApplicationContext(
"spring-cache-anno.xml");//加载spring配置文件
AccountServices=(AccountService)context.getBean("accountServiceBean");
Accountaccount=s.getAccountByName("someone");
account.setPassword("123");
s.updateAccount(account);
account.setPassword("321");
s.updateAccount(account);
account=s.getAccountByName("someone");
System.out.println(account.getPassword());
}
如上面的代码所示，我们首先用getAccountByName方法查询一个人someone的账号，这个时候会查询数据库一次，但是也记录到缓存中了。然后我们修改了密码，调用了updateAccount方法，这个时候会执行数据库的更新操作且记录到缓存，我们再次修改密码并调用updateAccount方法，然后通过getAccountByName方法查询，这个时候，由于缓存中已经有数据，所以不会查询数据库，而是直接返回最新的数据，所以打印的密码应该是“321”
清单22.运行结果
realqueryingdb...someone
realupdatingdb...someone
realupdatingdb...someone
321
和分析的一样，只查询了一次数据库，更新了两次数据库，最终的结果是最新的密码。说明@CachePut确实可以保证方法被执行，且结果一定会被缓存。
@Cacheable、@CachePut、@CacheEvict注释介绍
通过上面的例子，我们可以看到springcache主要使用两个注释标签，即@Cacheable、@CachePut和@CacheEvict，我们总结一下其作用和配置方法。
表1.@Cacheable作用和配置方法
@Cacheable的作用 主要针对方法配置，能够根据方法的请求参数对其结果进行缓存
@Cacheable主要的参数
value 缓存的名称，在spring配置文件中定义，必须指定至少一个 例如：
@Cacheable(value=”mycache”)或者
@Cacheable(value={”cache1”,”cache2”}
key 缓存的key，可以为空，如果指定要按照SpEL表达式编写，如果不指定，则缺省按照方法的所有参数进行组合 例如：
@Cacheable(value=”testcache”,key=”#userName”)
condition 缓存的条件，可以为空，使用SpEL编写，返回true或者false，只有为true才进行缓存 例如：
@Cacheable(value=”testcache”,condition=”#userName.length()>2”)
表2.@CachePut作用和配置方法
@CachePut的作用 主要针对方法配置，能够根据方法的请求参数对其结果进行缓存，和@Cacheable不同的是，它每次都会触发真实方法的调用
@CachePut主要的参数
value 缓存的名称，在spring配置文件中定义，必须指定至少一个 例如：
@Cacheable(value=”mycache”)或者
@Cacheable(value={”cache1”,”cache2”}
key 缓存的key，可以为空，如果指定要按照SpEL表达式编写，如果不指定，则缺省按照方法的所有参数进行组合 例如：
@Cacheable(value=”testcache”,key=”#userName”)
condition 缓存的条件，可以为空，使用SpEL编写，返回true或者false，只有为true才进行缓存 例如：
@Cacheable(value=”testcache”,condition=”#userName.length()>2”)
表3.@CacheEvict作用和配置方法
@CachEvict的作用 主要针对方法配置，能够根据一定的条件对缓存进行清空
@CacheEvict主要的参数
value 缓存的名称，在spring配置文件中定义，必须指定至少一个 例如：
@CachEvict(value=”mycache”)或者
@CachEvict(value={”cache1”,”cache2”}
key 缓存的key，可以为空，如果指定要按照SpEL表达式编写，如果不指定，则缺省按照方法的所有参数进行组合 例如：
@CachEvict(value=”testcache”,key=”#userName”)
condition 缓存的条件，可以为空，使用SpEL编写，返回true或者false，只有为true才清空缓存 例如：
@CachEvict(value=”testcache”,
condition=”#userName.length()>2”)
allEntries 是否清空所有缓存内容，缺省为false，如果指定为true，则方法调用后将立即清空所有缓存 例如：
@CachEvict(value=”testcache”,allEntries=true)
beforeInvocation 是否在方法执行前就清空，缺省为false，如果指定为true，则在方法还没有执行的时候就清空缓存，缺省情况下，如果方法执行抛出异常，则不会清空缓存 例如：
@CachEvict(value=”testcache”，beforeInvocation=true)
回页首
基本原理
和spring的事务管理类似，springcache的关键原理就是springAOP，通过springAOP，其实现了在方法调用前、调用后获取方法的入参和返回值，进而实现了缓存的逻辑。我们来看一下下面这个图：
图2.原始方法调用图
图2.原始方法调用图
上图显示，当客户端“Callingcode”调用一个普通类PlainObject的foo()方法的时候，是直接作用在pojo类自身对象上的，客户端拥有的是被调用者的直接的引用。
而Springcache利用了SpringAOP的动态代理技术，即当客户端尝试调用pojo的foo（）方法的时候，给他的不是pojo自身的引用，而是一个动态生成的代理类
图3.动态代理调用图
图3.动态代理调用图
如上图所示，这个时候，实际客户端拥有的是一个代理的引用，那么在调用foo()方法的时候，会首先调用proxy的foo()方法，这个时候proxy可以整体控制实际的pojo.foo()方法的入参和返回值，比如缓存结果，比如直接略过执行实际的foo()方法等，都是可以轻松做到的。
回页首
扩展性
直到现在，我们已经学会了如何使用开箱即用的springcache，这基本能够满足一般应用对缓存的需求，但现实总是很复杂，当你的用户量上去或者性能跟不上，总需要进行扩展，这个时候你或许对其提供的内存缓存不满意了，因为其不支持高可用性，也不具备持久化数据能力，这个时候，你就需要自定义你的缓存方案了，还好，spring也想到了这一点。
我们先不考虑如何持久化缓存，毕竟这种第三方的实现方案很多，我们要考虑的是，怎么利用spring提供的扩展点实现我们自己的缓存，且在不改原来已有代码的情况下进行扩展。
首先，我们需要提供一个CacheManager接口的实现，这个接口告诉spring有哪些cache实例，spring会根据cache的名字查找cache的实例。另外还需要自己实现Cache接口，Cache接口负责实际的缓存逻辑，例如增加键值对、存储、查询和清空等。利用Cache接口，我们可以对接任何第三方的缓存系统，例如EHCache、OSCache，甚至一些内存数据库例如memcache或者h2db等。下面我举一个简单的例子说明如何做。
清单23.MyCacheManager
packagecacheOfAnno;
importjava.util.Collection;
importorg.springframework.cache.support.AbstractCacheManager;
publicclassMyCacheManagerextendsAbstractCacheManager{
privateCollectioncaches;
/
SpecifythecollectionofCacheinstancestouseforthisCacheManager.
/
publicvoidsetCaches(Collectioncaches){
this.caches=caches;
}
@Override
protectedCollectionloadCaches(){
returnthis.caches;
}
}
上面的自定义的CacheManager实际继承了spring内置的AbstractCacheManager，实际上仅仅管理MyCache类的实例。
清单24.MyCache
packagecacheOfAnno;
importjava.util.HashMap;
importjava.util.Map;
importorg.springframework.cache.Cache;
importorg.springframework.cache.support.SimpleValueWrapper;
publicclassMyCacheimplementsCache{
privateStringname;
privateMapstore=newHashMap();;
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(){
}
}
上面的自定义缓存只实现了很简单的逻辑，但这是我们自己做的，也很令人激动是不是，主要看get和put方法，其中的get方法留了一个后门，即所有的从缓存查询返回的对象都将其password字段设置为一个特殊的值，这样我们等下就能演示“我们的缓存确实在起作用！”了。
这还不够，spring还不知道我们写了这些东西，需要通过spring.xml配置文件告诉它
清单25.Spring-cache-anno.xml
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cache="http://www.springframework.org/schema/cache"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/cache
http://www.springframework.org/schema/cache/spring-cache.xsd">
class="cacheOfAnno.MyCache"
p:name="accountCache"/>
注意上面配置文件的黑体字，这些配置说明了我们的cacheManager和我们自己的cache实例。
好，什么都不说，测试！
清单26.Main.java
publicstaticvoidmain(String[]args){
ApplicationContextcontext=newClassPathXmlApplicationContext(
"spring-cache-anno.xml");//加载spring配置文件
AccountServices=(AccountService)context.getBean("accountServiceBean");
Accountaccount=s.getAccountByName("someone");
System.out.println("passwd="+account.getPassword());
account=s.getAccountByName("someone");
System.out.println("passwd="+account.getPassword());
}
上面的测试代码主要是先调用getAccountByName进行一次查询，这会调用数据库查询，然后缓存到mycache中，然后我打印密码，应该是空的；下面我再次查询someone的账号，这个时候会从mycache中返回缓存的实例，记得上面的后门么？我们修改了密码，所以这个时候打印的密码应该是一个特殊的值
清单27.运行结果
realqueryingdb...someone
passwd=null
passwd=frommycache:accountCache
结果符合预期，即第一次查询数据库，且密码为空，第二次打印了一个特殊的密码。说明我们的myCache起作用了。
回页首
注意和限制
基于proxy的springaop带来的内部调用问题
上面介绍过springcache的原理，即它是基于动态生成的proxy代理机制来对方法的调用进行切面，这里关键点是对象的引用问题，如果对象的方法是内部调用（即this引用）而不是外部引用，则会导致proxy失效，那么我们的切面就失效，也就是说上面定义的各种注释包括@Cacheable、@CachePut和@CacheEvict都会失效，我们来演示一下。
清单28.AccountService.java
publicAccountgetAccountByName2(StringuserName){
returnthis.getAccountByName(userName);
}
@Cacheable(value="accountCache")//使用了一个缓存名叫accountCache
publicAccountgetAccountByName(StringuserName){
//方法内部实现不考虑缓存逻辑，直接实现业务
returngetFromDB(userName);
}
上面我们定义了一个新的方法getAccountByName2，其自身调用了getAccountByName方法，这个时候，发生的是内部调用（this），所以没有走proxy，导致springcache失效
清单29.Main.java
publicstaticvoidmain(String[]args){
ApplicationContextcontext=newClassPathXmlApplicationContext(
"spring-cache-anno.xml");//加载spring配置文件
AccountServices=(AccountService)context.getBean("accountServiceBean");
s.getAccountByName2("someone");
s.getAccountByName2("someone");
s.getAccountByName2("someone");
}
清单30.运行结果
realqueryingdb...someone
realqueryingdb...someone
realqueryingdb...someone
可见，结果是每次都查询数据库，缓存没起作用。要避免这个问题，就是要避免对缓存方法的内部调用，或者避免使用基于proxy的AOP模式，可以使用基于aspectJ的AOP模式来解决这个问题。
@CacheEvict的可靠性问题
我们看到，@CacheEvict注释有一个属性beforeInvocation，缺省为false，即缺省情况下，都是在实际的方法执行完成后，才对缓存进行清空操作。期间如果执行方法出现异常，则会导致缓存清空不被执行。我们演示一下
清单31.AccountService.java
@CacheEvict(value="accountCache",allEntries=true)//清空accountCache缓存
publicvoidreload(){
thrownewRuntimeException();
}
注意上面的代码，我们在reload的时候抛出了运行期异常，这会导致清空缓存失败。
清单32.Main.java
publicstaticvoidmain(String[]args){
ApplicationContextcontext=newClassPathXmlApplicationContext(
"spring-cache-anno.xml");//加载spring配置文件
AccountServices=(AccountService)context.getBean("accountServiceBean");
s.getAccountByName("someone");
s.getAccountByName("someone");
try{
s.reload();
}catch(Exceptione){
}
s.getAccountByName("someone");
}
上面的测试代码先查询了两次，然后reload，然后再查询一次，结果应该是只有第一次查询走了数据库，其他两次查询都从缓存，第三次也走缓存因为reload失败了。
清单33.运行结果
realqueryingdb...someone
和预期一样。那么我们如何避免这个问题呢？我们可以用@CacheEvict注释提供的beforeInvocation属性，将其设置为true，这样，在方法执行前我们的缓存就被清空了。可以确保缓存被清空。
清单34.AccountService.java
@CacheEvict(value="accountCache",allEntries=true,beforeInvocation=true)
//清空accountCache缓存
publicvoidreload(){
thrownewRuntimeException();
}
注意上面的代码，我们在@CacheEvict注释中加了beforeInvocation属性，确保缓存被清空。
执行相同的测试代码
清单35.运行结果
realqueryingdb...someone
realqueryingdb...someone
这样，第一次和第三次都从数据库取数据了，缓存清空有效。
非public方法问题
和内部调用问题类似，非public方法如果想实现基于注释的缓存，必须采用基于AspectJ的AOP机制，这里限于篇幅不再细述。
回页首
其他技巧
DummyCacheManager的配置和作用
有的时候，我们在代码迁移、调试或者部署的时候，恰好没有cache容器，比如memcache还不具备条件，h2db还没有装好等，如果这个时候你想调试代码，岂不是要疯掉？这里有一个办法，在不具备缓存条件的时候，在不改代码的情况下，禁用缓存。
方法就是修改spring.xml配置文件，设置一个找不到缓存就不做任何操作的标志位，如下
清单36.Spring-cache-anno.xml
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cache="http://www.springframework.org/schema/cache"
xmlns:p="http://www.springframework.org/schema/p"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/cache
http://www.springframework.org/schema/cache/spring-cache.xsd">
class="org.springframework.cache.support.SimpleCacheManager">
class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean"
p:name="default"/>
class="org.springframework.cache.support.CompositeCacheManager">
注意以前的cacheManager变为了simpleCacheManager，且没有配置accountCache实例，后面的cacheManager的实例是一个CompositeCacheManager，他利用了前面的simpleCacheManager进行查询，如果查询不到，则根据标志位fallbackToNoOpCache来判断是否不做任何缓存操作。
清单37.运行结果
realqueryingdb...someone
realqueryingdb...someone
realqueryingdb...someone
可以看出，缓存失效。每次都查询数据库。因为我们没有配置它需要的accountCache实例。
如果将上面xml配置文件的fallbackToNoOpCache设置为false，再次运行，则会得到
清单38.运行结果
Exceptioninthread"main"java.lang.IllegalArgumentException:
Cannotfindcachenamed[accountCache]forCacheableOperation
[publiccacheOfAnno.Account
cacheOfAnno.AccountService.getAccountByName(java.lang.String)]
caches=[accountCache]|condition=''''|key=''''
可见，在找不到accountCache，且没有将fallbackToNoOpCache设置为true的情况下，系统会抛出异常。
回页首
小结
总之，注释驱动的springcache能够极大的减少我们编写常见缓存的代码量，通过少量的注释标签和配置文件，即可达到使代码具备缓存的能力。且具备很好的灵活性和扩展性。但是我们也应该看到，springcache由于急于springAOP技术，尤其是动态的proxy技术，导致其不能很好的支持方法的内部调用或者非public方法的缓存设置，当然这都是可以解决的问题，通过学习这个技术，我们能够认识到，AOP技术的应用还是很广泛的，如果有兴趣，我相信你也能基于AOP实现自己的缓存方案。
|
|
