引言

我們在使用mybatis時，如果出現(xiàn)sql問題，一般會把mybatis配置文件中的logging.level參數(shù)改成debug，這樣就能在日志中看到某個mapper最終執(zhí)行sql、入?yún)⒑陀绊憯?shù)據(jù)行數(shù)。我們拿到sql和入?yún)?，手動拼接成完整的sql，然后將該sql在數(shù)據(jù)庫中執(zhí)行一下，就基本能定位到問題原因。mybatis的日志功能使用起來還是非常方便的，大家有沒有想過它是如何設計的呢？

從logging目錄開始

我們先看一下mybatis的logging目錄，該目錄的功能決定了mybatis使用什么日志工具打印日志。

logging目錄結構如下：

它里面除了jdbc目錄，還包含了7個子目錄，每一個子目錄代表一種日志打印工具，目前支持6種日志打印工具和1種非日志打印工具。我們用一張圖來總結一下

除了上面的8種日志工具之外，它還抽象出一個Log接口，所有的日志打印工具必須實現(xiàn)該接口，后面可以面向接口編程。定義了LogException異常，該異常是日志功能的專屬異常，如果你有看過mybatis其他源碼的話，不難發(fā)現(xiàn)，其他功能也定義專屬異常，比如：DataSourceException等，這是mybatis的慣用手法，主要是為了將異常細粒度的劃分，以便更快定位問題。此外，它還定義了LogFactory日志工廠，以便于屏蔽日志工具實例的創(chuàng)建細節(jié)，讓用戶使用起來更簡單。

如果是你該如何設計這個功能？

我們按照上面目錄結構的介紹其實已經有一些思路：

1. 定義一個 Log接口，以便于統(tǒng)一抽象日志功能，這8種日志功能都實現(xiàn) Log接口，并且重寫日志打印方法。
2. 定義一個 LogFactory日志工廠，它會根據(jù)我們項目中引入的某個日志打印工具jar包，創(chuàng)建一個具體的日志打印工具實例。

看起來，不錯。但是，再仔細想想，LogFactory中如何判斷項目中引入了某個日志打印工具jar包才創(chuàng)建相應的實例呢？我們第一個想到的可能是用if...else判斷不就行了，再想想感覺用if...else不好，7種條件判斷太多了，并非優(yōu)雅的編程。這時候，你會想一些避免太長if...else判斷的方法，當然如果你看過我之前寫的文章《實戰(zhàn)|如何消除又臭又長的if...else判斷更優(yōu)雅的編程？》，可能已經學到了幾招，但是mybatis卻用了一個新的辦法。

mybatis是如何設計這個功能的？

1. 從 Log接口開始

它里面抽象了日志打印的5種方法和2種判斷方法。

2. 再分析 LogFactory的代碼

它里面定義了一個靜態(tài)的構造器logConstructor，沒有用if...else判斷，在static代碼塊中調用了6個tryImplementation方法，該方法會啟動一個執(zhí)行任務去調用了useXXXLogging方法，創(chuàng)建日志打印工具實例。

當然tryImplementation方法在執(zhí)行前會判斷構造器logConstructor為空才允許執(zhí)行任務中的run方法。下一步看看useXXXLogging方法：看到這里，聰明的你可能會有這樣的疑問，從上圖可以看出mybatis定義了8種useXXXLogging方法，但是在前面的static靜態(tài)代碼塊中卻只調用了6種，這是為什么？

對比后發(fā)現(xiàn)：useCustomLogging 和 useStdOutLogging 前面是沒調用的。useStdOutLogging它里面使用了StdOutImpl類

該類其實就是通過JDK自帶的System類的方法打印日志的，無需引入額外的jar包，所以不參與static代碼塊中的判斷。

而useCustomLogging方法需要傳入一個實現(xiàn)了Log接口的類，如果mybatis默認提供的6種日志打印工具不滿足要求，以便于用戶自己擴展。

而這個方法是在Configuration類中調用的，如果用戶有自定義logImpl參數(shù)的話。

具體是在XMLConfigBuilder類的settingsElement方法中調用

再回到前面LogFactory的setImplementation方法

它會先找到實現(xiàn)了Log接口的類的構造器，返回將該構造器賦值給全局的logConstructor。

這樣一來，就可以通過getLog方法獲取到Log實例。

然后在業(yè)務代碼中通過下面這種方式獲取Log對象，調用它的方法打印日志了。

梳理一下LogFactory的流程：

• 在static代碼塊中根據(jù)逐個引入日志打印工具jar包中的日志類，先判斷如果全局變量logConstructor為空，則加載并獲取相應的構造器，如果可以獲取到則賦值給全局變量logConstructor。
• 如果全局變量logConstructor不為空，則不繼續(xù)獲取構造器。
• 根據(jù)getLog方法獲取Log實例
• 通過Log實例的具體日志方法打印日志

在這里還分享一個知識點，如果某個工具類里面都是靜態(tài)方法，那么要把該工具類的構造方法定義成private的，防止被疑問調用，LogFactory就是這么做的。

3. 適配器模式

日志模塊除了使用工廠模式之外，還是有了適配器模式。

適配器模式會將所需要適配的類轉換成調用者能夠使用的目標接口

涉及以下幾個角色：

• 目標接口（ Target ）
• 需要適配的類（ Adaptee ）
• 適配器（ Adapter)

mybatis是怎么用適配器模式的?

上圖中標紅的類對應的是Adapter角色，Log是Target角色。

而LogFactory就是Adaptee，它里面的getLog方法里面包含是需要適配的對象。

sql執(zhí)行日志打印原理

從上面已經能夠確定使用哪種日志打印工具，但在sql執(zhí)行的過程中是如何打印日志的呢？這就需要進一步分析logging目錄下的jdbc目錄了。

看看這幾個類的關系圖：

ConnectionLogger、PreparedStatementLogger、ResultSetLogger和StatementLogger都繼承了BaseJdbcLogger類，并且實現(xiàn)了InvocationHandler接口。從類名非常直觀的看出，這4種類對應的數(shù)據(jù)庫jdbc功能。

它們實現(xiàn)了InvocationHandler接口意味著它用到了動態(tài)代理，真正起作用的是invoke方法，我們以ConnectionLogger為例：

如果調用了prepareStatement方法，則會打印debug日志。

上圖中傳入的original參數(shù)里面包含了\n\t等分隔符，需要將分隔符替換成空格，拼接成一行sql。

最終會在日志中打印sql、入?yún)⒑陀绊懶袛?shù)：

上圖中的sql語句是在ConnectionLogger類中打印的

那么入?yún)⒑陀绊懶袛?shù)呢？

入?yún)⒃赑reparedStatementLogger類中打印的

影響行數(shù)在ResultSetLogger類中打印的

彩蛋

不知道大家有沒有發(fā)現(xiàn)這樣一個問題：

在LogFactory的代碼中定義了很多匿名的任務執(zhí)行器

但是在實際調用時，卻沒有在線程中執(zhí)行，而是直接調用的，這是為什么？

答案是為了保證順序執(zhí)行，如果所有的日志工具jar包都有，加載優(yōu)先級是：slf4j 》commonsLog 》log4j2 》log4j 》jdkLog 》NoLog

還有個問題，順序執(zhí)行就可以了，為什么要把匿名內部類定義成Runnable的呢？

這里非常有迷惑性，因為它沒創(chuàng)建Thread類，并不會多線程執(zhí)行。我個人認為，這里是mybatis的開發(fā)者的一種偷懶，不然需要定義一個新類代替這種執(zhí)行任務的含義，還不如就用已有的。

特別推薦一個分享架構+算法的優(yōu)質內容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝