### SqlSession簡介 Mybatis是一個強大的ORM框架，它通過接口式編程為開發者屏蔽了傳統JDBC的諸多不便，以簡單的方式提供強大的擴展能力。其中的接口式編程就是指日常使用的Mapper接口，Mybatis借助動態代理實現了sql語句與Mapper的接口的動態綁定，降低復雜度的同時為開發人員提供強大自主權。 經過上一篇文章《Mybatis源碼之SQL執行過程》已經知道，Mapper其實是Mybatis暴露給開發人員的擴展能力，在運行時Mybatis把Mapper接口轉為動態方法，最終也會轉交給SqlSession的CRUD方法執行。所以，SqlSession是Mybatis框架真正意義上的命令執行入口。 SqlSession是Mybatis中最基礎的一個接口類，它代表一個與數據庫的會話，在其生命周期內完成與數據庫的交互，通過它可以： * 執行基本的SQL命令（select/update/insert/delete）：SQL命令具有唯一ID，每個ID對應Configration中的一個MappedStatement。 * 獲取自定義的Mapper接口對象（getMapper）：使用動態代理技術動態生成Mapper接口實現類，由MapperProxy代理實現。 * 控制管理事務操作（rollback/commit）：數據庫事務操作中提交與回滾操作。  以上類圖為SqlSession等Mybatis接口層的繼承體系與關系，由上圖可知： * SqlSessionFactory負責SqlSession的創建工作，其默認實現為DefaultSqlSessionFactory。 * SqlSession有兩個實現類：DefaultSqlSession和SqlSessionManager，其中DefaultSqlSession為默認實現；SqlSessionManager除了實現SqlSession接口外，還實現了SqlSessionFactory接口。 接下來，我們通過實例和源碼來詳細了解下DefaultSqlSession和SqlSessionManager兩者的特點與差別，進一步加深對它的理解。 ### DefaultSqlSession DefaultSqlSession是SqlSession的默認實現，它純粹是一個功能類，完全實現了SqlSession的接口方法，但是它并不具備自主管理能力。在開始之前，我們先了解兩個問題： * DefaultSqlSession是非線程安全的，因此需要避免多線程并發使用，隨用隨取，及時釋放； * DefaultSqlSession它不具有自動關閉的能力，需要開發者自主調用關閉方法。 下面這個示例代碼還是跟之前一樣，我們重點關注第7-9行，其實只有兩行代碼。 ~~~java public static void main(String[] args) throws IOException { // mybatis配置文件 String path = "mybatis-config.xml"; InputStream inputStream = Resources.getResourceAsStream(path); // 獲取 SqlSessionFactory SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); // 創建 SqlSession try (SqlSession sqlSession = sqlSessionFactory.openSession()) { // …… } } 復制代碼 ~~~ 第7行：主要完成配置文件解析并保存到Configuration，由SqlSessionFactoryBuilder創建SqlSessionFactory對象，為創建SqlSession做準備。 第9行：采用“try-with-resource”方式調用SqlSessionFactory#openSession方法創建了SqlSession對象。當代碼離開try代碼塊時會自動關閉SqlSession，但是這里的自動關閉并不是SqlSession的能力，相當于手動調用了SqlSession#close方法。看下openSession的實現： ~~~java public SqlSession openSession() { return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, false); } private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) { Transaction tx = null; try { //獲取環境配置信息 final Environment environment = configuration.getEnvironment(); //創建事務處理器 final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment); tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit); //創建Executor，這里默認使用CachingExecutor final Executor executor = configuration.newExecutor(tx, execType); //創建SqlSession，默認實例DefaultSqlSession return new DefaultSqlSession(configuration, executor, autoCommit); } catch (Exception e) { closeTransaction(tx); // may have fetched a connection so lets call close() throw ExceptionFactory.wrapException("Error opening session. Cause: " + e, e); } finally { ErrorContext.instance().reset(); } } 復制代碼 ~~~ 由此可知，openSessionFromDataSource方法完成了SqlSession的創建，它返回了DefaultSqlSession對象。DefaultSqlSession中聚合了Configuration、Executor等對象。 #### selectXxx方法 以selectList為例看下selectXxx方法的執行過程： ~~~java public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) { try { //statement為MappedStatement的唯一id，注冊在Configuration#mappedStatements //根據id獲取MappedStatement MappedStatement ms = configuration.getMappedStatement(statement); //調用執行器的query方法執行查詢命令。 return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER); } catch (Exception e) { throw ExceptionFactory.wrapException("Error querying database. Cause: " + e, e); } finally { ErrorContext.instance().reset(); } } 復制代碼 ~~~ SqlSession中selectXxx方法，最終都走到了selectList方法，但是它并沒有直接與數據庫交互，獲取MappedStatement對象后調用了執行器Executor的query方法。 #### insert方法 insert對應sql的insert命令，代碼如下： ~~~java public int insert(String statement) { return insert(statement, null); } public int insert(String statement, Object parameter) { return update(statement, parameter); } public int update(String statement, Object parameter) { try { dirty = true; MappedStatement ms = configuration.getMappedStatement(statement); return executor.update(ms, wrapCollection(parameter)); } catch (Exception e) { throw ExceptionFactory.wrapException("Error updating database. Cause: " + e, e); } finally { ErrorContext.instance().reset(); } } 復制代碼 ~~~ 與select類似，首先獲取MappedStatement，然后調用了執行器的update方法。整體流程比較簡單，有一點需要說明的是：對于數據庫而言，insert/update/delete其實都是更新操作，所以這里雖然是insert方法入口，但是實際調用了Executor#update方法。 #### delete方法/update方法 delete/update方法的執行過程與insert基本是一樣的，不再贅述。 #### 小結 DefaultSqlSession是SqlSession的默認實現，提供了數據庫的CURD能力，但是它并沒有直接與數據庫交互，而是調用了Executor的相關方法，是一個名副其實的“甩手掌柜”。 在selectXxx或insert方法中，我們并沒有發現它調用close方法，所以它不具備自動關閉的能力，需要我們開發者手動調用，比如示例中的“try-with-resource”方式。 回過頭來說下“線程安全”：通過上述示例和源碼，我們會發現一旦DefaultSqlSession對象被創建，任何獲取到它的線程都可以訪問其方法，CURD或者close，多個線程同時操作就會導致不可預知的結果。所以，我們不能把它直接設置為公共實例，應該即用即取，及時釋放。 ### SqlSessionManager 看完DefaultSqlSession，繼續看下SqlSessionManager。由上述類圖可知，它實現了SqlSession和SqlSessionFactory兩個接口，同時具備SqlSession接口能力及SqlSession對象創建能力。 仔細觀察類圖會發現，SqlSessionManager內部還聚合了一個SqlSessionFactory和SqlSession對象，什么情況？實現了這兩個接口，卻又聚合了這兩個接口的實例，難道它只是個代理，就是包了一層？源碼走走看！ ~~~java public class SqlSessionMgrDemo { public static void main(String[] args) throws IOException { // mybatis配置文件 String path = "mybatis-config.xml"; InputStream inputStream = Resources.getResourceAsStream(path); // 獲取 SqlSessionManager SqlSessionManager sqlSessionManager = SqlSessionManager.newInstance(inputStream); // 開啟對session的管理：沒有這行代碼也可以使用 sqlSessionManager.startManagedSession(); // 獲取mapper CompanyDao dao = sqlSessionManager.getMapper(CompanyDao.class); // 執行查詢 CompanyDO companyDO = dao.selectById(1); System.out.println(companyDO); } } 復制代碼 ~~~ 簡單說下這段代碼的執行流程： * 4～5行：加載并讀取配置文件； * 7行：創建SqlSessionManager實例； * 9行：開啟對SqlSession的管理，通過它可以實現對SqlSession的線程安全管理，使SqlSessionManager實例可共享（這個與DefaultSqlSession有差別）； * 11～14行：執行查詢； #### 實例化 通過示例代碼可知，SqlSessionManager#newInstance創建了SqlSessionManager對象，看下執行過程，我們仔細看看SqlSessionManager到底是個什么東東。 ~~~java // 創建 SqlSessionManager public static SqlSessionManager newInstance(InputStream inputStream) { return new SqlSessionManager(new SqlSessionFactoryBuilder().build(inputStream, null, null)); } // 構造方法，這里入參為DefaultSqlSessionFactory實例 private SqlSessionManager(SqlSessionFactory sqlSessionFactory) { this.sqlSessionFactory = sqlSessionFactory; // 通過動態代理，創建SqlSession實例 this.sqlSessionProxy = (SqlSession) Proxy.newProxyInstance( SqlSessionFactory.class.getClassLoader(), new Class[]{SqlSession.class}, new SqlSessionInterceptor()); } // SqlSessionFactory實例 private final SqlSessionFactory sqlSessionFactory; // SqlSession 代理對象 private final SqlSession sqlSessionProxy; 復制代碼 ~~~ newInstance方法調用了SqlSessionManager的私有構造方法（僅有私有構造方法），構造方法的入參是SqlSessionFactory（與DefaultSqlSession的實現一致），這里是其默認實現DefaultSqlSessionFactory。 構造方法內通過動態代理創建對象sqlSessionProxy，它是SqlSession的動態實現，這里需要重點關注SqlSessionInterceptor這個類。從名稱看它是一個攔截器，也就是說當我們調用SqlSession的方法時，會被它攔截，看下SqlSessionInterceptor#invoke方法： ~~~java private class SqlSessionInterceptor implements InvocationHandler { public SqlSessionInterceptor() { // Prevent Synthetic Access } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 判斷本地線程是否有sqlSession final SqlSession sqlSession = SqlSessionManager.this.localSqlSession.get(); // 如果有，直接使用，無需創建 if (sqlSession != null) { try { // 調用SqlSession接口方法實現 return method.invoke(sqlSession, args); } catch (Throwable t) { throw ExceptionUtil.unwrapThrowable(t); } } else { // 如果沒有，通過openSession創建，openSession方法返回的是DefaultSqlSession實例 //這里使用try-with-resource，使用完成會自動關閉 try (SqlSession autoSqlSession = openSession()) { try { // 調用SqlSession接口方法實現 final Object result = method.invoke(autoSqlSession, args); //事務提交 autoSqlSession.commit(); return result; } catch (Throwable t) { //事務回滾 autoSqlSession.rollback(); throw ExceptionUtil.unwrapThrowable(t); } } } } } 復制代碼 ~~~ SqlSessionInterceptor#invoke首先會從localSqlSession獲取SqlSession對象，localSqlSession是什么呢？這里只提到get，那set在哪里？從代碼里面找下吧： ~~~java //localSqlSession是一個ThreadLocal對象，用來存儲SqlSession //這是一個線程安全的標志 private final ThreadLocal<SqlSession> localSqlSession = new ThreadLocal<>(); //開啟對SqlSession的管理，我們示例代碼有調用 public void startManagedSession() { //為localSqlSession賦值，參數為openSession返回值 this.localSqlSession.set(openSession()); } public SqlSession openSession() { //與之前一樣，它返回的是DefaultSqlSession對象 return sqlSessionFactory.openSession(); } 復制代碼 ~~~ localSqlSession是一個ThreadLocal對象，用來存儲SqlSession，它用來在線程內共享對象，很明顯的線程安全處理方式。localSqlSession是在startManagedSession及其重載方法中設置的，通過openSession方法可知，localSqlSession內部存放的是DefaultSqlSession對象。 繼續SqlSessionInterceptor#invoke分析，根據localSqlSession中是否存有sqlSession，有兩個不同的處理方式： * 有：如果有，則直接使用，不再新建。這里只能是在同一線程內共享，避免了重復創建對象的額外開銷。 * 無：如果沒有，就與我們DefaultSqlSession一節中的使用方式一樣，使用了“try-with-resource”方式，實現了SqlSession的自動關閉。 **SqlSessionManager持有的SqlSessionFactory引用為DefaultSqlSessionFactory，作用自然是創建SqlSession實例；SqlSessionFactory創建的SqlSession是DefaultSqlSession實例；但是SqlSessionManager內部通過動態代理模式使用SqlSessionInterceptor對DefaultSqlSession進行了攔截，在攔截處理中有兩種邏輯：一是使用ThreadLocal對SqlSession進行了線程安全共享；二是實現了對SqlSession的自動關閉。由此可見：SqlSessionManager是DefaultSqlSession的加強版，或者說是一個高級封裝。** #### SqlSession接口實現 SqlSessionManager對SqlSession接口的實現全部轉交給其內部的sqlSessionProxy代理對象完成，沒有什么處理邏輯，貼幾個方法看下： ~~~java public void select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler) { sqlSessionProxy.select(statement, parameter, rowBounds, handler); } public int insert(String statement) { return sqlSessionProxy.insert(statement); } public int update(String statement) { return sqlSessionProxy.update(statement); } public int delete(String statement) { return sqlSessionProxy.delete(statement); } 復制代碼 ~~~ sqlSessionProxy其實是一個包裝了DefaultSqlSession的SqlSessionInterceptor實例，所有方法會被SqlSessionInterceptor#invoke攔截，最終是由DefaultSqlSession來實現的（就是前面一節說的內容）。 前面“實例化”一節說invoke內有兩種邏輯，那實際會走哪種邏輯呢？實際上，這引出了SqlSessionManager的兩種使用方式，使用方式不同invoke的執行邏輯也不同。 * 一是：像使用DefaultSqlSession一樣，按需創建，此時SqlSessionManager提供了自動關閉功能。 * 二是：啟用SqlSession管理功能。此時SqlSessionManager會在同一線程內共享SqlSession，它是線程安全的。 小伙伴兒們可以嘗試把示例代碼中第9行關閉或打開注釋作下調試，一試便知。 #### 小結 SqlSessionManager雖然同時實現了SqlSession和SqlSessionFactory兩個接口，但是真正“干活”的還是DefaultSqlSession和DefaultSqlSessionFactory；它使用動態代理對SqlSession的方法進行攔截，提供了SqlSession自動關閉或線程安全的解決方案。整體上看，SqlSessionManager是對安全、智能、高級封裝版的DefaultSqlSession。 ### SqlSession總結 本文“啰里八嗦”的介紹了DefaultSqlSession和SqlSessionManager兩者的區別與聯系，重點關注了SqlSessionManager如何解決線程安全和自動關閉兩個問題，從源碼層面了解到SqlSessionManager其實是對DefaultSqlSession的高級封裝。 我們還了解到，所有的SQL命令都會從SqlSession開始，然而SqlSession并沒有直接操作數據庫，臟活累活都交給了Executor，形象點說SqlSession其實是一個“包工頭兒”。具體Executor如何做，且聽下文講解。 作者：碼路印記 鏈接：https://juejin.cn/post/6882696575315886094 來源：掘金 著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。