前言
在SpringCache緩存初探中我們研究了如何利用spring cache已有的幾種實現快速地滿足我們對於緩存的需求。這一次我們有了新的更個性化的需求，想在一個請求的生命周期里實現緩存。
需求背景是：一次數據的組裝需要調用多個方法，然而在這多個方法里又會調用同一個IO接口，此時多浪費了一次IO的資源。首先想到的解決方案是將這次IO接口提出來調用，然后將結果作為參數傳遞到多個方法中，但是這樣一來，每個調用這些方法的地方都得添加額外的代碼。那么第二個方案就是，我們還是分別調用，只不過將這個結果緩存起來，就像我們之前做的那樣。
這時候問題來了，這個數據結果我們希望盡可能實時，即使只緩存了一秒，導致在不同的請求里用了同一份數據也不太好，又或者緩存效率非常低下，可能就這個請求會查幾次。看來不得不自己實現一個只保持在一次請求過程中的緩存了。
方案分析
要將數據緩存在一次請求周期內，那我們先得區分是什么環境下的請求，以分析我們如何存儲數據。
1. Web
Web環境下的有個絕佳的數據存儲位置 HttpServletRequest的Attribute 。調用setAttribute和getAttribute方法就能輕易地將我們的數據用key-value的形式存儲在請求上，而且每次請求都自動擁有一個干凈的Request 。想要獲取到HttpServletRequest 也非常簡單，在web請求中隨時隨地調用((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest() 即可。
2. RPC框架
我司所使用的rpc框架是基於finagle自研的，對外提供服務時使用線程池進行處理請求，即對於一次完整的請求，會使用同一個線程進行處理。首先想到的辦法還是改動這個rpc框架服務端，增加一個可以對外暴露的、可以key-value存儲的請求上下文。為了能在方便的地方獲取到這個請求上下文，得將其存儲在ThreadLocal中。
綜合這兩種環境考慮，我們最好還是實現一個統一的方案以減少維護和開發成本。Spring的RequestContextHolder.getRequestAttributes()其實也是使用ThreadLocal來實現的，那我們可以統一將數據存到ThreadLocal<Map<Object,Object>>，自己來維護緩存的清理。
存儲位置有了，接下來實現SpringCache思路就比較清晰了。
實現SpringCache
要實現SpringCache需要一個CacheManager，接口定義如下
public interface CacheManager { Cache getCache(String name); Collection<String> getCacheNames(); }
可以看到其實只需要實現Cache接口就行了。 在上一篇文章中提到的SimpleCacheManager，它的Cache實現ConcurrentMapCache內部的存儲是依賴ConcurrentMap<Object, Object>。我們的實現跟它非常類似，最主要的不同是我們需要使用ThreadLocal<Map<Object, Object>> 下面給出幾處關鍵的實現，其他部分簡單看下ConcurrentMapCache就能明白。
1 extends
我們選擇不直接繼承Cache而是AbstractValueAdaptingCache，其被大多數緩存實現所繼承，它的作用主要是包裝value值以區分是沒有命中緩存還是緩存的null值。
2 store
private final ThreadLocal<Map<Object, Object>> store = ThreadLocal.withInitial(() -> new HashMap<>(128));
我們的緩存數據存儲的地方，ThreadLocal保證緩存只會存在於這一個線程中。同時又因為只有一個線程能夠訪問，我們簡單地使用HashMap即可。
3 get
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實現即可。
@After("bean(server)")
public void clearThreadCache() {
threadCacheManager.clear();
}
記得將Cache的clear方法通過我們自定義的CacheManager暴露出來。同時也要確保切面能覆蓋每個請求的結束。
總結與擴展
從以上一個簡單的ThreadLocalCacheManager實現，我們對CacheManager又有了更多的理解。
同時可能也會有更多的疑問。
1. 我們實現的這些方法，從方法名和邏輯上看起來都很簡單，那他們是如何配合使用的？跟@Cacheable上的sync又有什么關系呢？
再回顧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 時, 只會調用如下代碼
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中其他的方法進行緩存的處理。邏輯較為簡單清晰，自行閱讀源碼即可。
2. 用ThreadLocal嚴格來說實現的只是線程內的緩存，萬一一次請求中有異步操作怎么辦？
異步操作分兩種情況，直接創建線程或者使用線程池。對於第一種情況我們可以簡單地使用java.lang.InheritableThreadLocal 來替代ThreadLocal，創建的子進程會自然而然地共享父進程的InheritableThreadLocal；第二種情況就相對比較復雜了，建議可以參考 alibaba/transmittable-thread-local ，它實現了線程池下的ThreadLocal值傳遞功能。