在SpringCache緩存初探中咱們研究瞭如何利用spring cache已有的幾種實現快速地知足咱們對於緩存的需求。這一次咱們有了新的更個性化的需求,想在一個請求的生命週期裏實現緩存。html
需求背景是:一次數據的組裝須要調用多個方法,然而在這多個方法裏又會調用同一個IO接口,此時多浪費了一次IO的資源。首先想到的解決方案是將此次IO接口提出來調用,而後將結果做爲參數傳遞到多個方法中,可是這樣一來,每一個調用這些方法的地方都得添加額外的代碼。那麼第二個方案就是,咱們仍是分別調用,只不過將這個結果緩存起來,就像咱們以前作的那樣。java
這時候問題來了,這個數據結果咱們但願儘量實時,即便只緩存了一秒,致使在不一樣的請求裏用了同一份數據也不太好,又或者緩存效率很是低下,可能就這個請求會查幾回。看來不得不本身實現一個只保持在一次請求過程當中的緩存了。node
要將數據緩存在一次請求週期內,那咱們先得區分是什麼環境下的請求,以分析咱們如何存儲數據。git
Web環境下的有個絕佳的數據存儲位置 HttpServletRequest
的Attribute
。調用setAttribute
和getAttribute
方法就能輕易地將咱們的數據用key-value的形式存儲在請求上,並且每次請求都自動擁有一個乾淨的Request
。想要獲取到HttpServletRequest
也很是簡單,在web請求中隨時隨地調用((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest()
便可。github
我司所使用的rpc框架是基於finagle自研的,對外提供服務時使用線程池進行處理請求,即對於一次完整的請求,會使用同一個線程進行處理。首先想到的辦法仍是改動這個rpc框架服務端,增長一個能夠對外暴露的、能夠key-value存儲的請求上下文。爲了能在方便的地方獲取到這個請求上下文,得將其存儲在ThreadLocal
中。 web
綜合這兩種環境考慮,咱們最好仍是實現一個統一的方案以減小維護和開發成本。Spring的RequestContextHolder.getRequestAttributes()
其實也是使用ThreadLocal
來實現的,那咱們能夠統一將數據存到ThreadLocal<Map<Object,Object>>
,本身來維護緩存的清理。spring
存儲位置有了,接下來實現SpringCache思路就比較清晰了。 windows
要實現SpringCache須要一個CacheManager,接口定義以下緩存
xxxxxxxxxx
public interface CacheManager {
Cache getCache(String name);
Collection<String> getCacheNames();
}
能夠看到其實只須要實現Cache接口就好了。 在上一篇文章中提到的SimpleCacheManager
,它的Cache實現ConcurrentMapCache
內部的存儲是依賴ConcurrentMap<Object, Object>
。咱們的實現跟它很是相似,最主要的不一樣是咱們須要使用ThreadLocal<Map<Object, Object>>
下面給出幾處關鍵的實現,其餘部分簡單看下ConcurrentMapCache
就能明白。app
咱們選擇不直接繼承Cache而是AbstractValueAdaptingCache
,其被大多數緩存實現所繼承,它的做用主要是包裝value值以區分是沒有命中緩存仍是緩存的null值。
xxxxxxxxxx
private final ThreadLocal<Map<Object, Object>> store = ThreadLocal.withInitial(() -> new HashMap<>(128));
咱們的緩存數據存儲的地方,ThreadLocal
保證緩存只會存在於這一個線程中。同時又由於只有一個線程可以訪問,咱們簡單地使用HashMap
便可。
xxxxxxxxxx
public <T> T get(Object key, Callable<T> valueLoader) {
return (T) fromStoreValue(this.store.get().computeIfAbsent(key, r -> {
try {
return toStoreValue(valueLoader.call());
} catch (Throwable ex) {
throw new ValueRetrievalException(key, valueLoader, ex);
}
}));
}
至此咱們即將大功告成,只差一個步驟,ThreadLocal
的清理:使用AOP
實現便可。
xxxxxxxxxx
"bean(server)") (
public void clearThreadCache() {
threadCacheManager.clear();
}
記得將Cache的clear
方法經過咱們自定義的CacheManager
暴露出來。同時也要確保切面能覆蓋每一個請求的結束。
從以上一個簡單的ThreadLocalCacheManager
實現,咱們對CacheManager
又有了更多的理解。
同時可能也會有更多的疑問。
再回顧Spring Cache爲咱們提供的@Cacheable
中的sync
的註釋,它提到此功能的做用是: 同步化對被註解方法的調用,使得多個線程試圖調用此方法時,只有一個線程可以成功調用,其餘線程直接取此次調用的返回值。同時也提到這僅僅只是個hint
,是否真的能成仍是要看緩存提供者。
咱們找到Spring Cache處理緩存調用的關鍵方法org.springframework.cache.interceptor.CacheAspectSupport#execute(org.springframework.cache.interceptor.CacheOperationInvoker, java.lang.reflect.Method, org.springframework.cache.interceptor.CacheAspectSupport.CacheOperationContexts)
(spring-context-5.1.5.RELEASE)
通過分析,當sync = true
時, 只會調用以下代碼
xxxxxxxxxx
return wrapCacheValue(method, cache.get(key, () -> unwrapReturnValue(invokeOperation(invoker))))
即咱們上文實現的T get(Object key, Callable<T> valueLoader)
方法,回頭一看一切都清晰了。 只要咱們的this.store.get().computeIfAbsent
是同步的,那這個sync = true
就起做用了。 固然咱們這裏使用的HashMap
不支持,可是咱們若是換成ConcurrentMap
就可以實現同步化的功能。另外簡單粗暴地讓方法同步也是能夠的(RedisCache就是這樣作的)。
當sync = false
時,會組合Cache中其餘的方法進行緩存的處理。邏輯較爲簡單清晰,自行閱讀源碼便可。
異步操做分兩種狀況,直接建立線程或者使用線程池。對於第一種狀況咱們能夠簡單地使用java.lang.InheritableThreadLocal
來替代ThreadLocal
,建立的子進程會天然而然地共享父進程的InheritableThreadLocal
;第二種狀況就相對比較複雜了,建議能夠參考 alibaba/transmittable-thread-local ,它實現了線程池下的ThreadLocal
值傳遞功能。