因為最近在專案中整合 Spring Cache，不過原生的 Spring Cache 支援的功能有點基本，我們想要擴充它的功能，所以需要稍微了解一下 Spring Cache 背後到底怎麼運作的，我們才有辦法找出比較合適的擴充方式。
網路上可以找到一些中國網友的原始碼解析，不過大多數找到的都是用預設的 Spring AOP，但我們專案的狀況會使用 AspectJ，所以這邊會紀錄 AspectJ 的狀況是如何運作的。
另外，因為我們還在用 Spring Boot 2.7，所以這裡會先關注在 Spring v5.3.31 版的原始碼。相關的 Spring Cache 官方文件可以參考這裡。
Spring Cache 的使用方式
那麼要從哪裡開始追蹤呢？先來看一下 Spring Cache 怎麼使用的。
@Configuration
@EnableCaching
public class AppConfig {
}
@Cacheable("books")
public Book findBook(ISBN isbn) {...}
Spring Cache 最基本的使用方式，就是像上面的例子那樣，用 @Cacheable 註解來告訴 Spring 說 findBook(...) 這個 method 要被 cache，並且需要提供一個 configuration，上面有 @EnableCaching 來要求要啟用 cache。這裡其實還需要一點其他的設定，不過因為不是這裡的重點，所以我都先略過 😆。總之，起點就是 @EnableCaching 了。
Cache 的載入流程
載入 Configuration
首先從 @EnableCaching 這個註解開始看，它的內容大概是這樣：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Import(CachingConfigurationSelector.class)
public @interface EnableCaching {
}
可以注意到，它宣告了 @Import，因此 Spring 會使用它指定的 CachingConfigurationSelector 來得知到載入什麼東西。
CachingConfigurationSelector (git) 是一個透過 parent 實作了 ImportSelector 的類別，因此它主要提供 selectImports 這個方法，用來告訴 Spring 說要載入的 class 的 FQDN 是什麼。比較重要的內容如下：
public class CachingConfigurationSelector extends AdviceModeImportSelector<EnableCaching> {
...
private static final String CACHE_ASPECT_CONFIGURATION_CLASS_NAME =
"org.springframework.cache.aspectj.AspectJCachingConfiguration";
...
@Override
public String[] selectImports(AdviceMode adviceMode) {
switch (adviceMode) {
case PROXY:
return getProxyImports();
case ASPECTJ:
return getAspectJImports();
default:
return null;
}
}
...
private String[] getAspectJImports() {
List<String> result = new ArrayList<>(2);
result.add(CACHE_ASPECT_CONFIGURATION_CLASS_NAME);
if (jsr107Present && jcacheImplPresent) {
result.add(JCACHE_ASPECT_CONFIGURATION_CLASS_NAME);
}
return StringUtils.toStringArray(result);
}
在 selectImports() 中，會依據註解設定的 adviceMode 決定 import 時要給哪個 class name，因為前面提到我們要用的是 AspectJ，並且我們並沒有要用 JSR-107，所以這裡就只看純 AspectJ 的狀況。所以可以看出，這裡如果 adviseMode 設定為 AspectJ 的話，它會回覆的 FQDN 是 org.springframework.cache.aspectj.AspectJCachingConfiguration。
於是接著來看一下 AspectJ 的 Configuration (git) 寫了什麼～。
@Configuration(proxyBeanMethods = false)
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public class AspectJCachingConfiguration extends AbstractCachingConfiguration {
@Bean(name = CacheManagementConfigUtils.CACHE_ASPECT_BEAN_NAME)
@Role(BeanDefinition.ROLE_INFRASTRUCTURE)
public AnnotationCacheAspect cacheAspect() {
AnnotationCacheAspect cacheAspect = AnnotationCacheAspect.aspectOf();
cacheAspect.configure(this.errorHandler, this.keyGenerator, this.cacheResolver, this.cacheManager);
return cacheAspect;
}
}
這裡最主要就是提供一個 Bean，這個 Bean 是用來建立 AnnotationCacheAspect 的，並且在建立的同時會把註解上的設定、以及其他需要建立的例如 ErrorHandler、KeyGenerator、CacheResolver、CacheManager 等東西都一起注入進去。
所以到這裡稍微總結一下，這整段代表的意思，是當 Spring 讀到 @EnableCaching 註解時，會基於這個 Selector 決定去載入指定的 Configuration，然後就會依據 Configuration 的內容去建立包含 CacheManager 等等的 Bean，並且初始化一個 Aspect，把那些 Aspect 需要用到的 Bean 注入到 Aspect 當中。
Aspect 被初始化以後，後面的主要工作應該就是 AspectJ 的範疇了。不過因為我目前還沒有很完整地看過 AspectJ 的文件，所以只有大略知道一些資訊，如果紀錄有誤歡迎提醒 😆。
AspectJ 在縫合的時候，會讓 Aspect 擁有 aspectOf() 的 method (doc)，所以 Spring 才有辦法呼叫 aspectOf() 來取得這個 Aspect，並且對它做設定。
載入並註冊 Aspect
前段被建立的 AnnotationCacheAspect (git) 是一個 .aj 檔，所以內容基本上就是 AspectJ 的定義了：
public aspect AnnotationCacheAspect extends AbstractCacheAspect {
public AnnotationCacheAspect() {
super(new AnnotationCacheOperationSource(false));
}
/**
* Matches the execution of any public method in a type with the @{@link Cacheable}
* annotation, or any subtype of a type with the {@code @Cacheable} annotation.
*/
private pointcut executionOfAnyPublicMethodInAtCacheableType() :
execution(public * ((@Cacheable *)+).*(..)) && within(@Cacheable *);
...
/**
* Definition of pointcut from super aspect - matched join points will have Spring
* cache management applied.
*/
protected pointcut cacheMethodExecution(Object cachedObject) :
(executionOfAnyPublicMethodInAtCacheableType()
|| executionOfAnyPublicMethodInAtCacheEvictType()
|| executionOfAnyPublicMethodInAtCachePutType()
|| executionOfAnyPublicMethodInAtCachingType()
|| executionOfCacheableMethod()
|| executionOfCacheEvictMethod()
|| executionOfCachePutMethod()
|| executionOfCachingMethod())
&& this(cachedObject);
這裡我把其他部份都略過了，只先看它定義關於 @Cacheable 的部份。它定義了一個 pointcut 叫做 executionOfAnyPublicMethodInAtCacheableType()，會被橫切到所有有標註 @Cacheable 的 public method 上。那麼 pointcut 要執行的邏輯是什麼呢？這就需要看它的 parent AbstractCacheAspect (git) 了。
public abstract aspect AbstractCacheAspect extends CacheAspectSupport implements DisposableBean {
...
@SuppressAjWarnings("adviceDidNotMatch")
Object around(final Object cachedObject) : cacheMethodExecution(cachedObject) {
MethodSignature methodSignature = (MethodSignature) thisJoinPoint.getSignature();
Method method = methodSignature.getMethod();
CacheOperationInvoker aspectJInvoker = new CacheOperationInvoker() {
public Object invoke() {
try {
return proceed(cachedObject);
}
catch (Throwable ex) {
throw new ThrowableWrapper(ex);
}
}
};
try {
return execute(aspectJInvoker, thisJoinPoint.getTarget(), method, thisJoinPoint.getArgs());
}
catch (CacheOperationInvoker.ThrowableWrapper th) {
AnyThrow.throwUnchecked(th.getOriginal());
return null; // never reached
}
}
}
可以看出，它定義了一個 around 並綁定在 cacheMethodExecution() 上，而 cacheMethodExecution() 這個 pointcut 則是定義一系列的 pointcuts。所以我的理解是，它應該是把 around 綁到所有它列出來的 pointcut，也就是像是 @Cacheable、`CachePut 等等的 pointcut。
接著來看這個 around 裡面的內容。它首先先建立了一個 CacheOperationInvoker 的 instance，這個 invoker 的目的是用來呼叫被 cache 的 method 的，接著就去呼叫 execute()，把 JoinPoint 的資訊以及剛剛建立的 invoker 都傳進去。
execute() 是 AbstractCacheAspect 從它的 parent CacheAspectSupport 繼承來的，所以接著就再去看 CacheAspectSupport 裡的內容。不過裡面內容蠻多的，所以只先節錄了 execute() 的部份：
@Nullable
protected Object execute(CacheOperationInvoker invoker, Object target, Method method, Object[] args) {
// Check whether aspect is enabled (to cope with cases where the AJ is pulled in automatically)
if (this.initialized) {
Class<?> targetClass = getTargetClass(target);
CacheOperationSource cacheOperationSource = getCacheOperationSource();
if (cacheOperationSource != null) {
Collection<CacheOperation> operations = cacheOperationSource.getCacheOperations(method, targetClass);
if (!CollectionUtils.isEmpty(operations)) {
return execute(invoker, method,
new CacheOperationContexts(operations, method, args, target, targetClass));
}
}
}
return invoker.invoke();
}
這段最主要的行為，是在檢查自己初始化的狀態，如果初始化還沒完成，就直接呼叫 invoker，否則就把 cache 的服務 (即 CacheOperationSource) 準備好，然後再去呼叫第二個 execute()。
第二個 execute() (git) 內容更長，所以這裡也是先篩掉一些內容，只先看最單純的部份：
private Object execute(final CacheOperationInvoker invoker, Method method, CacheOperationContexts contexts) {
// Special handling of synchronized invocation
if (contexts.isSynchronized()) {
...
}
...
// Check if we have a cached value matching the conditions
Cache.ValueWrapper cacheHit = findCachedItem(contexts.get(CacheableOperation.class));
...
Object cacheValue;
Object returnValue;
if (cacheHit != null && !hasCachePut(contexts)) {
// If there are no put requests, just use the cache hit
cacheValue = cacheHit.get();
returnValue = wrapCacheValue(method, cacheValue);
}
else {
// Invoke the method if we don't have a cache hit
returnValue = invokeOperation(invoker);
cacheValue = unwrapReturnValue(returnValue);
}
...
// Process any collected put requests, either from @CachePut or a @Cacheable miss
for (CachePutRequest cachePutRequest : cachePutRequests) {
cachePutRequest.apply(cacheValue);
}
...
return returnValue;
}
節錄下來的部份就是 Spring Cache 實際上操作 cache 服務和被 cache 的 method 的行為了。首先它透過 findCachedItem() 取得 cache 的結果，如果 cache hit 了，就把它放進 returnValue 中；反之，如果 cache miss 了，則會去執行被 cache 的 method 取得最新的執行結果，然後放進 returnValue 裡。
中間有一部分收集 put requests 的程式碼被我過濾掉了沒貼進來，不過大致上就是最後它會依據收集到要做的 put requests 開始一個一個 apply 到 cache 中，完成 cache 的更新。
沒有留言:
張貼留言