mybatis源码_Mybatis源码之SqlSession
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行，其實只有兩行代碼。
1public?static?void?main(String[]?args)?throws?IOException?{2????//?mybatis配置文件
3????String?path?=?"mybatis-config.xml";
4????InputStream?inputStream?=?Resources.getResourceAsStream(path);
5
6????//?獲取?SqlSessionFactory
7????SqlSessionFactory?sqlSessionFactory?=?new?SqlSessionFactoryBuilder().build(inputStream);
8????//?創建?SqlSession
9????try?(SqlSession?sqlSession?=?sqlSessionFactory.openSession())?{
10????????//?……
11????}
12}
第7行：主要完成配置文件解析并保存到Configuration，由SqlSessionFactoryBuilder創建SqlSessionFactory對象，為創建SqlSession做準備。
第9行：采用“try-with-resource”方式調用SqlSessionFactory#openSession方法創建了SqlSession對象。當代碼離開try代碼塊時會自動關閉SqlSession，但是這里的自動關閉并不是SqlSession的能力，相當于手動調用了SqlSession#close方法。看下openSession的實現：
1??public?SqlSession?openSession()?{2????return?openSessionFromDataSource(configuration.getDefaultExecutorType(),?null,?false);
3??}
4
5??private?SqlSession?openSessionFromDataSource(ExecutorType?execType,?TransactionIsolationLevel?level,?boolean?autoCommit)?{
6????Transaction?tx?=?null;
7????try?{
8??????//獲取環境配置信息
9??????final?Environment?environment?=?configuration.getEnvironment();
10??????//創建事務處理器
11??????final?TransactionFactory?transactionFactory?=?getTransactionFactoryFromEnvironment(environment);
12??????tx?=?transactionFactory.newTransaction(environment.getDataSource(),?level,?autoCommit);
13??????//創建Executor，這里默認使用CachingExecutor
14??????final?Executor?executor?=?configuration.newExecutor(tx,?execType);
15??????//創建SqlSession，默認實例DefaultSqlSession
16??????return?new?DefaultSqlSession(configuration,?executor,?autoCommit);
17????}?catch?(Exception?e)?{
18??????closeTransaction(tx);?//?may?have?fetched?a?connection?so?lets?call?close()
19??????throw?ExceptionFactory.wrapException("Error?opening?session.??Cause:?"?+?e,?e);
20????}?finally?{
21??????ErrorContext.instance().reset();
22????}
23??}
由此可知，openSessionFromDataSource方法完成了SqlSession的創建，它返回了DefaultSqlSession對象。DefaultSqlSession中聚合了Configuration、Executor等對象。
selectXxx方法
以selectList為例看下selectXxx方法的執行過程：
1??public??List?selectList(String?statement,?Object?parameter,?RowBounds?rowBounds)?{ 2????try?{ 3??????//statement為MappedStatement的唯一id，注冊在Configuration#mappedStatements 4??????//根據id獲取MappedStatement 5??????MappedStatement?ms?=?configuration.getMappedStatement(statement); 6??????//調用執行器的query方法執行查詢命令。 7??????return?executor.query(ms,?wrapCollection(parameter),?rowBounds,?Executor.NO_RESULT_HANDLER); 8????}?catch?(Exception?e)?{ 9??????throw?ExceptionFactory.wrapException("Error?querying?database.??Cause:?"?+?e,?e);10????}?finally?{11??????ErrorContext.instance().reset();12????}13??}SqlSession中selectXxx方法，最終都走到了selectList方法，但是它并沒有直接與數據庫交互，獲取MappedStatement對象后調用了執行器Executor的query方法。
insert方法
insert對應sql的insert命令，代碼如下：
1??public?int?insert(String?statement)?{2????return?insert(statement,?null);
3??}
4
5??public?int?insert(String?statement,?Object?parameter)?{
6????return?update(statement,?parameter);
7??}
8
9??public?int?update(String?statement,?Object?parameter)?{
10????try?{
11??????dirty?=?true;
12??????MappedStatement?ms?=?configuration.getMappedStatement(statement);
13??????return?executor.update(ms,?wrapCollection(parameter));
14????}?catch?(Exception?e)?{
15??????throw?ExceptionFactory.wrapException("Error?updating?database.??Cause:?"?+?e,?e);
16????}?finally?{
17??????ErrorContext.instance().reset();
18????}
19??}
與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對象，什么情況？實現了這兩個接口，卻又聚合了這兩個接口的實例，難道它只是個代理，就是包了一層？源碼走走看！
1public?class?SqlSessionMgrDemo?{2????public?static?void?main(String[]?args)?throws?IOException?{
3????????//?mybatis配置文件
4????????String?path?=?"mybatis-config.xml";
5????????InputStream?inputStream?=?Resources.getResourceAsStream(path);
6????????//?獲取?SqlSessionManager
7????????SqlSessionManager?sqlSessionManager?=?SqlSessionManager.newInstance(inputStream);
8????????//?開啟對session的管理：沒有這行代碼也可以使用
9????????sqlSessionManager.startManagedSession();
10????????//?獲取mapper
11????????CompanyDao?dao?=?sqlSessionManager.getMapper(CompanyDao.class);
12????????//?執行查詢
13????????CompanyDO?companyDO?=?dao.selectById(1);
14????????System.out.println(companyDO);
15????}
16}
簡單說下這段代碼的執行流程：
4～5行：加載并讀取配置文件；
7行：創建SqlSessionManager實例；
9行：開啟對SqlSession的管理，通過它可以實現對SqlSession的線程安全管理，使SqlSessionManager實例可共享(這個與DefaultSqlSession有差別)；
11～14行：執行查詢；
實例化
通過示例代碼可知，SqlSessionManager#newInstance創建了SqlSessionManager對象，看下執行過程，我們仔細看看SqlSessionManager到底是個什么東東。
1//?創建?SqlSessionManager2public?static?SqlSessionManager?newInstance(InputStream?inputStream)?{
3??return?new?SqlSessionManager(new?SqlSessionFactoryBuilder().build(inputStream,?null,?null));
4}
5
6//?構造方法，這里入參為DefaultSqlSessionFactory實例
7private?SqlSessionManager(SqlSessionFactory?sqlSessionFactory)?{
8
9??this.sqlSessionFactory?=?sqlSessionFactory;
10
11??//?通過動態代理，創建SqlSession實例
12??this.sqlSessionProxy?=?(SqlSession)?Proxy.newProxyInstance(
13??????SqlSessionFactory.class.getClassLoader(),
14??????new?Class[]{SqlSession.class},
15??????new?SqlSessionInterceptor());
16}
17
18//?SqlSessionFactory實例
19private?final?SqlSessionFactory?sqlSessionFactory;
20
21//?SqlSession?代理對象
22private?final?SqlSession?sqlSessionProxy;
newInstance方法調用了SqlSessionManager的私有構造方法(僅有私有構造方法)，構造方法的入參是SqlSessionFactory(與DefaultSqlSession的實現一致)，這里是其默認實現DefaultSqlSessionFactory。
構造方法內通過動態代理創建對象sqlSessionProxy，它是SqlSession的動態實現，這里需要重點關注SqlSessionInterceptor這個類。從名稱看它是一個攔截器，也就是說當我們調用SqlSession的方法時，會被它攔截，看下SqlSessionInterceptor#invoke方法：
1??private?class?SqlSessionInterceptor?implements?InvocationHandler?{2????public?SqlSessionInterceptor()?{
3????????//?Prevent?Synthetic?Access
4????}
5
6????@Override
7????public?Object?invoke(Object?proxy,?Method?method,?Object[]?args)?throws?Throwable?{
8
9??????//?判斷本地線程是否有sqlSession
10??????final?SqlSession?sqlSession?=?SqlSessionManager.this.localSqlSession.get();
11??????//?如果有，直接使用，無需創建
12??????if?(sqlSession?!=?null)?{
13????????try?{
14??????????//?調用SqlSession接口方法實現
15??????????return?method.invoke(sqlSession,?args);
16????????}?catch?(Throwable?t)?{
17??????????throw?ExceptionUtil.unwrapThrowable(t);
18????????}
19??????}?else?{
20????????//?如果沒有，通過openSession創建，openSession方法返回的是DefaultSqlSession實例
21????????//這里使用try-with-resource，使用完成會自動關閉
22????????try?(SqlSession?autoSqlSession?=?openSession())?{
23??????????try?{
24????????????//?調用SqlSession接口方法實現
25????????????final?Object?result?=?method.invoke(autoSqlSession,?args);
26????????????//事務提交
27????????????autoSqlSession.commit();
28????????????return?result;
29??????????}?catch?(Throwable?t)?{
30????????????//事務回滾
31????????????autoSqlSession.rollback();
32????????????throw?ExceptionUtil.unwrapThrowable(t);
33??????????}
34????????}
35??????}
36????}
37??}
SqlSessionInterceptor#invoke首先會從localSqlSession獲取SqlSession對象，localSqlSession是什么呢？這里只提到get，那set在哪里？從代碼里面找下吧：
1??//localSqlSession是一個ThreadLocal對象，用來存儲SqlSession2??//這是一個線程安全的標志
3??private?final?ThreadLocal?localSqlSession?=?new?ThreadLocal<>(); 4 5??//開啟對SqlSession的管理，我們示例代碼有調用 6??public?void?startManagedSession()?{ 7????//為localSqlSession賦值，參數為openSession返回值 8????this.localSqlSession.set(openSession()); 9??}1011??public?SqlSession?openSession()?{12????//與之前一樣，它返回的是DefaultSqlSession對象13????return?sqlSessionFactory.openSession();14??}
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代理對象完成，沒有什么處理邏輯，貼幾個方法看下：
1??public?void?select(String?statement,?Object?parameter,?RowBounds?rowBounds,?ResultHandler?handler)?{2????sqlSessionProxy.select(statement,?parameter,?rowBounds,?handler);
3??}
4
5??public?int?insert(String?statement)?{
6????return?sqlSessionProxy.insert(statement);
7??}
8
9??public?int?update(String?statement)?{
10????return?sqlSessionProxy.update(statement);
11??}
12
13??public?int?delete(String?statement)?{
14????return?sqlSessionProxy.delete(statement);
15??}
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如何做，且聽下文講解。
感謝您的閱讀，如有問題歡迎討論！也可以關注我的微信公眾號：“兮一昂吧”。歡迎點贊、在看、轉發。
總結
以上是生活随笔為你收集整理的mybatis源码_Mybatis源码之SqlSession的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 北京环球影城停车场收费标准
- 下一篇： oppok9功能介绍