盤點 Mybatis 使用過程中遇到的坑！

作者：了不起 2024-09-09 08:02:27

springframework包下的@Param注解執行時機在wrapCollection處理之前，wrapCollection對集合的特殊處理將springframework包下的@Param注解處理覆蓋掉了，所以無法解析參數set。而mybatis包下的@Param注解執行時機在wrapCollection處理之后，程序可以正常運行。

01、引言

大家好，我是了不起，前一段時間在工作中因為一個疏忽踩了一個坑，最終通過異常棧追溯源碼解決了問題。

下面我來給大家還原一下案發現場，并介紹一下自己的解決思路，希望能對大家有所啟發。

02、案發現場

當時的業務邏輯主要通過 Mybatis 框架來修改數據，具體示例如下：

import org.springframework.data.repository.query.Param;

public interface GroupMapper {
 
 int updateGroup(@Param("oldSerial") Set<Integer> oldSerial, @Param("newSerial") int newSerial);

 int invalidGroup(@Param("set") Set<Integer> set);
}

<update id="updateGroup">
    update groupCode_table_use
    set groupCode=#{newSerial}
    where groupCode in
    <foreach collection="oldSerial" close=")" open="(" item="item" separator=",">
        #{item}
    </foreach>
</update>

<update id="invalidGroup">
    update groupCode_table
    set status='無效'
    where groupCode in
    <foreach collection="set" close=")" open="(" item="item" separator=",">
        #{item}
    </foreach>
</update>

本以為 so easy 的代碼，出現意外了！第一個sql語句updateGroup正常運行，第二個sql語句invalidGroup竟然報錯了？？？

報錯信息如下：

圖片

從日志上可以看出，提示set參數找不到！

明明使用了@Param("set")將參數命名為set為何找不到，完全不符合多年開發的認知。

更加詭異的是updateGroup已使用了同樣的方式去遍歷，完全沒得問題，那么問題出現在了哪了？

小伙伴可以先猜一猜！

03、原因分析

百思不得其解下，我掏出了祖傳絕活 debug 源碼，最終發現原來是Mybatis對集合Set進行了特殊處理。

案發項目引入的Mybatis版本是 3.5.1。部分源碼如下！

org.apache.ibatis.session.defaults.DefaultSqlSession.java

@Override
public int update(String statement, Object parameter) {
  try {
    dirty = true;
    MappedStatement ms = configuration.getMappedStatement(statement);
    //調用了wrapCollection方法對參數進行了處理
    return executor.update(ms, wrapCollection(parameter));
  } catch (Exception e) {
    throw ExceptionFactory.wrapException("Error updating database.  Cause: " + e, e);
  } finally {
    ErrorContext.instance().reset();
  }
}

/**
* 如果參數實現了Collection接口或是數組類型 wrapCollection方法會對參數進行封裝
* 如果參數實現了Collection接口會封裝為含collection鍵的Map
*     如果參數又實現了List接口會封裝為含list鍵的Map(追增)
*     對Set集合沒有特殊處理
* 如果參數是數組類型會封裝為含array鍵的Map
*/
private Object wrapCollection(final Object object) {
  if (object instanceof Collection) {
    StrictMap<Object> map = new StrictMap<>();
    map.put("collection", object);
    if (object instanceof List) {
      map.put("list", object);
    }
    return map;
  } else if (object != null && object.getClass().isArray()) {
    StrictMap<Object> map = new StrictMap<>();
    map.put("array", object);
    return map;
  }
  return object;
}

通過以上的源碼分析，發現Mybatis框架對集合參數進行了特殊處理。

這就是為什么報錯信息中提示Available parameters are [collection]。

找到了collection錯誤信息從哪里來問題，接下來我們分析一下set參數到了哪里去。

首先updateGroup可以正常執行是因為源碼中對集合的特殊處理只對單參數生效，也就是說@Param("set")注解失效是因為被Mybatis自家的特殊處理給覆蓋了？

這不合乎常理啊，那么問題可能出在@Param注解身上，通過排查代碼發現GroupMapper.java類引用的@Param注解不對！

// 代碼引入的注解類Param
import org.springframework.data.repository.query.Param;
// 期望的注解類，應該由mybatis提供
import org.apache.ibatis.annotations.Param;

實際上，springframework包下的@Param注解執行時機在wrapCollection處理之前，wrapCollection對集合的特殊處理將springframework包下的@Param注解處理覆蓋掉了，所以無法解析參數set。而mybatis包下的@Param注解執行時機在wrapCollection處理之后，程序可以正常運行。

最終確定，繞了這么大一圈，原來是包導入錯了，誰能想到springframework包下還有一個@Param注解，在多參數的情況下竟然可以正常使用o(╥﹏╥)o。

04、異常棧分析法

整個異常排查過程中，主要通過分析異常棧信息進行快速定位。下面我給大家介紹一下異常棧分析法。

我們在工作中查看異常棧，往往都是業務代碼異常導致的，這個時候我們只需要關心是在我們編寫的哪段代碼中出了問題。

而這時好用的idea也會為溫馨的為我們做出提示，會在異常棧中將我們編寫的方法位置信息標藍處理，這樣我們就定快速定位出現問題的代碼。

圖片

但是一旦是底層引用的jar包出現了異常，僅僅是這樣查看異常棧是不夠的。下面我們就以上面案例中的異常棧來帶大家分析。

當前異常：

圖片

原始異常：

圖片

分析流程：

異常調用棧順序:從上至下為方法調用順序的逆序，異常由異常棧的最上面的方法拋出，整個調用的入口在最下方。
尋找原始異常入口技巧：檢索異常棧中與原始異常入口（最下面）拋出位置同名的方法。
尋找真正異常出現的位置，要找最后一個 Caused by 的第一行棧幀。

"Caused by" 是 Java 異常處理機制中的一部分，它表示當前異常是由另一個異常引起的。在 Java 中，每個 Throwable 對象都可以通過 getCause() 方法獲取到原始異常，這個原始異常就是通過 "Caused by" 打印出來的。

異常棧示例代碼：

假設你在catch塊中捕獲了一個異常，并重新拋出了一個新的異常，同時保留了原始異常的信息：

public class Example {
    public static void main(String[] args) {
        try {
            methodThatThrowsException();
        } catch (Exception e) {
            throw new RuntimeException("Caught an exception", e);
        }
    }

    public static void methodThatThrowsException() throws Exception {
        throw new Exception("Original exception");
    }
}

當你運行上述代碼時，控制臺輸出的異常棧信息通常會包含Caused by信息：

java.lang.RuntimeException: Caught an exception
    at Example.main(Example.java:7)
Caused by: java.lang.Exception: Original exception
    at Example.methodThatThrowsException(Example.java:12)
    at Example.main(Example.java:5)

java.lang.Exception: Original exception 是原始異常。
java.lang.RuntimeException: Caught an exception 是新拋出的異常，并且包含了原始異常作為其原因。
Caused by 信息顯示了原始異常的詳細信息，這有助于調試和理解異常的來源。

如何保留原始異常信息呢？

方式一：直接傳遞原始異常：

try {
     methodThatThrowsException();
 } catch (Exception e) {
     throw new RuntimeException("Caught an exception", e);
 }

方式二：使用 addSuppressed 方法：

try {
     methodThatThrowsException();
 } catch (Exception e) {
     RuntimeException newException = new RuntimeException("Caught an exception");
     newException.addSuppressed(e);
     throw newException;
 }

05、結語

學會查看分析異常棧，可以為我們工作大大提高效率，希望這篇文章給大家帶來收獲，最后再送給大家一個小技巧。異常棧不僅僅可以用來排查異常哦，還可以幫助大家學習源碼，debug 源碼找不到入口怎么辦，那就創造一個異常！

責任編輯：武曉燕來源： Java極客技術

Mybatis 異常棧程序