Mybatis 關(guān)聯(lián)屬性懶加載

延遲加載配置

mybatis默認(rèn)沒有開啟延遲加載，需要在config.xml中setting配置。

lazyLoadingEnabled：true使用延遲加載，false禁用延遲加載，默認(rèn)為false。

aggressiveLazyLoading：true啟用時(shí)，當(dāng)延遲加載開啟時(shí)訪問對(duì)象中一個(gè)懶對(duì)象屬性時(shí)，將完全加載這個(gè)對(duì)象的所有懶對(duì)象屬性。false，當(dāng)延遲加載時(shí)，按需加載對(duì)象屬性（即訪問對(duì)象中一個(gè)對(duì)象屬性時(shí)，不會(huì)加載對(duì)象中的引用屬性）。默認(rèn)為true。

修改延遲加載需要的select語句

延遲加載場景分析

查詢訂單時(shí)，需要關(guān)聯(lián)查詢訂單明細(xì)表

假設(shè)有10 個(gè)訂單，每個(gè)訂單有5個(gè)明細(xì)信息。

如果用戶僅僅需要查看訂單信息，不需要訂單明細(xì)信息，但是查詢了10+50個(gè)對(duì)象到內(nèi)存（只有10個(gè)是用戶想要的）。顯然是增加內(nèi)存的負(fù)擔(dān)。

如果用戶的需求僅僅是查詢訂單信息，我僅僅訂單信息用戶，沒有查詢訂單的詳情，那么，內(nèi)存中只有10對(duì)象（10個(gè)對(duì)象全是客戶想的），這樣做顯然 節(jié)省了內(nèi)存。

業(yè)務(wù)需求特點(diǎn)：需要的時(shí)候在進(jìn)行查詢，不需要的時(shí)候不盡興查詢，這種情況就是延遲加載，也叫作懶加載。

配置過程

去掉sql語句中對(duì)user表的查詢語句

對(duì)resultMap orderAndUser 進(jìn)行修改

注意：查詢訂單時(shí)要同時(shí)查詢userid，避免查詢user時(shí)沒有憑據(jù)

修改orderMapper.xml文件select語句

<!-- 關(guān)聯(lián)屬性延遲加載 -->
	<select id="queryOrderAndUser" resultMap="orderAndUser">
		select
		o.id oids,o.orderid,o.createtime,o.note,o.userid
		from orders o,t_user u
		where o.userid=u.id
	</select>
	<resultMap type="orders" id="orderAndUser">
		<id property="id" column="oids"></id>
		<result property="orderId" column="orderid"></result>
		<result property="createtime" column="createtime" />
		<result property="note" column="note" />
		<association property="user" javaType="users" 
		select="net.neuedu.mybatis.mapper.UserMapper.queryUserById" column="userid">
			<!-- 
				這里不查詢用戶的信息，而是將用的信息放在另外一個(gè)查詢中
				column是order表中的userid字段
			 -->
		</association>
	</resultMap>

因?yàn)樵赼ssocication多了一個(gè)select元素，就要在UserMapper中多加一個(gè)方法。

 //根據(jù)ID查詢用戶
 public Users queryUserById(Integer id);

在UserMapper.xml中添加queryUserById的select

 <!-- public Users queryUserById(Integer id); -->
 <select id="queryUserById" parameterType="int" resultType="users">
  select * from t_user where id=#{id}
 </select>

Mybatis注解方式懶加載失效分析

本人在使用spring mvc + mybatis的后臺(tái)結(jié)構(gòu)的項(xiàng)目的時(shí)候，在使用mybatis的懶加載出現(xiàn)了一些問題：

明明懶加載的配置都正確了，但就是用debug斷點(diǎn)調(diào)試的時(shí)候懶加載的屬性總是提前加載，在經(jīng)過幾天的不斷努力之后，終于發(fā)現(xiàn)了原因：

mybatis懶加載配置：

<!-- 查詢時(shí)，關(guān)閉關(guān)聯(lián)對(duì)象即時(shí)加載以提高性能 -->
<setting name="lazyLoadingEnabled" value="true" />
<!-- 設(shè)置關(guān)聯(lián)對(duì)象加載的形態(tài)，此處為按需加載字段(加載字段由SQL指 定)，不會(huì)加載關(guān)聯(lián)表的所有字段，以提高性能 -->
<setting name="aggressiveLazyLoading" value="false" />

懶加載查詢語句：

@Select("select * from user_main where username=#{username}")
 @Results({
       @Result(property = "roleNames", column = "id", many = @Many(fetchType=FetchType.LAZY,select = "getRoleNamesByUserId")),
       @Result(property = "permissionNames", column = "id", many = @Many(fetchType=FetchType.LAZY,select = "getPermissionsByUserId"))
   })
public UserPO getUserByUsername(@Param("username")String username);

測試用例：

 @Test
   public void testGetUserByUsername() throws Exception {
     SqlSession session = sqlSessionFactory.openSession();
     try {
       UserMapper userMapper = session.getMapper(UserMapper.class);
       UserPO userPo = userMapper.getUserByUsername("zhangsan");
       System.out.println(userPo);
       System.out.println(userPo.getPermissionNames());
//       List<String> map = userMapper.getRoleMain();
//       System.out.println(map);
       session.close();
     } finally {
       session.close();
     }
   }

結(jié)果調(diào)試測試用例的時(shí)候，使用debug卻發(fā)現(xiàn)懶加載并沒有生效，后來看了mybatis懶加載的源碼，依然沒有發(fā)現(xiàn)原因，感覺就是roleNames和permissionNames就是突然的加載了，斷點(diǎn)也捕捉不到，也沒有博捉到觸發(fā)的事件，這時(shí)樓主我就很奇怪了，最后經(jīng)過幾天的努力終于發(fā)現(xiàn)了原因：

mybatis源碼：configuration

protected Set<String> lazyLoadTriggerMethods = new HashSet<String>(Arrays.asList(new String[] { "equals", "clone", "hashCode", "toString" }));

默認(rèn)這四個(gè)方法或觸發(fā)懶加載，當(dāng)然，觸發(fā)懶加載的方法還有g(shù)etRoleNames 和 getPermissions ，這兩個(gè)（只針對(duì)當(dāng)前實(shí)例）

然后通過sysout輸出的時(shí)候，發(fā)現(xiàn)hashcode和equals方法被莫名的觸發(fā)了，而且debug斷點(diǎn)還捕捉不到，然后roleNames和permissionNames就被莫名的加載了

最后發(fā)現(xiàn)，這個(gè)問題和debug的原理有一定的關(guān)系，

原來，在顯示debug的黃色框框時(shí)，debug會(huì)另起一個(gè)線程，然后重新調(diào)用一遍代碼，然后顯示userpo信息的時(shí)候，又會(huì)調(diào)用userpo的hashcode方法和tostring方法，

這樣的話，就會(huì)導(dǎo)致這兩個(gè)方法會(huì)在debug線程內(nèi)觸發(fā)懶加載，造成的效果就是懶加載失效，但是實(shí)際上懶加載是生效了的，只是在debug模式上被觸發(fā)了，而且用斷點(diǎn)還捕捉不到，就會(huì)形成一個(gè)奇怪的問題，如果想用debug來查看效果，也是很簡單：

通過將觸發(fā)默認(rèn)的四個(gè)方法屏蔽來查看效果，但是不支持，因?yàn)檫@樣的話，可能會(huì)影響實(shí)體的hash排序等問題，即使是用了這個(gè)方法，也是建議看完效果以后改成默認(rèn)的

這種事代碼方式的，還有一種是配置文件方式的(自己從網(wǎng)上找)

configuration.setLazyLoadTriggerMethods(new HashSet<String>());

還有一種更好的方式來查看懶加載的效果，那就是mybatis的默認(rèn)日志，建議將日志級(jí)別調(diào)成debug（這個(gè)debug級(jí)別和debug模式不一樣），然后執(zhí)行的時(shí)候就可以通過sql語句的打印來判斷懶加載是否生效。

其實(shí)這個(gè)問題的分析最后，還是在說debug斷點(diǎn)調(diào)試的問題，它的這種原理需要注意，特別是會(huì)在另一個(gè)線程調(diào)用hashcode和tostring方法，相信在很多方面會(huì)影響到我們，希望大家能夠注意吧~

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論