概述Spring 3.1 引入了基于注释（Annotation）的缓存（Cache）技术。它本质上不是一个具体的缓存实现方案（例如 EHCache 或者 OSCache），而是一个对缓存使用的抽象。通过在既有代码中添加少量 Spring 定义的注释，即可达到缓存方法返回对象的效果。Spring 的缓存技术具备相当的灵活性：不仅能够使用 SpEL（Spring Expression Language）来定义缓存的 key 和各种 condition，还提供开箱即用的缓存临时存储方案，同时也支持和主流的专业缓存（例如 EHCache）集成。其特点总结如下：低侵入性：通过少量的配置 Annotation 注释即可使得既有代码支持缓存。开箱即用（Out-Of-The-Box）：不用安装和部署额外第三方组件即可使用缓存。支持 SpEL：能使用对象的任何属性或者方法来定义缓存的 key 和 condition。支持 AspectJ：并通过其实现任何方法的缓存支持。高扩展性：支持自定义 key 和自定义缓存管理者，具有相当的灵活性和扩展性。本文将针对上述特点对 Spring Cache 进行详细介绍。主要通过一个简单的例子和原理介绍展开，随后展示一个比较实际的缓存例子，最后介绍 Spring Cache 的使用限制和注意事项。原来我们是怎么做的这里先展示一个完全自定义的缓存实现，即不用任何第三方组件来实现某种对象的内存缓存。场景：对一个账号查询方法做缓存，以账号名称为 key，账号对象为 value。当以相同的账号名称查询账号的时候，直接从缓存中返回结果，否则更新缓存。账号查询服务还支持 reload 缓存（即清空缓存）。首先定义一个实体类：账号类，具备基本的 id 和 name 属性，且具备 getter 和 setter 方法。清单 1. Account.javapackage cacheOfAnno; public class Account { private int id; private String name; public Account(String name.html) { this.name = name; } public int getId() { return id; } public void setId(int id.html) { this.id = id; } public String getName() { return name; } public void setName(String name.html) { this.name = name; } }然后定义一个缓存管理器，这个管理器负责实现缓存逻辑，支持对象的增加、修改和删除，支持值对象的泛型。清单 2. MyCacheManager.javapackage oldcache; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; public class MyCacheManager<T> { private Map<String,T> cache = new ConcurrentHashMap<String,T>(); public T getValue(Object key.html) { return cache.get(key.html); } public void addOrUpdateCache(String key,T value.html) { cache.put(key, value.html); } public void evictCache(String key.html) {// 根据 key 来删除缓存中的一条记录 if(cache.containsKey(key.html)) { cache.remove(key.html); } } public void evictCache() {// 清空缓存中的所有记录 cache.clear(); } }现在我们有了实体类和一个缓存管理器，还需要一个提供账号查询的服务类。此服务类使用缓存管理器来支持账号查询缓存。清单 3. MyAccountService.javapackage oldcache; import cacheOfAnno.Account; public class MyAccountService { private MyCacheManager<Account> cacheManager; public MyAccountService() { cacheManager = new MyCacheManager<Account>();// 构造一个缓存管理器 } public Account getAccountByName(String acctName.html) { Account result = cacheManager.getValue(acctName.html);// 首先查询缓存 if(result!=null.html) { System.out.println("get from cache..."+acctName.html); return result;// 如果在缓存中，则直接返回缓存的结果 } result = getFromDB(acctName.html);// 否则到数据库中查询 if(result!=null.html) {// 将数据库查询的结果更新到缓存中 cacheManager.addOrUpdateCache(acctName, result.html); } return result; } public void reload() { cacheManager.evictCache(); } private Account getFromDB(String acctName.html) { System.out.println("real querying db..."+acctName.html); return new Account(acctName.html); } }现在我们开始写一个测试类，用于测试刚才的缓存是否有效。清单 4. Main.javapackage oldcache; public class Main { public static void main(String[] args.html) { MyAccountService s = new MyAccountService(); // 开始查询账号 s.getAccountByName("somebody".html);// 第一次查询，应该是数据库查询 s.getAccountByName("somebody".html);// 第二次查询，应该直接从缓存返回 s.reload();// 重置缓存 System.out.println("after reload...".html); s.getAccountByName("somebody".html);// 应该是数据库查询 s.getAccountByName("somebody".html);// 第二次查询，应该直接从缓存返回 } }按照分析，执行结果应该是：首先从数据库查询，然后直接返回缓存中的结果；重置缓存后，应该先从数据库查询，然后返回缓存中的结果。实际的执行结果如下：清单 5. 运行结果real querying db...somebody// 第一次从数据库加载 get from cache...somebody// 第二次从缓存加载 after reload...// 清空缓存 real querying db...somebody// 又从数据库加载 get from cache...somebody// 从缓存加载可以看出我们的缓存起效了，但是这种自定义的缓存方案有如下劣势：耦合度高：缓存代码和业务代码耦合度太高。如上面的例子，AccountService 中的 getAccountByName() 方法中有了太多缓存的逻辑，不便于维护和变更。不灵活：这种缓存方案不支持按照某种条件的缓存。比如只有某种类型的账号才需要缓存，这种需求会导致代码的变更。存储固定：缓存的存储这块写的比较死，不能灵活的切换为使用第三方的缓存模块。如果你的代码中有上述代码的影子，那么你可以考虑按照下面的介绍来优化一下你的代码结构了。你会发现，你的代码会变得优雅得多。Hello World，注释驱动的 Spring CacheHello World 的实现目标本 Hello World 类似于其他任何的 Hello World 程序，从最简单实用的角度展现 Spring Cache 的魅力。它基于刚才自定义缓存方案的实体类 Account.java，重新定义了 AccountService.java 和测试类 Main.java。注意这个例子不用自己定义缓存管理器，因为 Spring 已经提供了缺省实现。需要的 jar 包为了使用 Spring Cache 缓存方案，在工程的 classpath 必须具备下列 jar 包。图 1. 工程依赖的 jar 包图注意这里引入的是 Spring 3.2.0.M1 版本 jar 包。其实只要是 Spring 3.1 以上，都支持 Spring Cache。其中 spring-context-*.jar 包含了 cache 需要的类。定义实体类、服务类和相关配置文件实体类就是上面自定义缓存方案定义的 Account.java，这里重新定义了服务类。清单 6. AccountService.javapackage cacheOfAnno; import org.springframework.cache.annotation.CacheEvict; import org.springframework.cache.annotation.Cacheable; public class AccountService { @Cacheable(value="accountCache".html)// 使用了一个缓存名叫 accountCache public Account getAccountByName(String userName.html) { // 方法内部实现不考虑缓存逻辑，直接实现业务 System.out.println("real query account."+userName.html); return getFromDB(userName.html); } private Account getFromDB(String acctName.html) { System.out.println("real querying db..."+acctName.html); return new Account(acctName.html); } }注意，此类的 getAccountByName 方法上有一个注释 Annotation，即 @Cacheable(value="accountCache".html)。这个注释的意思是：当调用这个方法的时候，会从一个名叫 accountCache 的缓存中查询，如果没有，则执行实际的方法（即查询数据库），并将执行的结果存入缓存中，否则返回缓存中的对象。这里的缓存中的 key 就是参数 userName，value 就是 Account 对象。"accountCache"缓存是在 spring*.xml 中定义的名称。因为加入了 Spring，所以我们还需要一个 Spring 的配置文件来支持基于注释的缓存。清单 7. Spring-cache-anno.xml<beans xmlns="http://www.springframework.org/schema/beans" 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"> <cache:annotation-driven /> <bean id="accountServiceBean" class="cacheOfAnno.AccountService"/> <bean id="cacheManager" class="org.springframework.cache.support.SimpleCacheManager"> <property name="caches"> <set> <bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="default" /> <bean class="org.springframework.cache.concurrent.ConcurrentMapCacheFactoryBean" p:name="accountCache" /> </set> </property> </bean> </beans>注意这个 Spring 配置文件有一个关键的支持缓存的配置项：<cache:annotation-driven />。这个配置项缺省使用了一个名字叫 cacheManager 的缓存管理器。这个缓存管理器有一个 Spring 的缺省实现，即 org.springframework.cache.support.SimpleCacheManager。这个缓存管理器实现了我们刚刚自定义的缓存管理器的逻辑，它需要配置一个属性 caches，即此缓存管理器管理的缓存集合。除了缺省的名字叫 default 的缓存，我们还自定义了一个名字叫 accountCache 的缓存，使用了缺省的内存存储方案 ConcurrentMapCacheFactoryBean，它是基于 java.util.concurrent.ConcurrentHashMap 的一个内存缓存实现方案。OK，现在我们具备了测试条件，测试代码如下：清单 8. Main.javapackage cacheOfAnno; import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; public class Main { public static void main(String[] args.html) { ApplicationContext context = new ClassPathXmlApplicationContext( "spring-cache-anno.xml");// 加载 spring 配置文件 AccountService s = (AccountService.html) context.getBean("accountServiceBean".html); // 第一次查询，应该走数据库 System.out.print("first query...".html); s.getAccountByName("somebody".html); // 第二次查询，应该不查数据库，直接返回缓存的值 System.out.print("second query...".html); s.getAccountByName("somebody".html); System.out.println(); } }上面的测试代码主要进行了两次查询，第一次应该会查询数据库，第二次应该返回缓存，不再查数据库。我们执行一下，看看结果。清单 9. 执行结果first query...real query account.somebody// 第一次查询 real querying db...somebody// 对数据库进行了查询 second query...// 第二次查询，没有打印数据库查询日志，直接返回了缓存中的结果可以看出我们设置的基于注释的缓存起作用了。而在 AccountService.java 的代码中，我们没有看到任何的缓存逻辑代码，只有一行注释：@Cacheable(value="accountCache".html)，就实现了基本的缓存方案。如何清空缓存到目前为止，我们的 Spring Cache 缓存程序已经运行成功了，但是还不完美，因为还缺少一个重要的缓存管理逻辑：清空缓存。当账号数据发生变更，那么必须要清空某个缓存；另外还需要定期的清空所有缓存，以保证缓存数据的可靠性。为了加入清空缓存的逻辑，我们只要对 AccountService.java 进行修改。从业务逻辑的角度上看，它有两个需要清空缓存的地方：当外部调用更新了账号，则我们需要更新此账号对应的缓存。当外部调用说明重新加载，则我们需要清空所有缓存。清单 10. AccountService.javapackage cacheOfAnno; import org.springframework.cache.annotation.CacheEvict; import org.springframework.cache.annotation.Cacheable; public class AccountService { @Cacheable(value="accountCache".html)// 使用了一个缓存名叫 accountCache public Account getAccountByName(String userName.html) { // 方法内部实现不考虑缓存逻辑，直接实现业务 return getFromDB(userName.html); } @CacheEvict(value="accountCache",key="#account.getName(.html)")// 清空 accountCache 缓存 public void updateAccount(Account account.html) { updateDB(account.html); } @CacheEvict(value="accountCache",allEntries=true.html)// 清空 accountCache 缓存 public void reload() { } private Account getFromDB(String acctName.html) { System.out.println("real querying db..."+acctName.html); return new Account(acctName.html); } private void updateDB(Account account.html) { System.out.println("real update db..."+account.getName(.html)); } }清单 11. Main.javapackage cacheOfAnno; import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; public class Main { public static void main(String[] args.html) { ApplicationContext context = new ClassPathXmlApplicationContext( "spring-cache-anno.xml");// 加载 spring 配置文件 AccountService s = (AccountService.html) context.getBean("accountServiceBean".html); // 第一次查询，应该走数据库 System.out.print("first query...".html); s.getAccountByName("somebody".html); // 第二次查询，应该不查数据库，直接返回缓存的值 System.out.print("second query...".html); s.getAccountByName("somebody".html); System.out.println(); System.out.println("start testing clear cache...".html); // 更新某个记录的缓存，首先构造两个账号记录，然后记录到缓存中 Account account1 = s.getAccountByName("somebody1".html); Account account2 = s.getAccountByName("somebody2".html); // 开始更新其中一个 account1.setId(1212.html); s.updateAccount(account1.html); s.getAccountByName("somebody1".html);// 因为被更新了，所以会查询数据库 s.getAccountByName("somebody2".html);// 没有更新过，应该走缓存 s.getAccountByName("somebody1".html);// 再次查询，应该走缓存 // 更新所有缓存 s.reload(); s.getAccountByName("somebody1".html);// 应该会查询数据库 s.getAccountByName("somebody2".html);// 应该会查询数据库 s.getAccountByName("somebody1".html);// 应该走缓存 s.getAccountByName("somebody2".html);// 应该走缓存 } }清单 12. 运行结果first query...real querying db...somebody second query... start testing clear cache... real querying db...somebody1 real querying db...somebody2 real update db...somebody1 real querying db...somebody1 real querying db...somebody1 real querying db...somebody2结果和我们期望的一致。Spring Cache 清空缓存的方法很简单，就是通过 @CacheEvict 注释来标记要清空缓存的方法，当这个方法被调用后，即会清空缓存。注意其中一个 @CacheEvict(value="accountCache",key="#account.getName(.html)")，其中的 Key 是用来指定缓存的 key 的。这里因为我们保存的时候用的是 account 对象的 name 字段，所以这里还需要从参数 account 对象中获取 name 的值来作为 key。前面的 # 号代表这是一个 SpEL 表达式，此表达式可以遍历方法的参数对象，具体语法可以参考 Spring 的相关文档手册。如何按照条件操作缓存前面介绍的缓存方法，没有任何条件，即所有对 accountService 对象的 getAccountByName 方法的调用都会启动缓存效果，不管参数是什么值。如果有一个需求，就是只有账号名称的长度小于等于 4 的情况下，才做缓存，大于 4 的不使用缓存，那怎么实现呢？Spring Cache 提供了一个很好的方法，那就是基于 SpEL 表达式的 condition 定义。这个 condition 是 @Cacheable 注释的一个属性。清单 13. AccountService.java（getAccountByName 方法修订，支持条件）@Cacheable(value="accountCache",condition="#userName.length(.html) <= 4")// 缓存名叫 accountCache public Account getAccountByName(String userName.html) { // 方法内部实现不考虑缓存逻辑，直接实现业务 return getFromDB(userName.html); }注意其中的 condition="#userName.length() <= 4"，这里使用了 SpEL 表达式访问了参数 userName 对象的 length() 方法。条件表达式返回一个布尔值（true/false），当条件为 true，则进行缓存操作，否则直接调用方法执行的返回结果。清单 14. 测试方法s.getAccountByName("somebody".html);// 长度大于 4，不会被缓存 s.getAccountByName("sbd".html);// 长度小于 4，会被缓存 s.getAccountByName("somebody".html);// 还是查询数据库 s.getAccountByName("sbd".html);// 会从缓存返回清单 15. 运行结果real querying db...somebody real querying db...sbd real querying db...somebody可见对长度大于 4 的账号名 (somebody.html) 没有缓存，每次都查询数据库。如果有多个参数，如何进行 key 的组合假设 AccountService 现在有一个需求，要求根据账号名、密码和是否发送日志查询账号信息。很明显，这里我们需要根据账号名、密码对账号对象进行缓存，而第三个参数“是否发送日志”对缓存没有任何影响。所以，我们可以利用 SpEL 表达式对缓存 key 进行设计。清单 16. Account.java（增加 password 属性）private String password; public String getPassword() { return password; } public void setPassword(String password.html) { this.password = password; }清单 17. AccountService.java（增加 getAccount 方法，支持组合 key）@Cacheable(value="accountCache",key="#userName.concat(#password.html)") public Account getAccount(String userName,String password,boolean sendLog.html) { // 方法内部实现不考虑缓存逻辑，直接实现业务 return getFromDB(userName,password.html); }注意上面的 key 属性，其中引用了方法的两个参数 userName 和 password，而 sendLog 属性没有考虑，因为其对缓存没有影响。清单 18. Main.javapublic static void main(String[] args.html) { ApplicationContext context = new ClassPathXmlApplicationContext( "spring-cache-anno.xml");// 加载 spring 配置文件 AccountService s = (AccountService.html) context.getBean("accountServiceBean".html); s.getAccount("somebody", "123456", true.html);// 应该查询数据库 s.getAccount("somebody", "123456", true.html);// 应该走缓存 s.getAccount("somebody", "123456", false.html);// 应该走缓存 s.getAccount("somebody", "654321", true.html);// 应该查询数据库 s.getAccount("somebody", "654321", true.html);// 应该走缓存 }上述测试，是采用了相同的账号，不同的密码组合进行查询，那么一共有两种组合情况，所以针对数据库的查询应该只有两次。清单 19. 运行结果real querying db...userName=somebody password=123456 real querying db...userName=somebody password=654321和我们预期的一致。如何做到：既要保证方法被调用，又希望结果被缓存根据前面的例子，我们知道，如果使用了 @Cacheable 注释，则当重复使用相同参数调用方法的时候，方法本身不会被调用执行，即方法本身被略过了，取而代之的是方法的结果直接从缓存中找到并返回了。现实中并不总是如此。有些情况下我们希望方法一定会被调用，因为其除了返回一个结果，还做了其他事情，例如记录日志、调用接口等。这个时候，我们可以用 @CachePut 注释。这个注释可以确保方法被执行，同时方法的返回值也被记录到缓存中。清单 20. AccountService.java@Cacheable(value="accountCache".html)// 使用了一个缓存名叫 accountCache public Account getAccountByName(String userName.html) { // 方法内部实现不考虑缓存逻辑，直接实现业务 return getFromDB(userName.html); } @CachePut(value="accountCache",key="#account.getName(.html)")// 更新 accountCache 缓存 public Account updateAccount(Account account.html) { return updateDB(account.html); } private Account updateDB(Account account.html) { System.out.println("real updating db..."+account.getName(.html)); return account; }清单 21. Main.javapublic static void main(String[] args.html) { ApplicationContext context = new ClassPathXmlApplicationContext( "spring-cache-anno.xml");// 加载 spring 配置文件 AccountService s = (AccountService.html) context.getBean("accountServiceBean".html); Account account = s.getAccountByName("someone".html); account.setPassword("123".html); s.updateAccount(account.html); account.setPassword("321".html); s.updateAccount(account.html); account = s.getAccountByName("someone".html); System.out.println(account.getPassword(.html)); }如上面的代码所示，我们首先用 getAccountByName 方法查询一个人 someone 的账号，这个时候会查询数据库一次，但是也记录到缓存中了。然后我们修改了密码，调用了 updateAccount 方法，这个时候会执行数据库的更新操作且记录到缓存。我们再次修改密码并调用 updateAccount 方法，然后通过 getAccountByName 方法查询。这个时候，由于缓存中已经有数据，所以不会查询数据库，而是直接返回最新的数据，所以打印的密码应该是"321"。清单 22. 运行结果real querying db...someone real updating db...someone real updating db...someone 321和分析的一样，只查询了一次数据库，更新了两次数据库，最终的结果是最新的密码。说明 @CachePut 确实可以保证方法被执行，且结果一定会被缓存。@Cacheable、@CachePut、@CacheEvict 注释介绍通过上面的例子，我们可以看到 Spring Cache 主要使用三个注释标签，即 @Cacheable、@CachePut 和 @CacheEvict。我们总结一下其作用和配置方法。表 1. @Cacheable 作用和配置方法属性说明示例作用主要针对方法配置，能够根据方法的请求参数对其结果进行缓存 value缓存的名称，在 spring 配置文件中定义，必须指定至少一个@Cacheable(value="mycache".html) 或者 @Cacheable(value={"cache1","cache2"}.html)key缓存的 key，可以为空。如果指定要按照 SpEL 表达式编写，如果不指定，则缺省按照方法的所有参数进行组合@Cacheable(value="testcache",key="#userName".html)condition缓存的条件，可以为空。使用 SpEL 编写，返回 true 或者 false，只有为 true 才进行缓存@Cacheable(value="testcache",condition="#userName.length(.html)>2")表 2. @CachePut 作用和配置方法属性说明示例作用主要针对方法配置，能够根据方法的请求参数对其结果进行缓存。和 @Cacheable 不同的是，它每次都会触发真实方法的调用 value缓存的名称，在 spring 配置文件中定义，必须指定至少一个@CachePut(value="mycache".html) 或者 @CachePut(value={"cache1","cache2"}.html)key缓存的 key，可以为空。如果指定要按照 SpEL 表达式编写，如果不指定，则缺省按照方法的所有参数进行组合@CachePut(value="testcache",key="#userName".html)condition缓存的条件，可以为空。使用 SpEL 编写，返回 true 或者 false，只有为 true 才进行缓存@CachePut(value="testcache",condition="#userName.length(.html)>2")表 3. @CacheEvict 作用和配置方法属性说明示例作用主要针对方法配置，能够根据一定的条件对缓存进行清空 value缓存的名称，在 spring 配置文件中定义，必须指定至少一个@CacheEvict(value="mycache".html) 或者 @CacheEvict(value={"cache1","cache2"}.html)key缓存的 key，可以为空。如果指定要按照 SpEL 表达式编写，如果不指定，则缺省按照方法的所有参数进行组合@CacheEvict(value="testcache",key="#userName".html)condition缓存的条件，可以为空。使用 SpEL 编写，返回 true 或者 false，只有为 true 才清空缓存@CacheEvict(value="testcache", condition="#userName.length(.html)>2")allEntries是否清空所有缓存内容，缺省为 false。如果指定为 true，则方法调用后将立即清空所有缓存@CacheEvict(value="testcache",allEntries=true.html)beforeInvocation是否在方法执行前就清空，缺省为 false。如果指定为 true，则在方法还没有执行的时候就清空缓存。缺省情况下，如果方法执行抛出异常，则不会清空缓存@CacheEvict(value="testcache", beforeInvocation=true.html)基本原理和 Spring 的事务管理类似，Spring Cache 的关键原理就是 Spring AOP。通过 Spring AOP，其实现了在方法调用前、调用后获取方法的入参和返回值，进而实现了缓存的逻辑。我们来看一下下面这个图。图 2. 原始方法调用图上图显示，当客户端"Calling code"调用一个普通类 Plain Object 的 foo() 方法的时候，是直接作用在 pojo 类自身对象上的，客户端拥有的是被调用者的直接的引用。而 Spring Cache 利用了 Spring AOP 的动态代理技术，即当客户端尝试调用 pojo 的 foo() 方法的时候，给他的不是 pojo 自身的引用，而是一个动态生成的代理类。图 3. 动态代理调用图如上图所示，这个时候，实际客户端拥有的是一个代理的引用。那么在调用 foo() 方法的时候，会首先调用 proxy 的 foo() 方法。这个时候 proxy 可以整体控制实际的 pojo.foo() 方法的入参和返回值，比如缓存结果，比如直接略过执行实际的 foo() 方法等，都是可以轻松做到的。扩展性直到现在，我们已经学会了如何使用开箱即用的 Spring Cache，这基本能够满足一般应用对缓存的需求。但现实总是很复杂，当你的用户量上去或者性能跟不上，总需要进行扩展。这个时候你或许对其提供的内存缓存不满意了，因为其不支持高可用性，也不具备持久化数据能力。这个时候，你就需要自定义你的缓存方案了。还好，Spring 也想到了这一点。我们先不考虑如何持久化缓存，毕竟这种第三方的实现方案很多。我们要考虑的是，怎么利用 Spring 提供的扩展点实现我们自己的缓存，且在不改原来已有代码的情况下进行扩展。首先，我们需要提供一个 CacheManager 接口的实现。这个接口告诉 Spring 有哪些 cache 实例，Spring 会根据 cache 的名字查找 cache 的实例。另外还需要自己实现 Cache 接口，Cache 接口负责实际的缓存逻辑，例如增加键值对、存储、查询和清空等。利用 Cache 接口，我们可以对接任何第三方的缓存系统，例如 EHCache、OSCache，甚至一些内存数据库例如 memcache 或者 h2db 等。下面我举一个简单的例子说明如何做。清单 23. MyCacheManagerpackage cacheOfAnno; 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.html) { this.caches = caches; } @Override protected Collection<? extends MyCache> loadCaches() { return this.caches; } }上面的自定义的 CacheManager 实际继承了 Spring 内置的 AbstractCacheManager，实际上仅仅管理 MyCache 类的实例。清单 24. MyCachepackage cacheOfAnno; 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.html) { this.name = name; } @Override public String getName() { return name; } public void setName(String name.html) { this.name = name; } @Override public Object getNativeCache() { return store; } @Override public ValueWrapper get(Object key.html) { ValueWrapper result = null; Account thevalue = store.get(key.html); if(thevalue!=null.html) { thevalue.setPassword("from mycache:"+name.html); result = new SimpleValueWrapper(thevalue.html); } return result; } @Override public void put(Object key, Object value.html) { Account thevalue = (Account.html)value; store.put((String.html)key, thevalue); } @Override public void evict(Object key.html) { } @Override public void clear() { } }上面的自定义缓存只实现了很简单的逻辑，但这是我们自己做的。主要看 get 和 put 方法，其中的 get 方法留了一个后门，即所有的从缓存查询返回的对象都将其 password 字段设置为一个特殊的值，这样我们等下就能演示“我们的缓存确实在起作用！”了。这还不够，Spring 还不知道我们写了这些东西，需要通过 spring*.xml 配置文件告诉它。清单 25. Spring-cache-anno.xml<beans xmlns="http://www.springframework.org/schema/beans" 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"> <cache:annotation-driven /> <bean id="accountServiceBean" class="cacheOfAnno.AccountService"/> <bean id="cacheManager" class="cacheOfAnno.MyCacheManager"> <property name="caches"> <set> <bean class="cacheOfAnno.MyCache" p:name="accountCache" /> </set> </property> </bean> </beans>注意上面配置文件的配置，这些配置说明了我们的 cacheManager 和我们自己的 cache 实例。好，什么都不说，测试！清单 26. Main.javapublic static void main(String[] args.html) { ApplicationContext context = new ClassPathXmlApplicationContext( "spring-cache-anno.xml");// 加载 spring 配置文件 AccountService s = (AccountService.html) context.getBean("accountServiceBean".html); Account account = s.getAccountByName("someone".html); System.out.println("passwd="+account.getPassword(.html)); account = s.getAccountByName("someone".html); System.out.println("passwd="+account.getPassword(.html)); }上面的测试代码主要是先调用 getAccountByName 进行一次查询，这会调用数据库查询，然后缓存到 mycache 中，然后我打印密码，应该是空的；下面我再次查询 someone 的账号，这个时候会从 mycache 中返回缓存的实例。记得上面的后门么？我们修改了密码，所以这个时候打印的密码应该是一个特殊的值。清单 27. 运行结果real querying db...someone passwd=null passwd=from mycache:accountCache结果符合预期，即第一次查询数据库，且密码为空，第二次打印了一个特殊的密码。说明我们的 myCache 起作用了。注意和限制基于 proxy 的 Spring AOP 带来的内部调用问题上面介绍过 Spring Cache 的原理，即它是基于动态生成的 proxy 代理机制来对方法的调用进行切面。这里关键点是对象的引用问题，如果对象的方法是内部调用（即 this 引用）而不是外部引用，则会导致 proxy 失效。那么我们的切面就失效，也就是说上面定义的各种注释包括 @Cacheable、@CachePut 和 @CacheEvict 都会失效。我们来演示一下。清单 28. AccountService.javapublic Account getAccountByName2(String userName.html) { return this.getAccountByName(userName.html); } @Cacheable(value="accountCache".html)// 使用了一个缓存名叫 accountCache public Account getAccountByName(String userName.html) { // 方法内部实现不考虑缓存逻辑，直接实现业务 return getFromDB(userName.html); }上面我们定义了一个新的方法 getAccountByName2，其自身调用了 getAccountByName 方法。这个时候，发生的是内部调用（this），所以没有走 proxy，导致 Spring Cache 失效。清单 29. Main.javapublic static void main(String[] args.html) { ApplicationContext context = new ClassPathXmlApplicationContext( "spring-cache-anno.xml");// 加载 spring 配置文件 AccountService s = (AccountService.html) context.getBean("accountServiceBean".html); s.getAccountByName2("someone".html); s.getAccountByName2("someone".html); s.getAccountByName2("someone".html); }清单 30. 运行结果real querying db...someone real querying db...someone real querying db...someone可见，结果是每次都查询数据库，缓存没起作用。要避免这个问题，就是要避免对缓存方法的内部调用，或者避免使用基于 proxy 的 AOP 模式，可以使用基于 AspectJ 的 AOP 模式来解决这个问题。@CacheEvict 的可靠性问题我们看到，@CacheEvict 注释有一个属性 beforeInvocation，缺省为 false。即缺省情况下，都是在实际的方法执行完成后，才对缓存进行清空操作。期间如果执行方法出现异常，则会导致缓存清空不被执行。我们演示一下。清单 31. AccountService.java@CacheEvict(value="accountCache",allEntries=true.html)// 清空 accountCache 缓存 public void reload() { throw new RuntimeException(); }注意上面的代码，我们在 reload 的时候抛出了运行期异常，这会导致清空缓存失败。清单 32. Main.javapublic static void main(String[] args.html) { ApplicationContext context = new ClassPathXmlApplicationContext( "spring-cache-anno.xml");// 加载 spring 配置文件 AccountService s = (AccountService.html) context.getBean("accountServiceBean".html); s.getAccountByName("someone".html); s.getAccountByName("someone".html); try { s.reload(); } catch (Exception e.html) { } s.getAccountByName("someone".html); }上面的测试代码先查询了两次，然后 reload，然后再查询一次。结果应该是只有第一次查询走了数据库，其他两次查询都从缓存，第三次也走缓存因为 reload 失败了。清单 33. 运行结果real querying db...someone和预期一样。那么我们如何避免这个问题呢？我们可以用 @CacheEvict 注释提供的 beforeInvocation 属性，将其设置为 true。这样，在方法执行前我们的缓存就被清空了，可以确保缓存被清空。清单 34. AccountService.java@CacheEvict(value="accountCache",allEntries=true,beforeInvocation=true.html) // 清空 accountCache 缓存 public void reload() { throw new RuntimeException(); }注意上面的代码，我们在 @CacheEvict 注释中加了 beforeInvocation 属性，确保缓存被清空。执行相同的测试代码。清单 35. 运行结果real querying db...someone real querying db...someone这样，第一次和第三次都从数据库取数据了，缓存清空有效。非 public 方法问题和内部调用问题类似，非 public 方法如果想实现基于注释的缓存，必须采用基于 AspectJ 的 AOP 机制，这里限于篇幅不再细述。其他技巧Dummy CacheManager 的配置和作用有的时候，我们在代码迁移、调试或者部署的时候，恰好没有 cache 容器，比如 memcache 还不具备条件，h2db 还没有装好等。如果这个时候你想调试代码，岂不是要疯掉？这里有一个办法，在不具备缓存条件的时候，在不改代码的情况下，禁用缓存。方法就是修改 spring*.xml 配置文件，设置一个找不到缓存就不做任何操作的标志位。清单 36. Spring-cache-anno.xml<beans xmlns="http://www.springframework.org/schema/beans" 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"> <cache:annotation-driven /> <bean id="accountServiceBean" class="cacheOfAnno.AccountService"/> <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"> <ref bean="simpleCacheManager" /> </property> <property name="fallbackToNoOpCache" value="true" /> </bean> </beans>注意以前的 cacheManager 变为了 simpleCacheManager，且没有配置 accountCache 实例。后面的 cacheManager 的实例是一个 CompositeCacheManager，它利用了前面的 simpleCacheManager 进行查询，如果查询不到，则根据标志位 fallbackToNoOpCache 来判断是否不做任何缓存操作。清单 37. 运行结果real querying db...someone real querying db...someone real querying db...someone可以看出，缓存失效，每次都查询数据库，因为我们没有配置它需要的 accountCache 实例。如果将上面 xml 配置文件的 fallbackToNoOpCache 设置为 false，再次运行，则会得到：清单 38. 运行结果Exception in thread "main" java.lang.IllegalArgumentException: Cannot find cache named [accountCache] for CacheableOperation [public cacheOfAnno.Account cacheOfAnno.AccountService.getAccountByName(java.lang.String)] caches=[accountCache] | condition='' | key=''可见，在找不到 accountCache，且没有将 fallbackToNoOpCache 设置为 true 的情况下，系统会抛出异常。小结总之，注释驱动的 Spring Cache 能够极大的减少我们编写常见缓存的代码量。通过少量的注释标签和配置文件，即可达到使代码具备缓存的能力，且具备很好的灵活性和扩展性。但是我们也应该看到，Spring Cache 由于基于 Spring AOP 技术，尤其是动态的 proxy 技术，导致其不能很好的支持方法的内部调用或者非 public 方法的缓存设置。当然这都是可以解决的问题。通过学习这个技术，我们能够认识到，AOP 技术的应用还是很广泛的。如果有兴趣，我相信你也能基于 AOP 实现自己的缓存方案。相关主题随时关注 developerWorks 技术活动 和 网络广播。访问 developerWorks Open source 专区 获得丰富的 how-to 信息、工具和项目更新以及 最受欢迎的文章和教程，帮助您用开放源码技术进行开发，并将它们与 IBM 产品结合使用。说明：本文基于 Spring 3.1/3.2 版本编写，核心原理（AOP 代理、注解驱动）在后续 Spring 版本（4.x/5.x/6.x）中依然适用。但在较新版本中，推荐优先使用 Java Config 配置方式替代 XML 配置，且缓存抽象接口细节可能有所演进。
编者注：本文为历史博文归档；涉及 JDK、框架与工具链版本请以当前官方文档为准。引用外链图片可能失效，阅读时请注意时效性。缓存概述正如大多数持久层框架一样，MyBatis 同样提供了一级缓存和二级缓存的支持：一级缓存：基于 PerpetualCache 的 HashMap 本地缓存。其存储作用域为 Session，当 Session flush 或 close 之后，该 Session 中的所有 Cache 将被清空。二级缓存：与一级缓存机制相同，默认也是采用 PerpetualCache（HashMap 存储）。不同在于其存储作用域为 Mapper (Namespace.html)，并且可自定义存储源，如 Ehcache、Hazelcast 等。缓存更新机制：当某一个作用域（一级缓存 Session / 二级缓存 Namespaces）进行了 C/U/D 操作后，默认该作用域下所有 select 中的缓存将被 clear。设计模式：MyBatis 的缓存采用了 Delegate 机制及装饰器模式设计。当 put、get、remove 时，其中会经过多层 Delegate Cache 处理。其 Cache 类别主要有：BaseCache（基础缓存）：为缓存数据最终存储的处理类，默认为 PerpetualCache，基于 Map 存储；可自定义存储处理，如基于 EhCache、Memcached 等。EvictionCache（排除算法缓存）：当缓存数量达到一定大小后，将通过算法对缓存数据进行清除。默认采用 LRU 算法 (LruCache.html)，提供有 FIFO 算法 (FifoCache.html) 等。DecoratorCache（装饰器缓存）：缓存 put/get 处理前后的装饰器。例如使用 LoggingCache 输出缓存命中日志信息、使用 SerializedCache 对 Cache 的数据 put 或 get 进行序列化及反序列化处理、当设置 flushInterval (默认 1 小时.html) 后，则使用 ScheduledCache 对缓存数据进行定时刷新等。Key 生成规则：一般缓存框架的数据结构基本上都是 Key-Value 方式存储，MyBatis 对于其 Key 的生成采取规则为：[hashcode : checksum : mappedStatementId : offset : limit : executeSql : queryParams]。并发同步：对于并发 Read/Write 时缓存数据的同步问题，MyBatis 默认基于 JDK concurrent 中的 ReadWriteLock，使用 ReentrantReadWriteLock 的实现，从而通过 Lock 机制防止在并发 Write Cache 过程中出现线程安全问题。源码剖解接下来将结合 MyBatis 序列图进行源码分析。在分析其 Cache 前，先看看其整个处理过程。执行过程通常情况下，我们需要在 Service 层调用 Mapper Interface 中的方法实现对数据库的操作，上述根据产品 ID 获取 Product 对象。当调用 ProductMapper 中的方法时，其实这里所调用的是 MapperProxy 中的方法，并且 MapperProxy 已经将所有的方法拦截。其具体原理及分析，参考 MyBatis+Spring 基于接口编程的原理分析，其 invoke 方法代码为：// 当调用 Mapper 所有的方法时，将都交由 Proxy 中的 invoke 处理 public Object invoke(Object proxy, Method method, Object[] args.html) throws Throwable { try { if (!OBJECT_METHODS.contains(method.getName(.html))) { final Class declaringInterface = findDeclaringInterface(proxy, method.html); // 最终交由 MapperMethod 类处理数据库操作，初始化 MapperMethod 对象 final MapperMethod mapperMethod = new MapperMethod(declaringInterface, method, sqlSession.html); // 执行 mapper method，返回执行结果 final Object result = mapperMethod.execute(args.html); .... return result; } } catch (SQLException e.html) { e.printStackTrace(); } return null; }其中的 mapperMethod 中的 execute 方法代码如下：public Object execute(Object[] args.html) throws SQLException { Object result; // 根据不同的操作类别，调用 DefaultSqlSession 中的执行处理 if (SqlCommandType.INSERT == type.html) { Object param = getParam(args.html); result = sqlSession.insert(commandName, param.html); } else if (SqlCommandType.UPDATE == type.html) { Object param = getParam(args.html); result = sqlSession.update(commandName, param.html); } else if (SqlCommandType.DELETE == type.html) { Object param = getParam(args.html); result = sqlSession.delete(commandName, param.html); } else if (SqlCommandType.SELECT == type.html) { if (returnsList.html) { result = executeForList(args.html); } else { Object param = getParam(args.html); result = sqlSession.selectOne(commandName, param.html); } } else { throw new BindingException("Unknown execution method for: " + commandName.html); } return result; }由于这里是根据 ID 进行查询，所以最终调用为 sqlSession.selectOne 函数，也就是接下来的 DefaultSqlSession.selectOne 执行。⑤ 可以在 DefaultSqlSession 看到，其 selectOne 调用了 selectList 方法：public Object selectOne(String statement, Object parameter.html) { List list = selectList(statement, parameter.html); if (list.size(.html) == 1) { return list.get(0.html); } ... } public List selectList(String statement, Object parameter, RowBounds rowBounds.html) { try { MappedStatement ms = configuration.getMappedStatement(statement.html); // 如果启用了 Cache 才调用 CachingExecutor.query，反之则使用 BaseExecutor.query 进行数据库查询 return executor.query(ms, wrapCollection(parameter.html), rowBounds, Executor.NO_RESULT_HANDLER); } catch (Exception e.html) { throw ExceptionFactory.wrapException("Error querying database. Cause: " + e, e.html); } finally { ErrorContext.instance().reset(); } }到这里，已经执行到具体数据查询的流程。在分析 CachingExecutor.query 前，先看看 MyBatis 中 Executor 的结构及构建过程。执行器（Executor）Executor：执行器接口，也是最终执行数据获取及更新的实例。其类结构如下：BaseExecutor：基础执行器抽象类。实现一些通用方法，如 createCacheKey 之类。并且采用模板模式将具体的数据库操作逻辑 (doUpdate、doQuery.html) 交由子类实现。另外，可以看到变量 localCache: PerpetualCache，在该类采用 PerpetualCache 实现基于 Map 存储的一级缓存，其 query 方法如下：public List query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler.html) throws SQLException { ErrorContext.instance().resource(ms.getResource(.html)).activity("executing a query".html).object(ms.getId(.html)); // 执行器已关闭 if (closed.html) throw new ExecutorException("Executor was closed.".html); List list; try { queryStack++; // 创建缓存 Key CacheKey key = createCacheKey(ms, parameter, rowBounds.html); // 从本地缓存在中获取该 key 所对应 的结果集 final List cachedList = (List.html) localCache.getObject(key.html); // 在缓存中找到数据 if (cachedList != null.html) { list = cachedList; } else { // 未从本地缓存中找到数据，开始调用数据库查询 // 为该 key 添加一个占位标记 localCache.putObject(key, EXECUTION_PLACEHOLDER.html); try { // 执行子类所实现的数据库查询 操作 list = doQuery(ms, parameter, rowBounds, resultHandler.html); } finally { // 删除该 key 的占位标记 localCache.removeObject(key.html); } // 将 db 中的数据添加至本地缓存中 localCache.putObject(key, list.html); } } finally { queryStack--; } // 刷新当前队列中的所有 DeferredLoad 实例，更新 MateObject if (queryStack == 0.html) { for (DeferredLoad deferredLoad : deferredLoads.html) { deferredLoad.load(); } } return list; }BatchExecutor、ReuseExecutor、SimpleExecutor：这几个继承了 BaseExecutor 的实现，实现其 doQuery、doUpdate 等方法，同样都是采用 JDBC 对数据库进行操作。三者区别在于：批量执行、重用 Statement 执行、普通方式执行。具体应用及场景在 MyBatis 的文档上都有详细说明。CachingExecutor：二级缓存执行器。这里灵活地使用了 Delegate 机制，其委托执行的类是 BaseExecutor。当无法从二级缓存获取数据时，同样需要从 DB 中进行查询，于是在这里可以直接委托给 BaseExecutor 进行查询。其大概流程为：流程为：从二级缓存中进行查询 -> [如果缓存中没有，委托给 BaseExecutor] -> 进入一级缓存中查询 -> [如果也没有] -> 则执行 JDBC 查询。其 query 代码如下：public List query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler.html) throws SQLException { if (ms != null.html) { // 获取二级缓存实例 Cache cache = ms.getCache(); if (cache != null.html) { flushCacheIfRequired(ms.html); // 获取 读锁 ( Read 锁可由多个 Read 线程同时保持.html) cache.getReadWriteLock().readLock().lock(); try { // 当前 Statement 是否启用了二级缓存 if (ms.isUseCache(.html)) { // 将创建 cache key 委托给 BaseExecutor 创建 CacheKey key = createCacheKey(ms, parameterObject, rowBounds.html); final List cachedList = (List.html) cache.getObject(key.html); // 从二级缓存中找到缓存数据 if (cachedList != null.html) { return cachedList; } else { // 未找到缓存，委托给 BaseExecutor 执行查询 List list = delegate.query(ms, parameterObject, rowBounds, resultHandler.html); tcm.putObject(cache, key, list.html); return list; } } else { // 没有启用二级缓存，直接委托给 BaseExecutor 执行查询 return delegate.query(ms, parameterObject, rowBounds, resultHandler.html); } } finally { // 当前线程释放 Read 锁 cache.getReadWriteLock().readLock().unlock(); } } } return delegate.query(ms, parameterObject, rowBounds, resultHandler.html); }至此，已经完成了整个缓存执行器的流程分析。接下来是对缓存的数据管理实例进行分析，也就是其 Cache 接口，用于对缓存数据 put、get 及 remove 的实例对象。Cache 委托链构建正如最开始的缓存概述所描述，其缓存类的设计采用装饰模式，基于委托的调用机制。缓存实例构建：缓存实例的构建，MyBatis 在解析其 Mapper 配置文件时就已经将该实现初始化。在 org.apache.ibatis.builder.xml.XMLMapperBuilder 类中可以看到：private void cacheElement(XNode context.html) throws Exception { if (context != null.html) { // 基础缓存类型 String type = context.getStringAttribute("type", "PERPETUAL".html); Class typeClass = typeAliasRegistry.resolveAlias(type.html); // 排除算法缓存类型 String eviction = context.getStringAttribute("eviction", "LRU".html); Class evictionClass = typeAliasRegistry.resolveAlias(eviction.html); // 缓存自动刷新时间 Long flushInterval = context.getLongAttribute("flushInterval".html); // 缓存存储实例引用的大小 Integer size = context.getIntAttribute("size".html); // 是否是只读缓存 boolean readWrite = !context.getBooleanAttribute("readOnly", false.html); Properties props = context.getChildrenAsProperties(); // 初始化缓存实现 builderAssistant.useNewCache(typeClass, evictionClass, flushInterval, size, readWrite, props.html); } }以下是 useNewCache 方法实现：public Cache useNewCache(Class typeClass, Class evictionClass, Long flushInterval, Integer size, boolean readWrite, Properties props) { typeClass = valueOrDefault(typeClass, PerpetualCache.class); evictionClass = valueOrDefault(evictionClass, LruCache.class); // 这里构建 Cache 实例采用 Builder 模式，每一个 Namespace 生成一个 Cache 实例 Cache cache = new CacheBuilder(currentNamespace.html) // Builder 前设置一些从 XML 中解析过来的参数 .implementation(typeClass.html) .addDecorator(evictionClass.html) .clearInterval(flushInterval.html) .size(size.html) .readWrite(readWrite.html) .properties(props.html) // 再看下面的 build 方法实现 .build(); configuration.addCache(cache.html); currentCache = cache; return cache; } public Cache build() { setDefaultImplementations(); // 创建基础缓存实例 Cache cache = newBaseCacheInstance(implementation, id.html); setCacheProperties(cache.html); // 缓存排除算法初始化，并将其委托至基础缓存中 for (Class<? extends Cache> decorator : decorators.html) { cache = newCacheDecoratorInstance(decorator, cache.html); setCacheProperties(cache.html); } // 标准装饰器缓存设置，如 LoggingCache 之类，同样将其委托至基础缓存中 cache = setStandardDecorators(cache.html); // 返回最终缓存的责任链对象 return cache; }最终生成后的缓存实例对象结构：可见，所有构建的缓存实例已经通过责任链方式将其串连在一起，各 Cache 各负其责、依次调用，直到缓存数据被 Put 至基础缓存实例中存储。Cache 实例解剖实例类：SynchronizedCache说明：用于控制 ReadWriteLock，避免并发时所产生的线程安全问题。解剖：对于 Lock 机制来说，其分为 Read 和 Write 锁。其 Read 锁允许多个线程同时持有，而 Write 锁一次能被一个线程持有。如果当 Write 锁没有释放，其它需要 Write 的线程只能等待其释放才能去持有。其代码实现：public void putObject(Object key, Object object.html) { acquireWriteLock(); // 获取 Write 锁 try { delegate.putObject(key, object.html); // 委托给下一个 Cache 执行 put 操作 } finally { releaseWriteLock(); // 释放 Write 锁 } }对于 Read 数据来说，也是如此，不同的是 Read 锁允许多线程同时持有：public Object getObject(Object key.html) { acquireReadLock(); try { return delegate.getObject(key.html); } finally { releaseReadLock(); } }其具体原理可以看看 JDK concurrent 中的 ReadWriteLock 实现。实例类：LoggingCache说明：用于日志记录处理，主要输出缓存命中率信息。解剖：说到缓存命中信息的统计，只有在 get 的时候才需要统计命中率：public Object getObject(Object key.html) { requests++; // 每调用一次该方法，则获取次数 +1 final Object value = delegate.getObject(key.html); if (value != null.html) { // 命中！命中 +1 hits++; } if (log.isDebugEnabled(.html)) { // 输出命中率。计算方法为：hits / requests 则为命中率 log.debug("Cache Hit Ratio [" + getId(.html) + "]: " + getHitRatio()); } return value; }实例类：SerializedCache说明：向缓存中 put 或 get 数据时的序列化及反序列化处理。解剖：序列化在 Java 里面已经是最基础的东西了，这里也没有什么特殊之处：public void putObject(Object key, Object object.html) { // PO 类需要实现 Serializable 接口 if (object == null || object instanceof Serializable.html) { delegate.putObject(key, serialize((Serializable.html) object)); } else { throw new CacheException("SharedCache failed to make a copy of a non-serializable object: " + object.html); } } public Object getObject(Object key.html) { Object object = delegate.getObject(key.html); // 获取数据时对 byte 数据进行反序列化 return object == null ? null : deserialize((byte[].html) object); }其 serialize 及 deserialize 代码就不必要贴了。实例类：LruCache说明：最近最少使用的：移除最长时间不被使用的对象，基于 LRU 算法。解剖：这里的 LRU 算法基于 LinkedHashMap 覆盖其 removeEldestEntry 方法实现。好像之前看过 XMemcached 的 LRU 算法也是这样实现的。初始化 LinkedHashMap，默认为大小为 1024 个元素：public LruCache(Cache delegate.html) { this.delegate = delegate; setSize(1024.html); // 设置 map 默认大小 } public void setSize(final int size.html) { // 设置其 capacity 为 size, 其 factor 为.75F keyMap = new LinkedHashMap(size, .75F, true.html) { // 覆盖该方法，当每次往该 map 中 put 时数据时，如该方法返回 True，便移除该 map 中使用最少的 Entry // 其参数 eldest 为当前最老的 Entry protected boolean removeEldestEntry(Map.Entry eldest.html) { boolean tooBig = size() > size; if (tooBig.html) { eldestKey = eldest.getKey(); // 记录当前最老的缓存数据的 Key 值，因为要委托给下一个 Cache 实现删除 } return tooBig; } }; } public void putObject(Object key, Object value.html) { delegate.putObject(key, value.html); cycleKeyList(key.html); // 每次 put 后，调用移除最老的 key } // 看看当前实现是否有 eldestKey, 有的话就调用 removeObject，将该 key 从 cache 中移除 private void cycleKeyList(Object key.html) { keyMap.put(key, key.html); // 存储当前 put 到 cache 中的 key 值 if (eldestKey != null.html) { delegate.removeObject(eldestKey.html); eldestKey = null; } } public Object getObject(Object key.html) { keyMap.get(key.html); // 便于 该 Map 统计 get 该 key 的次数 return delegate.getObject(key.html); }实例类：PerpetualCache说明：这个比较简单，直接通过一个 HashMap 来存储缓存数据。所以没什么说的，直接看下面的 MemcachedCache 吧。自定义二级缓存：Memcached 实现其自定义二级缓存也较为简单，它本身默认提供了对 Ehcache 及 Hazelcast 的缓存支持：Mybatis-Cache。我这里参考它们的实现，自定义了针对 Memcached 的缓存支持，其代码如下：package com.xx.core.plugin.mybatis; import java.util.LinkedList; import java.util.concurrent.locks.ReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock; import org.apache.ibatis.cache.Cache; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import com.xx.core.memcached.JMemcachedClientAdapter; import com.xx.core.memcached.service.CacheService; import com.xx.core.memcached.service.MemcachedService; /** * Cache adapter for Memcached. * * @author denger */ public class MemcachedCache implements Cache { // Sf4j logger reference private static Logger logger = LoggerFactory.getLogger(MemcachedCache.class); /** The cache service reference. */ protected static final CacheService CACHE_SERVICE = createMemcachedService(); /** The ReadWriteLock. */ private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock(); private String id; private LinkedList<String> cacheKeys = new LinkedList<String>(); public MemcachedCache(String id.html) { this.id = id; } // 创建缓存服务类，基于 java-memcached-client protected static CacheService createMemcachedService() { JMemcachedClientAdapter memcachedAdapter; try { memcachedAdapter = new JMemcachedClientAdapter(); } catch (Exception e.html) { String msg = "Initial the JMmemcachedClientAdapter Error."; logger.error(msg, e.html); throw new RuntimeException(msg.html); } return new MemcachedService(memcachedAdapter.html); } @Override public String getId() { return this.id; } // 根据 key 从缓存中获取数据 @Override public Object getObject(Object key.html) { String cacheKey = String.valueOf(key.hashCode(.html)); Object value = CACHE_SERVICE.get(cacheKey.html); if (!cacheKeys.contains(cacheKey.html)){ cacheKeys.add(cacheKey.html); } return value; } @Override public ReadWriteLock getReadWriteLock() { return this.readWriteLock; } // 设置数据至缓存中 @Override public void putObject(Object key, Object value.html) { String cacheKey = String.valueOf(key.hashCode(.html)); if (!cacheKeys.contains(cacheKey.html)){ cacheKeys.add(cacheKey.html); } CACHE_SERVICE.put(cacheKey, value.html); } // 从缓存中删除指定 key 数据 @Override public Object removeObject(Object key.html) { String cacheKey = String.valueOf(key.hashCode(.html)); cacheKeys.remove(cacheKey.html); return CACHE_SERVICE.delete(cacheKey.html); } // 清空当前 Cache 实例中的所有缓存数据 @Override public void clear() { for (int i = 0; i < cacheKeys.size(.html); i++){ String cacheKey = cacheKeys.get(i.html); CACHE_SERVICE.delete(cacheKey.html); } cacheKeys.clear(); } @Override public int getSize() { return cacheKeys.size(); } }在 ProductMapper 中增加配置：<cache eviction="LRU" type="com.xx.core.plugin.mybatis.MemcachedCache" />启动 Memcached：memcached -c 2000 -p 11211 -vv -U 0 -l 192.168.1.2 -v执行 Mapper 中的查询、修改等操作，Test：@Test public void testSelectById() { Long pid = 100L; Product dbProduct = productMapper.selectByID(pid.html); Assert.assertNotNull(dbProduct.html); Product cacheProduct = productMapper.selectByID(pid.html); Assert.assertNotNull(cacheProduct.html); productMapper.updateName("IPad", pid.html); Product product = productMapper.selectByID(pid.html); Assert.assertEquals(product.getName(.html), "IPad"); }Memcached Logging：看上去没什么问题~ OK 了。说明：本文基于 MyBatis 3.0.x 版本源码进行分析，部分类名（如 BaseExcutor 应为 BaseExecutor）及外部链接（如 grepcode、iteye）可能因版本迭代或服务关闭而失效，实际开发请以官方最新文档为准。