Mybatis查詢延遲加載詳解及實例
1.1 啟用延遲加載
Mybatis的延遲加載是針對嵌套查詢而言的，是指在進行查詢的時候先只查詢最外層的SQL，對于內層SQL將在需要使用的時候才查詢出來。Mybatis的延遲加載默認是關閉的，即默認是一次就將所有的嵌套SQL一并查了將對象所有的信息都查詢出來。開啟延遲加載有兩種方式。
第一種是在對應的<collection>或<association>標簽上指定fetchType屬性值為“lazy”。如下示例中我們在查詢id為selectByPrimaryKey的查詢時會返回BaseResultMap，在BaseResultMap中，我們指定了屬性“nodes”是一個集合類型的，而且是需要通過id為selectNodes的查詢進行查詢的，我們指定了該查詢的fetchType為lazy，即延遲加載。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
<resultMap id="BaseResultMap" type="com.elim.learn.mybatis.model.SysWfProcess"> <id column="id" jdbcType="INTEGER" property="id" /> <result column="template_id" jdbcType="INTEGER" property="templateId" /> <result column="creator" jdbcType="INTEGER" property="creator" /> <result column="create_time" jdbcType="TIMESTAMP" property="createTime" /> <collection property="nodes" column="id" ofType="com.elim.learn.mybatis.model.SysWfNode" select="selectNodes" fetchType="lazy"/></resultMap><resultMap id="SysWfNodeResult" type="com.elim.learn.mybatis.model.SysWfNode"> <id column="id" jdbcType="INTEGER" property="nodeId" /> <result column="process_id" jdbcType="INTEGER" property="processId" /> <result column="node_code" jdbcType="VARCHAR" property="nodeCode" /> <result column="node_name" jdbcType="VARCHAR" property="nodeName" /></resultMap><select id="selectByPrimaryKey" parameterType="java.lang.Integer" resultMap="BaseResultMap"> select <include refid="Base_Column_List" /> from sys_wf_process where id = #{id,jdbcType=INTEGER}</select><select id="selectNodes" resultMap="SysWfNodeResult"> select id, process_id, node_code, node_name from sys_wf_node where process_id=#{id}</select> |
第二種是開啟全局的延遲加載。通過在Mybatis的配置文件的<settings>標簽下加上如下配置可開啟全局的延遲加載。開啟了全局的延遲加載后我們就無需再在各個嵌套的子查詢上配置延遲加載了，如果有某一個嵌套的子查詢是不需要延遲加載的，可以設置其fetchType=”eager”。設置在嵌套查詢上的fetchType可以覆蓋全局的延遲加載設置。
|
1
|
<setting name="lazyLoadingEnabled" value="true"/> |
1.2 分析
Mybatis的查詢結果是由ResultSetHandler接口的handleResultSets()方法處理的。ResultSetHandler接口只有一個實現，DefaultResultSetHandler。有興趣的朋友可以去看一下它的源碼，看一下它是如何處理結果集的。對于本文的主題，延遲加載相關的一個核心的方法就是如下這個創建返回結果對象的方法。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
private Object createResultObject(ResultSetWrapper rsw, ResultMap resultMap, ResultLoaderMap lazyLoader, String columnPrefix) throws SQLException { final List<Class<?>> constructorArgTypes = new ArrayList<Class<?>>(); final List<Object> constructorArgs = new ArrayList<Object>(); final Object resultObject = createResultObject(rsw, resultMap, constructorArgTypes, constructorArgs, columnPrefix); if (resultObject != null && !typeHandlerRegistry.hasTypeHandler(resultMap.getType())) { final List<ResultMapping> propertyMappings = resultMap.getPropertyResultMappings(); for (ResultMapping propertyMapping : propertyMappings) { // issue gcode #109 && issue #149 if (propertyMapping.getNestedQueryId() != null && propertyMapping.isLazy()) { return configuration.getProxyFactory().createProxy(resultObject, lazyLoader, configuration, objectFactory, constructorArgTypes, constructorArgs); } } } return resultObject;} |
在上面方法中我們可以看到Mybatis先是根據正常情況創建一個返回類型對應的對象。當我們的ResultMap是包含子查詢的時候，其會在我們正常返回類型對象的基礎上創建對應的代理對象。對，你沒有看錯，就是我們的直接結果是代理對象，而不是子查詢對應的屬性是代理對象。默認是基于JavassistProxyFactory類創建的代理對象。可以通過Mybatis的全局配置proxyFactory來更改，可選值是CGLIB和JAVASSIST，默認是后者。需要使用CGLIB代理時注意加入CGLIB的包。
|
1
|
<setting name="proxyFactory" value="CGLIB"/> |
回過頭來看我們之前的那個延遲加載的配置，我們的一個查詢返回的是SysWfProcess類型的對象，其有一個SysWfNode集合類型的nodes屬性，nodes屬性是通過一個子查詢查出來的，而且是延遲加載。這個時候我們來進行以下測試。
|
1
2
3
4
5
6
7
8
9
10
11
12
|
@Test public void testLazyLoad1() { SysWfProcessMapper mapper = this.session.getMapper(SysWfProcessMapper.class); SysWfProcess process = mapper.selectByPrimaryKey(1); System.out.println(process.getClass()); } |
這個時候你會發現，上面的測試代碼的輸出結果是一個代理類，而不是我們自己的com.elim.learn.mybatis.model.SysWfProcess類型。另外如果你啟用了日志輸出，并且是打印的DEBUG日志，你會看到Mybatis是發了兩條SQL進行查詢的。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
2016-12-23 15:43:21,131 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Preparing: select id, template_id, creator, create_time from sys_wf_process where id = ?2016-12-23 15:43:21,156 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Parameters: 1(Integer)2016-12-23 15:43:21,269 DEBUG [main] (BaseJdbcLogger.java:145) - <== Total: 1class com.elim.learn.mybatis.model.SysWfProcess_$$_jvstc25_02016-12-23 15:43:21,271 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Preparing: select id, process_id, node_code, node_name from sys_wf_node where process_id=?2016-12-23 15:43:21,272 DEBUG [main] (BaseJdbcLogger.java:145) - ==> Parameters: 1(Integer)2016-12-23 15:43:21,274 DEBUG [main] (BaseJdbcLogger.java:145) - <== Total: 2 |
但是如果我們把最后一個System.out.println()去掉，也就是說我們只是從數據庫中查詢出SysWfProcess對象，而不使用它的時候，通過查看日志輸出你會發現Mybatis又只會發送一條SQL，即只是查詢出SysWfProcess的信息。這是為什么呢？
1.3 aggressiveLazyLoading
這是因為當我們啟用了延遲加載時，我們的查詢結果返回的是一個代理對象，當我們訪問該代理對象的方法時，都會觸發加載所有的延遲加載的對象信息。這也就可以很好的解釋上面的場景。但是如果是這樣的設計，貌似Mybatis的延遲加載作用不大。但事實并非如此，這只是Mybatis的一個默認策略，我們可以通過Mybatis的全局配置aggressiveLazyLoading來改變它，默認是true，表示延遲加載時將在第一次訪問代理對象的方法時就將全部的延遲加載對象加載出來。當設置為false時則會在我們第一次訪問延遲加載的對象的時候才會從數據庫加載對應的數據。注意在延遲對象未從數據庫加載出來前，我們對應延遲對象的屬性將是null，因為你沒有對它賦值。
|
1
|
<setting name="aggressiveLazyLoading" value="fasle"/> |
1.4 lazyLoadTriggerMethods
那如果我們設置了aggressiveLazyLoading=”false”，但又希望在調用某些方法之前把所有的延遲對象都從數據庫加載出來，怎么辦呢？這個時候我們可以通過lazyLoadTriggerMethods參數來指定需要加載延遲對象的方法調用。默認是equals、clone、hashCode和toString，也就是說我們在調用代理對象的這些方法之前就會把延遲加載對象從數據庫加載出來。
|
1
|
<setting name="lazyLoadTriggerMethods" value="equals,clone,hashCode,toString" /> |
Mybatis延遲加載生成的代理對象的代理過程，可以參考ProxyFactory的創建代理對象的過程，以下是基于Javassist創建的代理對象的代理過程，基于CGLIB的代理也是類似的。從下面的代碼我們可以看到Mybatis的代理對象需要從數據庫加載延遲對象時是在目標方法被調用以前發生的，這就可以保證我們的目標方法被調用時延遲加載的對象已經從數據庫中加載出來了。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
@Override public Object invoke(Object enhanced, Method method, Method methodProxy, Object[] args) throws Throwable { final String methodName = method.getName(); try { synchronized (lazyLoader) { if (WRITE_REPLACE_METHOD.equals(methodName)) { Object original = null; if (constructorArgTypes.isEmpty()) { original = objectFactory.create(type); } else { original = objectFactory.create(type, constructorArgTypes, constructorArgs); } PropertyCopier.copyBeanProperties(type, enhanced, original); if (lazyLoader.size() > 0) { return new JavassistSerialStateHolder(original, lazyLoader.getProperties(), objectFactory, constructorArgTypes, constructorArgs); } else { return original; } } else { if (lazyLoader.size() > 0 && !FINALIZE_METHOD.equals(methodName)) { if (aggressive || lazyLoadTriggerMethods.contains(methodName)) { lazyLoader.loadAll(); } else if (PropertyNamer.isProperty(methodName)) { final String property = PropertyNamer.methodToProperty(methodName); if (lazyLoader.hasLoader(property)) { lazyLoader.load(property); } } } } } return methodProxy.invoke(enhanced, args); } catch (Throwable t) { throw ExceptionUtil.unwrapThrowable(t); } } } |
本文是介紹的都是基于<collection>這種關聯，其實<association>關聯的對象的延遲加載也是一樣的，它們的默認策略也是一樣的。
感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！
原文鏈接：https://my.oschina.net/elim1/blog/817302
