Mybatis原始碼手記-從快取體系看責任鏈派發模式與迴圈依賴企業級實踐
一、快取總覽
Mybatis在設計上處處都有用到的快取,而且Mybatis的快取體系設計上遵循單一職責、開閉原則、高度解耦。及其精巧,充分的將快取分層,其獨到之處可以套用到很多類似的業務上。這裡將主要的快取體系做一下簡單的分析筆記。以及藉助Mybatis快取體系的學習,進一步窺探責任鏈派發模式企業級實踐,以及物件迴圈依賴場景下如何避免裝載死迴圈的企業級解決方案。
先來一張之前的執行體系圖:
對照這張執行圖,不難看出,其實對於一次Mybatis查詢呼叫,即SqlSession -> SimpleExecutor/ReuseExecutor/BatchExecutor -> JDBC,其實快取就是在SqlSession到Executor*之間做一層截獲請求的邏輯。從巨集觀上很好理解。CachingExecutor作為BaseExecutor的一個前置增強裝飾器,其增強的功能就是,判斷是否命中了快取,如果命中快取,則不進行BaseExecutor的執行派發。
1 public class CachingExecutor implements Executor { 2 // BaseExecutor 3 private final Executor delegate; 4 public CachingExecutor(Executor delegate) { 5 this.delegate = delegate; 6 delegate.setExecutorWrapper(this); 7 } 8 @Override 9 public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) 10 throws SQLException { 11 Cache cache = ms.getCache(); 12 if (cache != null) { 13 flushCacheIfRequired(ms); 14 if (ms.isUseCache() && resultHandler == null) { 15 ensureNoOutParams(ms, boundSql); 16 List<E> list = (List<E>) tcm.getObject(cache, key); 17 if (list == null) { 18 list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); 19 tcm.putObject(cache, key, list); // issue #578 and #116 20 } 21 return list; 22 } 23 } 24 // 如果未命中快取則向BaseExecutor派發 25 return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); 26 } 27 }
所以由此來看,mybatis的快取是先嚐試命中CachingExecutor的二級快取,如果未命中,則派發個BaseExecutor,下來才會去嘗試命中一級快取。由於一級快取比較簡單,我們先來看一級快取。
二、一級快取概覽
之前執行器的那一節講過,Mybatis的執行器和SqlSession都是一對一的關係
1 public class DefaultSqlSession implements SqlSession { 2 // ... 3 private final Executor executor; 4 // ... 5 }
而每個執行器裡邊用一個成員變數來做快取容器
1 public abstract class BaseExecutor implements Executor { 2 // ... 3 protected PerpetualCache localCache; 4 // ... 5 }
那麼也就是說,一旦SqlSession關閉,即物件銷燬,必然BaseExecutor物件銷燬,所以一級快取容器跟著銷燬。由此可以推到出:一級快取是SqlSession級別的快取。也就是要命中一級快取,必須是同一個SqlSession,而且未關閉。
再來看一下一級快取是如何設定快取的:
1 public abstract class BaseExecutor implements Executor { 2 protected PerpetualCache localCache; 3 @Override 4 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException { 5 BoundSql boundSql = ms.getBoundSql(parameter); 6 CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql); 7 return query(ms, parameter, rowBounds, resultHandler, key, boundSql); 8 } 9 @Override 10 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { 11 ErrorContext.instance().resource(ms.getResource()).activity("executing a query").object(ms.getId()); 12 if (closed) { 13 throw new ExecutorException("Executor was closed."); 14 } 15 if (queryStack == 0 && ms.isFlushCacheRequired()) { 16 clearLocalCache(); 17 } 18 List<E> list; 19 try { 20 queryStack++; 21 list = resultHandler == null ? (List<E>) localCache.getObject(key) : null; 22 if (list != null) { 23 handleLocallyCachedOutputParameters(ms, key, parameter, boundSql); 24 } else { 25 list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql); 26 } 27 } finally { 28 queryStack--; 29 } 30 if (queryStack == 0) { 31 for (DeferredLoad deferredLoad : deferredLoads) { 32 deferredLoad.load(); 33 } 34 // issue #601 35 deferredLoads.clear(); 36 if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) { 37 // issue #482 38 clearLocalCache(); 39 } 40 } 41 return list; 42 } 43 }
通過這一段原始碼,可以看到,是在第6行去構建快取key,在第21行嘗試獲取快取。構建快取key,取決於四個維度:MappedStatement(同一個statementId)、parameter(同樣的查詢引數)、RowBounds(同樣的行數)、BoundsSql(同樣的SQL),加上上邊SqlSession的條件,一級快取的命中條件為:相同的SqlSession、statementId、parameter、行數、Sql,才能命中一級快取。
這裡在說一句題外話,就是當mybatis與Spring整合時,SqlSession的管理就交給Spring框架了,每次Mybatis的查詢都會由Spring框架新建一個Sqlsession供mybatis用,看起來一級快取永遠失效。解決辦法就是給查詢加上事務,當加上事務的時候,Spring框架會保證在一個事務裡邊只提供給mybatis同一個SqlSession物件。
再看下一級快取何時會被重新整理掉,來上原始碼:
1 public abstract class BaseExecutor implements Executor { 2 protected PerpetualCache localCache; 3 @Override 4 public void close(boolean forceRollback) { 5 try { 6 try { 7 rollback(forceRollback); 8 } finally { 9 if (transaction != null) { 10 transaction.close(); 11 } 12 } 13 } catch (SQLException e) { 14 log.warn("Unexpected exception on closing transaction. Cause: " + e); 15 } finally { 16 transaction = null; 17 deferredLoads = null; 18 localCache = null; 19 localOutputParameterCache = null; 20 closed = true; 21 } 22 } 23 @Override 24 public int update(MappedStatement ms, Object parameter) throws SQLException { 25 ErrorContext.instance().resource(ms.getResource()).activity("executing an update").object(ms.getId()); 26 if (closed) { 27 throw new ExecutorException("Executor was closed."); 28 } 29 clearLocalCache(); 30 return doUpdate(ms, parameter); 31 } 32 @Override 33 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { 34 if (queryStack == 0 && ms.isFlushCacheRequired()) { 35 clearLocalCache(); 36 } 37 if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) { 38 clearLocalCache(); 39 } 40 } 41 @Override 42 public void commit(boolean required) throws SQLException { 43 clearLocalCache(); 44 } 45 46 @Override 47 public void rollback(boolean required) throws SQLException { 48 if (!closed) { 49 try { 50 clearLocalCache(); 51 flushStatements(true); 52 } finally { 53 if (required) { 54 transaction.rollback(); 55 } 56 } 57 } 58 } 59 60 @Override 61 public void clearLocalCache() { 62 if (!closed) { 63 localCache.clear(); 64 localOutputParameterCache.clear(); 65 } 66 }
對於這段原始碼,清除快取的場景,著重關注一下clearLocalCache的呼叫的地方:
即觸發更新操作(第29行)、配置flushCache=true(第35行)、配置快取作用於為STATEMENT(第38行)、commit時候(第42行)、rollback時候(第50行)、執行器關閉時候(第7行)都會清除一級快取。
三、一級快取對於巢狀子查詢迴圈依賴場景的解決方案
迴圈依賴的情況處處可見,比如:一個班主任,下邊有多個學生,每個學生又有一個對應的班主任。
對於班主任和學生這種場景,在mybatis層面屬於典型的巢狀子查詢。mybatis在處理巢狀查詢的時候,都會查詢,然後在設定屬性的時候,如果發現有子查詢,則發起子查詢。那麼,如果不加特殊干預,這種場景將會陷入設定屬性觸發查詢的死迴圈中。
1 <select id="selectHeadmasterById" resultMap="teacherMap"> 2 select * from teacher where id = #{id} 3 </select> 4 <resultMap id="teacherMap" type="Teacher" autoMapping="true"> 5 <result column="name" property="name"/> 6 <collection property="students" column="id" select="selectStudentsByTeacherId" fetchType="eager"/> 7 </resultMap> 8 <select id="selectStudentsByTeacherId" resultMap="studentMap"> 9 select * from student where teacher_id = #{teacherId} 10 </select> 11 <resultMap id="studentMap" type="comment"> 12 <association property="teacher" column="teacher_id" select="selectHeadmasterById" fetchType="eager"/> 13 </resultMap>
mybatis在處理這種情況的時候,巧妙的用了一個臨時一級快取佔位符與延遲裝載(不同於懶載入),解決了查詢死迴圈的問題。這裡我們直接上原始碼:
每次查詢,如果沒有命中有效快取(即非佔位符快取)mybatis都會事先給一級快取寫入一個佔位符,待資料庫查詢完畢後,再將真正的資料覆蓋掉佔位符快取。
1 public abstract class BaseExecutor implements Executor { 2 protected ConcurrentLinkedQueue<DeferredLoad> deferredLoads; 3 protected PerpetualCache localCache; 4 protected int queryStack; 5 @Override 6 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { 7 ErrorContext.instance().resource(ms.getResource()).activity("executing a query").object(ms.getId()); 8 if (closed) { 9 throw new ExecutorException("Executor was closed."); 10 } 11 if (queryStack == 0 && ms.isFlushCacheRequired()) { 12 clearLocalCache(); 13 } 14 List<E> list; 15 try { 16 queryStack++; 17 list = resultHandler == null ? (List<E>) localCache.getObject(key) : null; 18 if (list != null) { 19 handleLocallyCachedOutputParameters(ms, key, parameter, boundSql); 20 } else { 21 // 如果未獲取到快取則查庫 22 list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql); 23 } 24 } finally { 25 queryStack--; 26 } 27 if (queryStack == 0) { 28 for (DeferredLoad deferredLoad : deferredLoads) { 29 deferredLoad.load(); 30 } 31 deferredLoads.clear(); 32 if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) { 33 clearLocalCache(); 34 } 35 } 36 return list; 37 } 38 }
如上Query方法的第22行進去:
1 private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { 2 List<E> list; 3 // 查庫之前先設定佔位符快取 4 localCache.putObject(key, EXECUTION_PLACEHOLDER); 5 try { 6 list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql); 7 } finally { 8 localCache.removeObject(key); 9 } 10 localCache.putObject(key, list); 11 if (ms.getStatementType() == StatementType.CALLABLE) { 12 localOutputParameterCache.putObject(key, parameter); 13 } 14 return list; 15 }
BaseExecutor.queryFromDataBase方法的第6行,會觸發資料庫查詢,緊接著會進入結果值設定的邏輯。那麼首先會探測有無巢狀的子查詢,如果有,則前一步主查詢暫時等待,立即發起子查詢。
1 private Object getNestedQueryMappingValue(ResultSet rs, MetaObject metaResultObject, ResultMapping propertyMapping, ResultLoaderMap lazyLoader, String columnPrefix) 2 throws SQLException { 3 final String nestedQueryId = propertyMapping.getNestedQueryId(); 4 final String property = propertyMapping.getProperty(); 5 final MappedStatement nestedQuery = configuration.getMappedStatement(nestedQueryId); 6 final Class<?> nestedQueryParameterType = nestedQuery.getParameterMap().getType(); 7 final Object nestedQueryParameterObject = prepareParameterForNestedQuery(rs, propertyMapping, nestedQueryParameterType, columnPrefix); 8 Object value = null; 9 if (nestedQueryParameterObject != null) { 10 final BoundSql nestedBoundSql = nestedQuery.getBoundSql(nestedQueryParameterObject); 11 final CacheKey key = executor.createCacheKey(nestedQuery, nestedQueryParameterObject, RowBounds.DEFAULT, nestedBoundSql); 12 final Class<?> targetType = propertyMapping.getJavaType(); 13 // 判斷當前的子查詢是否和之前的某一步主查詢相同 14 if (executor.isCached(nestedQuery, key)) { 15 executor.deferLoad(nestedQuery, metaResultObject, property, key, targetType); 16 value = DEFERRED; 17 } else { 18 final ResultLoader resultLoader = new ResultLoader(configuration, executor, nestedQuery, nestedQueryParameterObject, targetType, key, nestedBoundSql); 19 if (propertyMapping.isLazy()) { 20 lazyLoader.addLoader(property, metaResultObject, resultLoader); 21 value = DEFERRED; 22 } else { 23 // 立即發起子查詢 24 value = resultLoader.loadResult(); 25 } 26 } 27 } 28 return value; 29 }
這塊重點關注第13行和第23行。其中第23行又會遞迴到上邊BaseExecutor.query程式碼片段的第22行。如果getNestedQueryMappingValue程式碼段走的是滴15行邏輯,那麼,會對應BaseExecutor.query程式碼片段的第28行。這塊遞迴比較繞。下來做下通俗的解釋:
首先查詢班主任的主查詢給一級快取寫入一個佔位符快取,然後去查庫,然後設定屬性,如果沒有巢狀子查詢,那麼到這裡就把設定好屬性的值寫入覆蓋剛才一級佔位符快取。流暢完畢。
但是恰好有巢狀子查詢,所以查詢班主任的主查詢就停在設定屬性這一步,然後又發起一次查詢,查詢學生,然後又進入查詢學生設定屬性的方法。
設定學生屬性方法又發現又有巢狀子查詢,所以有發起一次學生查詢班主任的查詢操作,又進入到設定屬性這塊,但是發現一級快取裡邊有前邊住查詢的站位快取。所以沒有在查庫,而是將本次子查詢放入延遲裝載的容器裡邊。本次子查詢結束。緊接著前一步子查詢(老師查學生)結束。
緊接著查詢老師的住查詢設定屬性完畢,並將自己的結果覆蓋之前寫入的站位快取。同時啟動了延時裝載的邏輯,延時裝載就是從一級快取取出剛才查詢老師的一級快取資料(老師),給第二步子查詢(學生)做一下MetaObject屬性設定。
說的通俗一點:主查詢(查班主任)執行時先寫入站位快取,緊接著掛起,發起第一個巢狀子查詢(用老師查學生),緊接著該子查詢再掛起,發起學生查老師,但是發現第一步主查詢有一級快取(站位快取),那麼本次子查詢自動加入延遲裝載佇列,然後終結改子查詢,等待主查詢真正查完,然後延遲裝載器再從快取取出資料給第一個子查詢(老師查學生)進行屬性設定。
說了這麼多,肯定暈車了,這裡給出一個時序圖:
總結一下:
1、佔位符快取作用在於標識與當前查詢相同的前邊的巢狀查詢。比如:查詢學生所屬班主任,發現前邊的主查詢就是查詢班主任,所以就不在執行班主任查詢。等待真正的班主任查詢完畢,我們只需去快取裡邊取即可。所以我們不執行查詢,只是將本次屬性設定放入延遲裝載佇列即可。
2、queryStack用來記錄當前查詢處於巢狀的第幾層。當queryStack == 0時,證明整個查詢已經迴歸到最初的主查詢上,此時,所有過程中需要延遲裝載的物件,都能啟動真實裝載了。
3、一級快取在解決巢狀子查詢屬性設定迴圈依賴上啟至關作用。所以以及快取是不能完全關閉的。但是我們可以設定:LocalCacheScope.STATEMENT,來讓一級快取及時清空。參見原始碼
1 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { 2 // ... 3 try { 4 queryStack++; 5 list = resultHandler == null ? (List<E>) localCache.getObject(key) : null; 6 if (list != null) { 7 handleLocallyCachedOutputParameters(ms, key, parameter, boundSql); 8 } else { 9 list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql); 10 } 11 } finally { 12 queryStack--; 13 } 14 if (queryStack == 0) { 15 for (DeferredLoad deferredLoad : deferredLoads) { 16 deferredLoad.load(); 17 } 18 deferredLoads.clear(); 19 // 設定LocalCacheScope.STATEMENT來及時清空快取 20 if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) { 21 clearLocalCache(); 22 } 23 } 24 return list; 25 }
四、二級快取
來先上一個二級快取的執行流程:
二級快取是BaseExecutor的前置增強包裝類CachingExecutor裡邊實現的,即如果從CachingExecutor裡邊命中快取,則不進行BaseExecutor的派發(如下第14行)。
1 public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) 2 throws SQLException { 3 Cache cache = ms.getCache(); 4 if (cache != null) { 5 flushCacheIfRequired(ms); 6 if (ms.isUseCache() && resultHandler == null) { 7 ensureNoOutParams(ms, parameterObject, boundSql); 8 @SuppressWarnings("unchecked") 9 List<E> list = (List<E>) tcm.getObject(cache, key); 10 if (list == null) { 11 list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); 12 tcm.putObject(cache, key, list); // issue #578 and #116 13 } 14 return list; 15 } 16 } 17 return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); 18 }
11行與17行的區別在於,是否啟動二級快取,如果啟動了,則將派發給BaseExecutor的查詢結果寫入暫存區(第12行,TransactionCacheManager),等事務提交在真正刷入二級快取。下來我們重點來關注一下快取的讀寫(第9行、第12行),這裡邊真正的執行物件是一系列Cache介面的實現,按職責有:執行緒安全、日誌記錄、過期清理、溢位淘汰、序列化、執行儲存等等環節。而二級快取的設計精巧之處就在於此處,完美的按職責進行責任派發,完全解耦。
接下來我們來看下,預設情況下,快取責任鏈的初始化過程:
1 public Cache useNewCache(Class<? extends Cache> typeClass, 2 Class<? extends Cache> evictionClass, 3 Long flushInterval, 4 Integer size, 5 boolean readWrite, 6 boolean blocking, 7 Properties props) { 8 Cache cache = new CacheBuilder(currentNamespace) 9 // 這裡設定預設的儲存為記憶體 10 .implementation(valueOrDefault(typeClass, PerpetualCache.class)) 11 // 這裡設定預設的溢位淘汰為LRU 12 .addDecorator(valueOrDefault(evictionClass, LruCache.class)) 13 .clearInterval(flushInterval) 14 .size(size) 15 .readWrite(readWrite) 16 .blocking(blocking) 17 .properties(props) 18 .build(); 19 configuration.addCache(cache); 20 currentCache = cache; 21 return cache; 22 }
然後是初始化過程:
1 public Cache build() { 2 setDefaultImplementations(); 3 Cache cache = newBaseCacheInstance(implementation, id); 4 setCacheProperties(cache); 5 // issue #352, do not apply decorators to custom caches 6 if (PerpetualCache.class.equals(cache.getClass())) { 7 for (Class<? extends Cache> decorator : decorators) { 8 cache = newCacheDecoratorInstance(decorator, cache); 9 setCacheProperties(cache); 10 } 11 cache = setStandardDecorators(cache); 12 } else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) { 13 cache = new LoggingCache(cache); 14 } 15 return cache; 16 } 17 private Cache setStandardDecorators(Cache cache) { 18 try { 19 MetaObject metaCache = SystemMetaObject.forObject(cache); 20 if (size != null && metaCache.hasSetter("size")) { 21 metaCache.setValue("size", size); 22 } 23 if (clearInterval != null) { 24 cache = new ScheduledCache(cache); 25 ((ScheduledCache) cache).setClearInterval(clearInterval); 26 } 27 if (readWrite) { 28 cache = new SerializedCache(cache); 29 } 30 cache = new LoggingCache(cache); 31 cache = new SynchronizedCache(cache); 32 if (blocking) { 33 cache = new BlockingCache(cache); 34 } 35 return cache; 36 } catch (Exception e) { 37 throw new CacheException("Error building standard cache decorators. Cause: " + e, e); 38 } 39 }
這裡從第3、8、24、28、30、31、33行分別進行了責任裝飾初始化。這種依據職責分別拆分然後巢狀的解耦方式,其實是一種很成熟的企業級責任派發設計模式。而且形如第8行的迴圈裝飾巢狀,在很多開源框架中都能見到,比如Dubbo的AOP機制就是這樣初始化的。
下邊直接列一下Mybatis的二級快取在設計上所覆蓋的功能,以及各功能責任鏈派發的結構圖:
從上邊的程式碼可以看出,如果設定了blocking的話,那麼最外層將會包裹BlockingCache、下來是SynchronizedCache,這兩個均是進行執行緒安全,防止快取穿透的處理。
1 public class BlockingCache implements Cache { 2 private final Cache delegate; 3 private final ConcurrentHashMap<Object, ReentrantLock> locks; 4 public BlockingCache(Cache delegate) { 5 this.delegate = delegate; 6 this.locks = new ConcurrentHashMap<Object, ReentrantLock>(); 7 } 8 @Override 9 public void putObject(Object key, Object value) { 10 try { 11 delegate.putObject(key, value); 12 } finally { 13 releaseLock(key); 14 } 15 } 16 @Override 17 public Object getObject(Object key) { 18 acquireLock(key); 19 Object value = delegate.getObject(key); 20 if (value != null) { 21 releaseLock(key); 22 } 23 return value; 24 } 25 }
1 public class SynchronizedCache implements Cache { 2 private Cache delegate; 3 @Override 4 public synchronized void putObject(Object key, Object object) { 5 delegate.putObject(key, object); 6 } 7 @Override 8 public synchronized Object getObject(Object key) { 9 return delegate.getObject(key); 10 } 11 }
再看一下負責溢位淘汰的LruCache:
1 public class LruCache implements Cache { 2 private final Cache delegate; 3 private Map<Object, Object> keyMap; 4 // 記錄當溢位時,需要淘汰的Key 5 private Object eldestKey; 6 public void setSize(final int size) { 7 // LinkedHashMap.accessOrder設定為true,即,每個被訪問的元素會一次放到佇列末尾。當溢位的時候就能從首部來移除了 8 keyMap = new LinkedHashMap<Object, Object>(size, .75F, true) { 9 @Override 10 protected boolean removeEldestEntry(Map.Entry<Object, Object> eldest) { 11 boolean tooBig = size() > size; 12 if (tooBig) { 13 eldestKey = eldest.getKey(); 14 } 15 return tooBig; 16 } 17 }; 18 } 19 @Override 20 public void putObject(Object key, Object value) { 21 delegate.putObject(key, value); 22 cycleKeyList(key); 23 } 24 private void cycleKeyList(Object key) { 25 keyMap.put(key, key); 26 if (eldestKey != null) { 27 delegate.removeObject(eldestKey); 28 eldestKey = null; 29 } 30 } 31 }
二級快取就講到這裡,總結一下二級快取件:
1、預設開啟,cachEnable開關。作用於提交後。
2、相同的StatementId。
3、相同的SQL、引數、行數。
4、跨Mapper呼叫。
五、總結
雖然在目前各種分散式應用的場景下,一級快取和二級快取都有很大概率的髒讀現象,而被禁止,但是Mybatis對這種區域性場景的設計是及其精巧的。比如,解決物件迴圈巢狀查詢的場景設計,其實這種成熟的解決方案也被Spring(也存在物件迴圈注入的情景)所應用。以及責任裝飾的設計,Dubbo同樣在使用。其實我們能從得到很多啟發,比如,對於既定的業務場景,要加入現成安全的考量,那在不侵入業務程式碼的前提下,我們是否也能增加一層責任裝飾,進行派發來完成呢?
&n