Spring Cache

在WEB后端应用程序来说，耗时比较大的往往有两个地方：一个是查数据库，一个是调用其它服务的API（因为其它服务最终也要去做查数据库等耗时操作）。重复查询也有两种。一种是我们在应用程序中代码写得不好，写的for循环，可能每次循环都用重复的参数去查询了。这种情况，比较聪明一点的程序员都会对这段代码进行重构，用Map来把查出来的东西暂时放在内存里，后续去查询之前先看看Map里面有没有，没有再去查数据库，其实这就是一种缓存的思想。另一种重复查询是大量的相同或相似请求造成的。比如资讯网站首页的文章列表、电商网站首页的商品列表、微博等社交媒体热搜的文章等等，当大量的用户都去请求同样的接口，同样的数据，如果每次都去查数据库，那对数据库来说是一个不可承受的压力。所以我们通常会把高频的查询进行缓存，我们称它为“热点”。

一、为什么使用Spring Cache

前面提到了缓存有诸多的好处，于是大家就摩拳擦掌准备给自己的应用加上缓存的功能。但是网上一搜却发现缓存的框架太多了，各有各的优势，比如Redis、Memcached、Guava、Caffeine等等。如果我们的程序想要使用缓存，就要与这些框架耦合。聪明的架构师已经在利用接口来降低耦合了，利用面向对象的抽象和多态的特性，做到业务代码与具体的框架分离。但我们仍然需要显式地在代码中去调用与缓存有关的接口和方法，在合适的时候插入数据到缓存里，在合适的时候从缓存中读取数据。
想一想AOP的适用场景，这不就是天生就应该AOP去做的吗？
是的，Spring Cache就是一个这个框架。它利用了AOP，实现了基于注解的缓存功能，并且进行了合理的抽象，业务代码不用关心底层是使用了什么缓存框架，只需要简单地加一个注解，就能实现缓存功能了。而且Spring Cache也提供了很多默认的配置，用户可以3秒钟就使用上一个很不错的缓存功能。

既然有这么好的轮子，干嘛不用呢？

二、如何使用Spring Cache

上面的3秒钟，绝对不夸张。使用SpringCache分为很简单的三步：加依赖，开启缓存，加缓存注解。

本文示例代码使用的是官方的示例代码，git地址：github.com/spring-guid…

加依赖

gradle：

implementation 'org.springframework.boot:spring-boot-starter-cache'

maven:

<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-cache</artifactId>
</dependency>

开启缓存

在启动类加上@EnableCaching注解即可开启使用缓存。

@SpringBootApplication
@EnableCaching
public class CachingApplication {public static void main(String[] args) {SpringApplication.run(CachingApplication.class, args);}
}

加缓存注解

在要缓存的方法上面添加@Cacheable注解，即可缓存这个方法的返回值。

@Override
@Cacheable("books")
public Book getByIsbn(String isbn) {simulateSlowService();return new Book(isbn, "Some book");
}
// Don't do this at home
private void simulateSlowService() {try {long time = 3000L;Thread.sleep(time);} catch (InterruptedException e) {throw new IllegalStateException(e);}
}

测试

@Override
public void run(String... args) {logger.info(".... Fetching books");logger.info("isbn-1234 -->" + bookRepository.getByIsbn("isbn-1234"));logger.info("isbn-4567 -->" + bookRepository.getByIsbn("isbn-4567"));logger.info("isbn-1234 -->" + bookRepository.getByIsbn("isbn-1234"));logger.info("isbn-4567 -->" + bookRepository.getByIsbn("isbn-4567"));logger.info("isbn-1234 -->" + bookRepository.getByIsbn("isbn-1234"));logger.info("isbn-1234 -->" + bookRepository.getByIsbn("isbn-1234"));
}

测试一下，可以发现。第一次和第二次（第二次参数和第一次不同）调用getByIsbn方法，会等待3秒，而后面四个调用，都会立即返回。

三、常用注解

Spring Cache有几个常用注解，分别为@Cacheable、@CachePut、@CacheEvict、@Caching、 @CacheConfig。除了最后一个CacheConfig外，其余四个都可以用在类上或者方法级别上，如果用在类上，就是对该类的所有public方法生效，下面分别介绍一下这几个注解。

@Cacheable

@Cacheble注解表示这个方法有了缓存的功能，方法的返回值会被缓存下来，下一次调用该方法前，会去检查是否缓存中已经有值，如果有就直接返回，不调用方法。如果没有，就调用方法，然后把结果缓存起来。这个注解一般用在查询方法上。

@CachePut：用于解决缓存数据一致性中的双写模式，需要有返回值

加了@CachePut注解的方法，会把方法的返回值put到缓存里面缓存起来，供其它地方使用。它通常用在新增方法上。

@CacheEvict：用于解决缓存数据一致性中的失效模式

使用了CacheEvict注解的方法，会清空指定缓存。一般用在更新或者删除的方法上。

@Caching

Java注解的机制决定了，一个方法上只能有一个相同的注解生效。那有时候可能一个方法会操作多个缓存（这个在删除缓存操作中比较常见，在添加操作中不太常见）。Spring Cache当然也考虑到了这种情况，@Caching注解就是用来解决这类情况的，大家一看它的源码就明白了。

public @interface Caching {Cacheable[] cacheable() default {};CachePut[] put() default {};CacheEvict[] evict() default {};
}

@CacheConfig

前面提到的四个注解，都是Spring Cache常用的注解。每个注解都有很多可以配置的属性，这个我们在下一节再详细解释。但这几个注解通常都是作用在方法上的，而有些配置可能又是一个类通用的，这种情况就可以使用@CacheConfig了，它是一个类级别的注解，可以在类级别上配置cacheNames、keyGenerator、cacheManager、cacheResolver等。

注解的属性

key： key的来源可分为三类，分别是：默认的、keyGenerator生成的、主动指定的。

condition：在激活注解功能前，进行condition验证，如果condition结果为true，则表明验证通过，缓存注解生效；否则缓存注解不生效。condition作用时机在：缓存注解检查缓存中是否有对应的key-value 之前。注：缓存注解检查缓存中是否有对应的key-value 在运行目标方法之前，所以 condition作用时机也在运行目标方法之前。

cacheNames：通过cacheNames对数据进行隔离，不同cacheName下可以有相同的key。也可称呼cacheName为命名空间。实际上(以spring-cache为例)，可以通过设置RedisCacheConfiguration#usePrefix的true或false来控制是否使用前缀。如果否，那么最终的redis键就是key值；如果是，那么就会根据cacheName生成一个前缀，然后再追加上key作为最终的redis键.cacheName还有其它重要的功能：cacheName(就像其名称【命名空间】所说)实现了数据分区的功能，一些操作可以直接按照命名空间批量进行。如：spring框架中的Cache实际对应的就是一个【命名空间】，spring会先去找到数据所在的命名空间(即：先找到对应的Cache)，再由Cache结合key，最终定位到数据。

注意：若属性cacheNames(或属性value)指定了多个命名空间;当进行缓存存储时，会在这些命名空间下都存一份key-value。当进行缓存读取时，会按照cacheNames值里命名空间的顺序，挨个挨个从命名空间中查找对应的key，如果在某个命名空间中查找打了对应的缓存，就不会再查找排在后面的命名空间，也不会再执行对应方法，直接返回缓存中的value值。

unless：功能是：是否令注解（在方法执行后的功能）不生效；若unless的结果为true，则(方法执行后的功能)不生效；若unless的结果为false，则(方法执行后的)功能生效。注：unless默认为""，即相当于默认为false。unless的作用时机：目标方法运行后。注：如果(因为直接从缓存中获取到了数据，而导致)目标方法没有被执行，那么unless字段不生效。

allEntries：此属性主要出现在@CacheEvict注解中，表示是否清除指定命名空间中的所有数据，默认为false。

beforeInvocation：此属性主要出现在@CacheEvict注解中，表示是否在目标方法执行前使此注解生效。默认为false，即:目标方法执行完毕后此注解生效。

三、常用注解的配置原理

注解使用详细例子
这部分我们最好是结合源码来看，才能更好地理解这些配置的运作机制。
源码：解析注解的时机。
这一节主要是源码解析，有点晦涩，对源码不感兴趣的同学可以跳过。但如果想要弄清楚Spring Cache运作的原理，还是推荐一看的。前面提到的几个注解@Cacheable、@CachePut、@CacheEvict、@CacheConfig，都有一些可配置的属性。这些配置的属性都可以在抽象类CacheOperation及其子类中可以找到。它们大概是这样的关系：

看到这里不得不佩服，这继承用得，妙啊。

解析每个注解的代码在SpringCacheAnnotationParser类中可以找到，比如parseEvictAnnotation方法，里面就有这么一句：

builder.setCacheWide(cacheEvict.allEntries());

明明注解里叫allEntries，但是CacheEvictOperation里却叫cacheWide？看了下作者，都是多个作者，但第一作者都是一个叫Costin Leau的哥们，我对这个命名还是有一点小小的困惑。。。看来大佬们写代码也会有命名不一致的问题

那这个SpringCacheAnnotationParser是在什么时候被调用的呢？很简单，我们在这个类的某个方法上打个断点，然后debug就行了，比如parseCacheableAnnotation方法。

在debug界面，可以看到调用链非常长，前面是我们熟悉的IOC注册Bean的一个流程，直到我们看到了一个叫做AbstractAutowireCapableBeanFactory的BeanFactory，然后这个类在创建Bean的时候会去找是否有Advisor。正好Spring Cache源码里就定义了这么一个Advisor：BeanFactoryCacheOperationSourceAdvisor。这个Advisor返回的PointCut是一个CacheOperationSourcePointcut，这个PointCut复写了matches方法，在里面去获取了一个CacheOperationSource，调用它的getCacheOperations方法。这个CacheOperationSource是个接口，主要的实现类是AnnotationCacheOperationSource。在findCacheOperations方法里，就会调用到我们最开始说的SpringCacheAnnotationParser了。

这样就完成了基于注解的解析。

四、入口：基于AOP的拦截器

那我们实际调用方法的时候，是怎么处理的呢？我们知道，使用了AOP的Bean，会生成一个代理对象，实际调用的时候，会执行这个代理对象的一系列的Interceptor。Spring Cache使用的是一个叫做CacheInterceptor的拦截器。我们如果加了缓存相应的注解，就会走到这个拦截器上。这个拦截器继承了CacheAspectSupport类，会执行这个类的execute方法，这个方法就是我们要分析的核心方法了。

@Cacheable的sync

我们继续看之前提到的execute方法，该方法首先会判断是否是同步。这里的同步配置是用的@Cacheable的sync属性，默认是false。如果配置了同步的话，多个线程尝试用相同的key去缓存拿数据的时候，会是一个同步的操作。（加锁）

我们来看看同步操作的源码。如果判断当前需要同步操作

（1）、首先会去判断当前的condition是不是符合条件
（2）、这里的condition也是@Cacheable中定义的一个配置，它是一个EL表达式，比如我们可以这样用来缓存id大于1的Book：

@Override
@Cacheable(cacheNames = "books", condition = "#id > 1", sync = true)
public Book getById(Long id) {return new Book(String.valueOf(id), "some book");
}

如果不符合条件，就不使用缓存，也不把结果放入缓存，直接跳到5。否则，尝试获取key

（3）、在获取key的时候，会先判断用户有没有定义key，它也是一个EL表达式。如果没有的话，就用keyGenerator生成一个key：

@Nullable
protected Object generateKey(@Nullable Object result) {if (StringUtils.hasText(this.metadata.operation.getKey())) {EvaluationContext evaluationContext = createEvaluationContext(result);return evaluator.key(this.metadata.operation.getKey(), this.metadata.methodKey, evaluationContext);}return this.metadata.keyGenerator.generate(this.target, this.metadata.method, this.args);
}

我们可以用这种方式手动指定根据id生成book-1，book-2这样的key：

@Override
@Cacheable(cacheNames = "books",  sync = true, key = "'book-' + #id")
public Book getById(Long id) {return new Book(String.valueOf(id), "some book");
}

这里的key是一个Object对象，如果我们不在注解上面指定key，会使用keyGenerator生成的key。默认的keyGenerator是SimpleKeyGenerator，它生成的是一个SimpleKey对象，方法也很简单，如果没有入参，就返回一个EMPTY的对象，如果有入参，且只有一个入参，并且不是空或者数组，就用这个参数（注意这里用的是参数本身，而不是SimpleKey对象。否则，用所有入参包一个SimpleKey。

源码：

@Override
public Object generate(Object target, Method method, Object... params) {return generateKey(params);
}
/*** Generate a key based on the specified parameters.*/
public static Object generateKey(Object... params) {if (params.length == 0) {return SimpleKey.EMPTY;}if (params.length == 1) {Object param = params[0];if (param != null && !param.getClass().isArray()) {return param;}}return new SimpleKey(params);
}

看到这里你一定有一个疑问吧，这里只用入参，没有类名和方法名的区别，那如果两个方法入参一样，岂不是key冲突了？

你的感觉没错，大家可以试一下这两个方法：

// 定义两个参数都是String的方法
@Override
@Cacheable(cacheNames = "books", sync = true)
public Book getByIsbn(String isbn) {simulateSlowService();return new Book(isbn, "Some book");
}@Override
@Cacheable(cacheNames = "books", sync = true)
public String test(String test) {return test;
}

// 调用这两个方法，用相同的参数"test"

logger.info("test getByIsbn -->" + bookRepository.getByIsbn("test"));
logger.info("test test -->" + bookRepository.test("test"));

你会发现两次生成的key相同，然后在调用test方法的时候，控制台会报错：

Caused by: java.lang.ClassCastException: class com.example.caching.Book cannot be cast to class java.lang.String (com.example.caching.Book is in unnamed module of loader 'app'; java.lang.String is in module java.base of loader 'bootstrap')at com.sun.proxy.$Proxy33.test(Unknown Source) ~[na:na]at com.example.caching.AppRunner.run(AppRunner.java:23) ~[main/:na]at org.springframework.boot.SpringApplication.callRunner(SpringApplication.java:795) ~[spring-boot-2.3.2.RELEASE.jar:2.3.2.RELEASE]... 5 common frames omitted

Book不能强转成String，因为我们第一次调用getByIsbn方法的时候，生成的key是test，然后换成了返回值Book对象到缓存里面。而调用test方法的时候，生成的key还是test，就会取出Book，但是test方法的返回值是String，所以会尝试强转到String，结果发现强转失败。

我们可以自定义一个keyGenerator来解决这个问题：

@Component
public class MyKeyGenerator implements KeyGenerator {@Overridepublic Object generate(Object target, Method method, Object... params) {return target.getClass().getName() + method.getName() + Stream.of(params).map(Object::toString).collect(Collectors.joining(","));}
}

然后就可以在配置里面使用这个自定义的MyKeyGenerator了，再次运行程序，就不会出现上述问题。

@Override
@Cacheable(cacheNames = "books", sync = true, keyGenerator = "myKeyGenerator")
public Book getByIsbn(String isbn) {simulateSlowService();return new Book(isbn, "Some book");
}@Override
@Cacheable(cacheNames = "books", sync = true, keyGenerator = "myKeyGenerator")
public String test(String test) {return test;
}

接着往下看，可以看到我们得到了一个Cache。这个Cache是在我们调用CacheAspectSupport的execute方法的时候，会new一个CacheOperationContext。在这个Context的构造方法里，会用cacheResolver去解析注解中的Cache，生成Cache对象。默认的cacheResolver是SimpleCacheResolver，它从CacheOperation中取得配置的cacheNames，然后用cacheManager去get一个Cache。这里的cacheManager是用于管理Cache的一个容器，默认的cacheManager是ConcurrentMapCacheManager。听名字就知道是基于ConcurrentMap来做的了，底层是ConcurrentHashMap。那这里的Cache是什么东西呢？Cache就对“缓存容器”的一个抽象，包含了缓存会用到的get、put、evict、putIfAbsent等方法。不同的cacheNames会对应不同的Cache对象，比如我们可以在一个方法上定义两个cacheNames，虽然也可以用value，它是cacheNames的别名，但如果有多个配置的时候，更推荐用cacheNames，因为这样具有更好的可读性。

@Override
@Cacheable(cacheNames = {"book", "test"})
public Book getByIsbn(String isbn) {simulateSlowService();return new Book(isbn, "Some book");
}

默认的Cache是ConcurrentMapCache，它也是基于ConcurrentHashMap的。但这里有个问题，我们回到上面的execute方法的代码，发现如果设置了sync为true，它取的是第一个Cache，而没有管剩下的Cache。所以如果你配置了sync为true，只支持配置一个cacheNames，如果配了多个，就会报错：

@Cacheable(sync=true) only allows a single cache on...

继续往下看，发现调用的是Cache的get(Object, Callcable)方法。这个方法会先尝试去缓存中用key取值，如果取不到在调用callable函数，然后加到缓存里。Spring Cache也是期望Cache的实现类在这个方法内部实现“同步”的功能。所以我们再回过头去看Cacheable中sync属性上方的注释，它写到：`使用sync为true，会有这些限制：

不支持unless，这个从代码可以看到，只支持了condition，没有支持unless；

只能有一个cache，因为代码就写死了一个。我猜这是为了更好地支持同步，它把同步放到了Cache里面去实现。

没有不支持其它的Cache操作，代码里面写死了，只支持Cachable，我猜这也是为了支持同步。

如果sync为false呢？

继续往下看execute的代码，大概经历了下面这些步骤：

尝试在方法调用前删除缓存，这个在@CacheEvict配置的beforeInvocation，默认为false（如果为true才会在这一步删除缓存）；

尝试获取缓存；

如果第2步获取不到，尝试获取Cachable的注解，生成相应的CachePutRequest；

如果第2步获取到了，并且没有CachPut注解，就直接从缓存中获取值。否则，调用目标方法；

解析CachePut注解，同样生成相应的CachePutRequest；

执行所有的CachePutRequest；

尝试在方法调用后删除缓存，如果@CacheEvict配置的beforeInvocation为false会删除缓存

至此，我们就结合源码解释完了所有的配置发生作用的时机。

五、使用其它缓存框架

如果要使用其它的缓存框架，应该怎么做呢？通过上面的源码分析我们知道，如果要使用其它的缓存框架，我们只需要重新定义好CacheManager和CacheResolver这两个Bean就行了。事实上，Spring会自动检测我们是否引入了相应的缓存框架，如果我们引入了spring-data-redis，Spring就会自动使用spring-data-redis提供的RedisCacheManager，RedisCache。如果我们要使用Caffeine框架。只需要引入Caffeine，Spring Cache就会默认使用CaffeineCacheManager和CaffeineCache。

implementation 'org.springframework.boot:spring-boot-starter-cache'
implementation 'com.github.ben-manes.caffeine:caffeine'

Caffeine是一个性能非常高的缓存框架，它使用了Window TinyLfu回收策略，提供了一个近乎最佳的命中率。Spring Cache还支持各种配置，在CacheProperties类里面，里面还提供了各种主流的缓存框架的特殊配置。比如Redis的过期时间等（默认永不过期）。

private final Caffeine caffeine = new Caffeine();private final Couchbase couchbase = new Couchbase();private final EhCache ehcache = new EhCache();private final Infinispan infinispan = new Infinispan();private final JCache jcache = new JCache();private final Redis redis = new Redis();

六、使用缓存带来的问题

双写不一致

使用缓存会带来许多问题，尤其是高并发下，包括缓存穿透、缓存击穿、缓存雪崩、双写不一致等问题。具体的问题介绍和常用的解决方案可以参考我的个人网站上的文章《缓存常见问题及解决方案》。其中主要聊一下双写不一致的问题，这是一个比较常见的问题，其中一个常用的解决方案是，更新的时候，先删除缓存，再更新数据库。所以Spring Cache的@CacheEvict会有一个beforeInvocation的配置。但使用缓存通常会存在缓存中的数据和数据库中不一致的问题，尤其是调用第三方接口，你不会知道它什么时候更新了数据。但使用缓存的业务场景很多时候并不需求数据的强一致，比如首页的热点文章，我们可以让缓存一分钟失效，这样就算一分钟内，不是最新的热点排行也没关系。

占用额外的内存

这个是无可避免的。因为总要有一个地方去放缓存。不管是ConcurrentHashMap也好，Redis也好，Caffeine也好，总归是会占用额外的内存资源去放缓存的。但缓存的思想正是用空间去换时间，有时候占用这点额外的空间对于时间上的优化来说，是非常值得的。这里需要注意的是，SpringCache默认使用的是ConcurrentHashMap，它不会自动回收key，所以如果使用默认的这个缓存，程序就会越来越大，并且得不到回收。最终可能导致OOM。

我们来模拟实验一下：

@Component
public class MyKeyGenerator implements KeyGenerator {@Overridepublic Object generate(Object target, Method method, Object... params) {// 每次都生成不同的keyreturn UUID.randomUUID().toString();}
}
//调它个100w次
for (int i = 0; i < 1000000; i++) {bookRepository.test("test");
}

然后把最大内存设置成20M: -Xmx20M。

我们先来测试默认的基于ConcurrentHashMap的缓存，发现它很快就会报OOM。

Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main"Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "RMI TCP Connection(idle)"

我们使用Caffeine，并且配置一下它的最大容量：

spring:cache:caffeine:spec: maximumSize=100

再次运行程序，发现正常运行，不会报错。所以如果是用基于同一个JVM内存的缓存的话，个人比较推荐使用Caffeine，强烈不推荐用默认的基于ConcurrentHashMap的实现。那什么情况适合用Redis这种需要调用第三方进程的缓存呢？如果你的应用程序是分布式的，一个服务器查询出来后，希望其它服务器也能用这个缓存，那就推荐使用基于Redis的缓存。使用Spring Cache也有不好之处，就是屏蔽了底层缓存的特性。比如，很难做到不同的场景有不同的过期时间（但并不是做不到，也可以通过配置不同的cacheManager来实现）。但整体上来看，还是利大于弊的，大家自己衡量，适合自己就好。

七、总结

     * 每一个需要缓存的数据我们都来指定要放到那个名字的缓存。【缓存的分区(按照业务类型分)】* 代表当前方法的结果需要缓存，如果缓存中有，方法都不用调用，如果缓存中没有，会调用方法。最后将方法的结果放入缓存* 默认行为*      如果缓存中有，方法不再调用*      key是默认生成的:缓存的名字::SimpleKey::[](自动生成key值)*      缓存的value值，默认使用jdk序列化机制，将序列化的数据存到redis中*      默认时间是 -1：**   自定义操作：key的生成*      指定生成缓存的key：key属性指定，接收一个Spel*      指定缓存的数据的存活时间:配置文档中修改存活时间*      将数据保存为json格式*** Spring-Cache的不足之处：*  1）、读模式*      缓存穿透：查询一个null数据。解决方案：缓存空数据*      缓存击穿：大量并发进来同时查询一个正好过期的数据。解决方案：加锁 ? 默认是无加锁的;使用sync = true来解决击穿问题*      缓存雪崩：大量的key同时过期。解决：加随机时间。加上过期时间*  2)、写模式：（缓存与数据库一致）*      1）、读写加锁。*      2）、引入Canal,感知到MySQL的更新去更新Redis*      3）、读多写多，直接去数据库查询就行**  总结：*      常规数据（读多写少，即时性，一致性要求不高的数据，完全可以使用Spring-Cache）：写模式(只要缓存的数据有过期时间就足够了)*      特殊数据：特殊设计**  原理：*      CacheManager(RedisCacheManager)->Cache(RedisCache)->Cache负责缓存的读写

文章转自

Spring Cache相关推荐

SpringBoot第十三篇：springboot集成spring cache
本文介绍如何在springboot中使用默认的spring cache, 声明式缓存 Spring 定义 CacheManager 和 Cache 接口用来统一不同的缓存技术.例如 JCache. E ...
学习笔记：cache 和spring cache 技术（1）
title: 学习笔记:cache 和spring cache 技术(1) author: Eric liu tags: [] categories: hexo 缓存是实际工作中非常常用的一种提高性能 ...
spring Cache /Redis 缓存 + Spring 的集成示例
spring Cache https://www.ibm.com/developerworks/cn/opensource/os-cn-spring-cache/ spring+redis 缓存 ht ...
java清空redis缓存数据库_java相关：Spring Cache手动清理Redis缓存
java相关:Spring Cache手动清理Redis缓存发布于 2020-4-24| 复制链接摘记: 这篇文章主要介绍了Spring Cache手动清理Redis缓存,文中通过示例代码介绍的非 ...
注释驱动的 Spring cache 缓存介绍--转载
概述 Spring 3.1 引入了激动人心的基于注释(annotation)的缓存(cache)技术,它本质上不是一个具体的缓存实现方案(例如 EHCache 或者 OSCache),而是一个对缓存使 ...
Spring Cache抽象-基于XML的配置声明（基于EhCache的配置）
概述完整示例 pomxml增加依赖数据库表数据Oracle 实体类服务层 ehcache的配置文件 Spring-EhCache配置文件单元测试日志输出日志分析示例源码概述首先请阅读 ...
Spring Cache抽象-基于XML的配置声明（基于ConcurrentMap的配置）
概述示例项目结构数据库表数据Oracle 实体类服务层 Spring配置文件单元测试日志输出日志分析示例源码概述 Spring Cache基于注解的配置如果不想使用注解或者由于其他 ...
Spring Cache抽象-使用SpEL表达式
概述 SpEl表达式概述在Spring Cache注解属性中(比如key,condition和unless),Spring的缓存抽象使用了SpEl表达式,从而提供了属性值的动态生成及足够的灵活性. ...
Spring Cache抽象-缓存管理器
概述 SimpleCacheManager NoOpCacheManager ConcurrentMapCacheManager CompositeCacheManager 概述 CacheManag ...
Spring Cache抽象-使用Java类注解的方式整合EhCache
概述工程结构源码概述 Spring Cache抽象-之缓存注解这篇博文中我们介绍了SpringCache抽象注解的使用方式既然这是一个抽象,我们需要一个具体的缓存存储实现.比价流行的有:基于J ...