스프링 캐시란 무엇입니까? Spring Cache 사용 소개
- 不言원래의
- 2018-09-20 15:05:523346검색
이 기사에서는 Spring Cache가 무엇인지 설명합니다. Spring Cache 사용에 대한 소개에는 특정 참고 가치가 있습니다. 도움이 필요한 친구들이 참고할 수 있기를 바랍니다.
Spring Cache
缓存는 실제 작업에서 성능을 향상시키기 위해 매우 일반적으로 사용되는 방법입니다. 캐싱은 다양한 시나리오에서 사용됩니다.
이 기사에서는 간단한 예제를 통해 원래의 자체 정의 캐시와 Spring의 시선 기반 캐시 구성 방법을 비교하여 Spring 캐시의 강력한 기능을 보여주고 주요 원리, 확장 지점 및 사용 시나리오의 한계를 소개합니다. 이 기사를 읽으면. 봄이 가져온 강력한 캐싱 기술을 짧은 시간 안에 마스터할 수 있을 것입니다. 거의 구성하지 않고도 기존 코드에 대한 캐싱 기능을 제공할 수 있습니다.
Overview
Spring 3.1은 본질적으로 특정 캐시 구현 솔루션(예: EHCache 또는 OSCache)이 아니라 소량의 다양한 주석을 추가하여 캐시 사용을 추상화하는 흥미로운 주석 기반 캐시 기술을 도입합니다. 기존 코드에 정의하면 메서드에서 반환된 개체를 캐싱하는 효과를 얻을 수 있습니다.
Spring의 캐싱 기술도 매우 유연합니다. SpEL(Spring Expression Language)을 사용하여 캐시 키 및 다양한 조건을 정의할 수 있을 뿐만 아니라 즉시 사용 가능한 캐시 임시 저장 솔루션을 제공하고 EHCache와 같은 주류 전문 캐시와의 통합도 지원합니다.
기능을 요약하면 다음과 같습니다.
소량의 구성 주석으로 기존 코드에서 캐싱을 지원하도록 만들 수 있습니다.
즉시 즉시 사용할 수 있는 기능을 지원합니다. , 추가로 설치 및 배포할 필요가 없습니다. 타사 구성 요소는 캐싱을 사용할 수 있습니다
Spring Express 언어를 지원하고 개체의 속성이나 메서드를 사용하여 캐시 키와 조건을 정의할 수 있습니다
-
AspectJ를 지원합니다. 실제로 모든 메소드에 대한 캐싱 지원을 구현합니다
상당한 유연성과 확장성을 갖춘 자체 정의 키 및 자체 정의 캐시 관리자를 지원합니다.
이 기사에서는 위의 특성을 기반으로 Spring 캐시에 대해 자세히 소개합니다. 간단한 예시와 원리 소개를 통해, 그리고 좀 더 실용적인 캐시 예시를 함께 살펴보겠습니다. 마지막으로 스프링 캐시의 사용 제한 및 주의사항을 소개합니다.
알겠습니다. 시작해 보겠습니다
캐싱을 직접 구현한 방법
여기에서는 먼저 완전히 자체 정의된 캐싱 구현을 보여줍니다. 즉, 특정 개체의 메모리 캐싱을 구현하는 데 타사 구성 요소가 필요하지 않습니다.
시나리오는 다음과 같습니다.
계정 이름을 키로, 계정 개체를 값으로 사용하여 계정 쿼리 방법을 캐시합니다. 동일한 계정 이름으로 계정을 쿼리하면 결과가 캐시에서 직접 반환됩니다. . 그렇지 않으면 캐시를 업데이트하십시오. 계정 쿼리 서비스는 캐시 다시 로드(즉, 캐시 지우기)도 지원합니다.
먼저 엔터티 클래스, 즉 기본 ID 및 이름 속성이 있는 계정 클래스를 정의합니다. 여기에는 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.
*/
@Service
public 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... accountName 00:53:17.168 [main] INFO c.r.s.cache.example1.AccountService - get from cache... accountName 00: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... accountName 00:53:17.169 [main] INFO c.r.s.cache.example1.AccountService - get from cache... accountName
캐시가 작동하는 것을 볼 수 있지만 이러한 자체 정의 캐싱 솔루션에는 다음과 같은 단점이 있습니다.
캐시 코드 비즈니스 코드와 결합도가 너무 높습니다. 위의 예에서와 같이 AccountService의 getAccountByName() 메소드는 캐싱 로직이 너무 많아 유지 관리 및 변경이 불편합니다. 이러한 캐싱 솔루션은 특정 조건에만 캐싱을 지원하지 않습니다. 이러한 요구 사항은 코드 변경으로 이어집니다
캐시 저장소는 상대적으로 제대로 작성되지 않았으며 타사 캐시 모듈을 사용하도록 유연하게 전환할 수 없습니다
코드에 그림자가 있다고 가정합니다. 위 코드를 포함하고 있다면 다음 소개에 따라 코드 구조를 최적화하는 것을 고려할 수 있습니다. 이는 단순화라고도 할 수 있습니다. 당신의 코드가 훨씬 더 우아해지는 것을 발견할 수 있을 것입니다!
Spring 캐시는 어떻게 이루어지나요?
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.
*/
@Service
public 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... accountName 01:10:32.457 [main] INFO c.r.s.cache.example2.AccountService2 - real querying db... accountName 01: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.
*/
@Service
public 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... accountName1
01:37:34.551 [main] INFO c.r.s.cache.example3.AccountService3 - real querying db... accountName1
01: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... accountName2
01:37:34.553 [main] INFO c.r.s.cache.example3.AccountService3 - real querying db... accountName2
01: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...accountName2
01: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... accountName2
01:37:34.596 [main] INFO c.r.s.cache.example3.AccountService3 - real querying db... accountName2
01: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
@Documented
public @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 />
接下来我们来编写測试代码：
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 />
注意曾经的 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 사용 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!