Cet article vous explique qu'est-ce que Spring Cache ? L'introduction à l'utilisation de Spring Cache a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer, j'espère qu'elle vous sera utile.
缓存 est une méthode très couramment utilisée pour améliorer les performances dans le travail réel. dans de nombreux scénarios.
Cet article se déroule à travers un exemple simple. En comparant notre cache auto-défini d'origine et la méthode de configuration du cache basée sur le regard de Spring, il démontre la puissance du cache Spring, puis présente ses principaux principes, ses points d'extension et. limites des scénarios d’utilisation. En lisant cet article. Vous devriez être capable de maîtriser la puissante technologie de mise en cache apportée par Spring en peu de temps. Il peut fournir des capacités de mise en cache pour le code existant avec très peu de configuration.
Spring 3.1 introduit la passionnante technologie de cache basée sur les annotations, qui n'est essentiellement pas une solution d'implémentation de cache spécifique (telle que EHCache ou OSCache), mais c'est une abstraction pour la mise en cache. en ajoutant une petite quantité de diverses annotations définies par celui-ci au code existant, l'effet de renvoi d'objets à partir des méthodes de cache peut être obtenu.
La technologie de mise en cache de Spring est également assez flexible. Non seulement SpEL (Spring Expression Language) peut être utilisé pour définir des clés de cache et diverses conditions, mais il fournit également une solution de stockage temporaire de cache prête à l'emploi et prend également en charge l'intégration avec les caches professionnels grand public tels que EHCache.
Un résumé de ses fonctionnalités est le suivant :
Avec une petite quantité d'annotations de configuration, le code existant peut être conçu pour prendre en charge la mise en cache
Prise en charge prête à l'emploi, c'est-à-dire que vous pouvez utiliser le cache sans installer ni déployer de composants tiers supplémentaires
Prend en charge Spring Express Langage, et peut utiliser n'importe quelle propriété de l'objet ou de la méthode pour définir la clé et la condition du cache
prend en charge AspectJ et implémente en fait la prise en charge de la mise en cache pour n'importe quelle méthode
prend en charge votre propre clé de définition et les gestionnaires de cache auto-définis, qui ont une flexibilité et une évolutivité considérables
Cet article donnera une introduction détaillée au cache Spring basé sur les caractéristiques ci-dessus , principalement à travers un exemple et un principe simples. L'introduction est développée, puis nous examinerons un exemple de cache plus pratique. Enfin, les restrictions d'utilisation et les précautions du Spring Cache seront présentées.
D'accord. Commençons
Ici, nous montrons d'abord une implémentation de cache complètement auto-définie, c'est-à-dire qu'aucun composant tiers n'est nécessaire pour implémenter la mémoire d'un certain objet.
Le scénario est le suivant :
Mettez en cache une méthode de requête de compte, en utilisant le nom du compte comme clé et l'objet de compte comme valeur lors de l'interrogation directe du compte avec le même nom de compte. du cache Renvoie les résultats. Sinon mettez à jour le cache. Le service de requête de compte prend également en charge le rechargement du cache (c'est-à-dire vider le cache)
Définissez d'abord une classe d'entité : la classe de compte, qui a les principaux attributs d'identifiant et de nom. Il dispose de méthodes getter et 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;
}
}, puis définit un gestionnaire de cache, qui est responsable de la mise en œuvre de la logique du cache, de la prise en charge de l'ajout, de la modification et de la suppression d'objets, ainsi que de la prise en charge des génériques d'objets de valeur.
Par exemple :
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();
}
}D'accord, maintenant que nous avons des classes d'entités et un gestionnaire de cache, nous avons également besoin d'une classe de service qui fournit des requêtes de compte. Cette classe de service utilise un gestionnaire de cache pour prendre en charge la mise en cache des requêtes de compte. Par exemple :
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));
}
}Maintenant, nous commençons à écrire une classe de test pour tester si le cache vient d'être valide
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");
}
}Selon l'analyse, le résultat en cours devrait être : Premier , à partir de la requête de base de données, puis renvoyer directement les résultats dans le cache. Après avoir réinitialisé le cache, vous devez d'abord interroger à partir de la base de données. Renvoyez ensuite les résultats dans le cache. Vérifiez le journal du programme en cours d'exécution, par exemple :
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
Vous pouvez voir que notre cache fonctionne, mais une telle solution de mise en cache auto-définie présente les inconvénients suivants :
Le couplage entre le code de mise en cache et le code métier est trop élevé. Comme dans l'exemple ci-dessus, la méthode getAccountByName() dans AccountService a trop de logique de mise en cache, ce qui est peu pratique à maintenir et à modifier.
Inflexible, une telle solution de mise en cache ne prend pas en charge une certaine. Cache sous certaines conditions, par exemple, seuls certains types de comptes doivent être mis en cache. De telles exigences entraîneront des modifications dans le code
Le stockage en cache est relativement difficile à écrire et ne peut pas être flexible. . Passez à l'utilisation d'un module de mise en cache tiers
Si votre code a l'ombre du code ci-dessus, vous pouvez envisager d'optimiser la structure de votre code selon l'introduction suivante, ou vous pouvez. Appelons cela de la simplification. Vous constaterez que votre code deviendra beaucoup plus élégant !
Nous apportons des modifications à AccountService1. Créer un compteService2 :
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));
}
}Nous avons remarqué qu'il y a une ligne dans le code ci-dessus :
@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。则进行缓存操作，否则直接调用方法运行的返回结果。
我们看看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 主要针对方法配置，能够依据方法的请求參数对其结果进行缓存，和 @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应该是一个特殊的值
上面介绍过 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 凝视有一个属性 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 方法假设想实现基于凝视的缓存，必须採用基于 AspectJ 的 AOP 机制
有的时候，我们在代码迁移、调试或者部署的时候。恰好没有 cache 容器，比方 memcache 还不具备条件，h2db 还没有装好等，假设这个时候你想调试代码，岂不是要疯掉？这里有一个办法。在不具备缓存条件的时候，在不改代码的情况下。禁用缓存。
方法就是改动 spring*.xml 配置文件，设置一个找不到缓存就不做不论什么操作的标志位，例如以下
注意曾经的 cacheManager 变为了 simpleCacheManager。且没有配置 accountCache 实例，后面的 cacheManager 的实例是一个 CompositeCacheManager，他利用了前面的 simpleCacheManager 进行查询。假设查询不到。则依据标志位 fallbackToNoOpCache 来推断是否不做不论什么缓存操作。
<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>Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Comment changer phpmyadmin en chinois
Tutoriel d'utilisation du serveur cloud
l'utilisation du processeur
Quels sont les logiciels de dessin ?
Introduction à la signification de += en langage C
Ripple le prix du marché actuel de la monnaie
L'inscription Bitcoin va-t-elle disparaître ?
Comment définir le style de lien en CSS
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
