一個排查了大半天兒的問題，差點又讓 MyBatis 背鍋-有解無憂

我是風箏，公眾號「古時的風箏」，一個不只有技術的技術公眾號，一個在程式圈混跡多年，主業 Java，另外 Python、React 也玩兒的 6 的斜杠開發者，
Spring Cloud 系列文章已經完成，可以到我的github 上查看系列完整內容，也可以在公眾號內回復「pdf」獲取我精心制作的 pdf 版完整教程，

寫代碼多年，我一直有個習慣，只要是要做的功能模塊不是很復雜，一般都是上來狂寫一通代碼，等功能做好了，再啟動服務測驗，哪里有問題再改（實話說，單元測驗寫的也不多），而不是寫完一個介面或方法就測驗一下，最長的記錄應該是連著寫4、5天代碼，然后一把測驗通過，那感覺，爽到可以多吃一碗飯，

代碼路上的滑鐵盧

然而，就在前兩天，我感覺遭遇到了代碼人生的滑鐵盧，其實遇到過不只一次了，每次滑完鐵，再爬起來慢慢就忘了，這次，我把它寫下來，這樣就不會忘了，

事情是這樣的，前兩天要對專案加個功能，專案 ORM 采用的是 MyBatis，因為增加了資料庫表，所以要對應的生成 DAO 層和 MyBatis 映射檔案(mapper.xml)，由于對之前業務不是熟悉，我只是先把各個物體類啊、業務類啊、映射檔案啊、列舉類啊等等都建出來，然后寫了兩個簡單介面準備除錯一下，于是我點了啟動按鈕，沒問題，沒有一點錯誤，專案正常啟動了，看上去是那么的完美，

我構造了一個請求，打算測一下剛剛寫好的介面，當請求發送出去之后，一個熟悉的例外出現在了 IDEA 控制臺中，invalid bound statement (not found)，用過 MyBatis 的同學恐怕沒有不認識這個例外的，它的意思就是我們呼叫 DAO 方法的時候，在 mapper.xml 檔案中沒有找到對應的 statement，或者說是沒有找到你定義的 SQL 查詢陳述句塊，

出現這個例外可能是下面的這幾個原因：

xml 檔案的 namespace 和對應的介面名不一致
介面類中的方法和 xml 檔案中的 statement id 對應不上
xml 檔案中有中文注釋
隨意在 xml 檔案中加一個空格或者空行然后保存，可能能解決問題

如果你是用工具自動生成 xml 還好，如果是手動創建的，那很可能由于疏忽出現這個問題，比如我們從另一個檔案復制過來，忘記改 namespace 了，或者介面方法名和 statement id 差了一個字母或者字母順序不一致，這個例外是很令人頭疼的，就比如相差一個字母這種情況，很難被發現，所以最好還是寫好介面方法名，然后復制到 xml 中，

我雖然有段時間沒有碰 MyBatis 了，作為一個老司機，我碰到這個問題其實一點也不慌，因為雖然是工具自動生成的 xml 檔案，但是我確實又加了幾個 statement 塊兒，而且 id 也是手敲的，并且報錯的確實也是我手動加上的，所以，我猜測應該是名字沒對上，敲錯字母或者順序不一致，于是我進去排查了一下，但是沒發現什么問題，為了保險起見，我又到介面中把方法名字復制到 xml 中了，然后確定 namespace 沒問題，沒有中文注釋，并且又在 xml 中加了個空行(雖然從來沒用這個方法解決過問題)，然后重新啟動專案，但是，例外還是沒有消失，

及時跳出來，不要陷在里面

這就有點奇怪了，又重新檢查了一遍，沒錯，都正常，看不出問題所在，當確定沒有問題的時候，就要跳出來了，得從其他方向或者更高層次考慮一下了，不然很可能就陷在里面了，劃重點，這是多次教訓總結出來的規律，我可以確定當前呼叫的這個介面方法和 statement 都完全沒有問題，那很有可能是別的問題，會不會是這個 xml 檔案沒有被編譯打包進去，于是我進到 target 目錄查探一番，有的，而且查看內容，確定是沒有問題的，

有時候問題很奇怪，可能和 IDE 有關，于是我用 mvn clean 命令清理了一下，然后重新運行，但是，問題依舊在，

接下來，我又試了洗掉這個 xml ，然后新建了一個，但是，問題依舊，

再往外跳，你不是這個方法有問題嗎，那我再新建一個方法，就寫一條最簡單的 SQL，方法名也起的簡單一點，看看會不會有問題，結果，發現新大陸了，這個新建的方法也報這個錯誤，那就有了新的排查方向了，我再試試別的介面中的方法呢，結果，這個包名下的幾個方法，全都有這個錯誤，而其他包名下的方法則沒有問題，因為不同功能的 xml 檔案放在不同的包下，也就是不同的路徑下，

那我就知道了，是 xml 檔案掃描出問題了，肯定是 MyBatis 配置的 mapperLocations 有問題了，有可能是被我或者其他同事不小心多敲了個字母之類的，于是打開組態檔看了一下，

mybatis:
  mapperLocations: com/xxx/aaa/mapper/*.xml,com/xxx/aaa/bbb/mapper/*.xml,com/xxx/aaa/ccc/mapper/*.xml

MyBatis 配置 mapperLocations 配置了三個包路徑，也就是從這三個包中尋找 *.xml去決議，但是經過檢查發現，并沒有問題，組態檔沒有 git 提交記錄，而且配置的包路徑也是正確無誤的，其他兩個包都掃描正常，就是 com/xxx/aaa/ccc/mapper/*.xml這個包有問題，于是我又試了如下幾個方法：

把這個有問題的包路徑放到第一個，無效，
把其他兩個注釋，只留這個有問題的，無效，
難道是 MyBatis 讀取了其他地方的配置？于是我把這個配置注釋掉，結果都出問題了，說明就是讀的這個配置，

原始碼大法好

此時，已經過去很長時間了，問題變的越來越詭異，但是事出必有因，肯定是某些地方出現了問題，實在找不出專案本身的問題了，沒辦法，我只能懷疑是 MyBatis 有問題了，也許真的是觸發了 MyBatis 本身的隱藏 bug，

不到萬不得已是不會用這種方式的，那就是除錯 MyBatis 原始碼，想來，MyBatis 原始碼我還是比較熟悉的，那咱們就再會一會吧，

mybatis-spring-boot-starter 只有三個 Java 檔案，其中 MybatisAutoConfiguration是關鍵業務類，

而我們知道 MyBatis 中 SqlSessionFactory 是非常核心的物件，所以我們就把斷點加在 sqlSessionFactory(DataSource dataSource)這個方法上，

如果是第一次除錯開源框架原始碼，往往不能一下子找準位置，其實沒有關系，把斷點打在任何一個位置都可以，大不了就慢慢跟兩遍嘛，本身讀原始碼、除錯的程序就是個漫長的程序，

@Bean
@ConditionalOnMissingBean
public SqlSessionFactory sqlSessionFactory(DataSource dataSource) throws Exception {
    SqlSessionFactoryBean factory = new SqlSessionFactoryBean();
    factory.setDataSource(dataSource);
  	// 省略...
    if (!ObjectUtils.isEmpty(this.properties.resolveMapperLocations())) {
      factory.setMapperLocations(this.properties.resolveMapperLocations());
    }
    return factory.getObject();
}

以上代碼我只保留了本次問題相關的代碼，那就是決議 mapperLocations 的程序，也就是上面代碼中this.properties.resolveMapperLocations()這個方法，

public Resource[] resolveMapperLocations() {
    ResourcePatternResolver resourceResolver = new PathMatchingResourcePatternResolver();
    List<Resource> resources = new ArrayList<Resource>();
    if (this.mapperLocations != null) {
      for (String mapperLocation : this.mapperLocations) {
        try {
          Resource[] mappers = resourceResolver.getResources(mapperLocation);
          resources.addAll(Arrays.asList(mappers));
        } catch (IOException e) {
          // ignore
        }
      }
    }
    return resources.toArray(new Resource[resources.size()]);
}

當我繼續跟蹤代碼的時候，發現 MyBatis 確實已經識別到了組態檔中的那三個包路徑，this.mapperLocations就是那三個包路徑的陣列集合，

接著往下跟，在方法 resourceResolver.getResources(mapperLocation)中對每一個路徑進行決議，發現前兩個包都正常回傳了Resource[]，也就是對應的 xml 檔案資源，而最后一個回傳的確實空陣列，問題原因已經很近了，

接著再次啟動除錯，當決議最后一個包路徑是，進入resourceResolver.getResources(mapperLocation)方法內部，看看里面都干了什么，最后發現在呼叫以下代碼之后，回傳的 rootDirURL 是一個絕對路徑，也就是 xml 所在的物理路徑，

URL rootDirURL = rootDirResource.getURL();

這時，終于發現問題所在了，這個絕對路徑竟然不是 xml 所在的路徑，而是另外一個子模塊下的路徑，經過對比發現，原來，子模塊中被新建了一個名稱一樣的檔案夾，造成存在兩個完全一樣的包路徑，而以上代碼回傳了另一個包的絕對路徑，于是，聯系同事，問清楚這個包被創建的原因，發現是最近新加的但是已經廢棄無用的，于是刪掉解決了問題，

正常專案開發中應該可以規避這種問題，模塊與模塊不應該出現相同包名，應該遵循如下命名：

模塊A：com.kite.moduleA

模塊B: com.kite.moduleB

這樣從根本上解決問題，以防出現不必要的麻煩，

最后

MyBatis 的這個例外確實令人頭疼，因為錯誤原因不明顯，以此類推，凡是 xml 檔案造成的問題都不太容易排查，大部分情況都是人為疏忽造成的，而錯誤一般都比較隱蔽，

當一個問題經過多方驗證都沒辦法被發現被解決的時候，往往就需要換個思路了，及時跳出來，從其它角度或者更高層次重新審視問題，也許能更快的找到問題原因，

在用開源框架的時候，如果出現問題，長時間找不到解決辦法，那么可以嘗試除錯一下原始碼，并沒有想象的那么困難，

壯士且慢，先給點個贊吧，總是被白嫖，身體吃不消！

我是風箏，公眾號「古時的風箏」，一個在程式圈混跡多年，主業 Java，另外 Python、React 也玩兒的很 6 的斜杠開發者，可以在公眾號中加我好友，進群里小伙伴交流學習，好多大廠的同學也在群內呦，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/190794.html

標籤：Java

上一篇：真香警告！擴展 swagger支持檔案自動列舉所有列舉值

下一篇：Spring MVC 函式式編程進階