《深入理解Mybatis原理》MyBatis數據源與連接池詳解 Detail - 後端,java,mybatis 程序員Seven Blog

MyBatis數據源DataSource分類

MyBatis把數據源DataSource分為三種：

UNPOOLED 不使用連接池的數據源
POOLED 使用連接池的數據源
JNDI 使用JNDI實現的數據源

相應地，MyBatis內部分別定義了實現了java.sql.DataSource接口的UnpooledDataSource，PooledDataSource類來表示UNPOOLED、POOLED類型的數據源。

對於JNDI類型的數據源DataSource，則是通過JNDI上下文中取值。

官網DataSource配置內容清單

dataSource 元素使用標準的 JDBC 數據源接口來配置 JDBC 連接對象的資源。

大多數 MyBatis 應用程序會按示例中的例子來配置數據源。雖然數據源配置是可選的，但如果要啓用延遲加載特性，就必須配置數據源。有三種內建的數據源類型（也就是 type="[UNPOOLED|POOLED|JNDI]"）：

UNPOOLED

這個數據源的實現會每次請求時打開和關閉連接。雖然有點慢，但對那些數據庫連接可用性要求不高的簡單應用程序來説，是一個很好的選擇。性能表現則依賴於使用的數據庫，對某些數據庫來説，使用連接池並不重要，這個配置就很適合這種情形。UNPOOLED 類型的數據源僅僅需要配置以下 5 種屬性：

driver – 這是 JDBC 驅動的 Java 類全限定名（並不是 JDBC 驅動中可能包含的數據源類）。
url – 這是數據庫的 JDBC URL 地址。
username – 登錄數據庫的用户名。
password – 登錄數據庫的密碼。
defaultTransactionIsolationLevel – 默認的連接事務隔離級別。
defaultNetworkTimeout – 等待數據庫操作完成的默認網絡超時時間（單位：毫秒）。查看 java.sql.Connection#setNetworkTimeout() 的 API 文檔以獲取更多信息。

作為可選項，你也可以傳遞屬性給數據庫驅動。只需在屬性名加上“driver.”前綴即可，例如：

driver.encoding=UTF8

這將通過 DriverManager.getConnection(url, driverProperties) 方法傳遞值為 UTF8 的 encoding 屬性給數據庫驅動。

POOLED

這種數據源的實現利用“池”的概念將 JDBC 連接對象組織起來，避免了創建新的連接實例時所必需的初始化和認證時間。這種處理方式很流行，能使併發 Web 應用快速響應請求。

除了上述提到 UNPOOLED 下的屬性外，還有更多屬性用來配置 POOLED 的數據源：

poolMaximumActiveConnections – 在任意時間可存在的活動（正在使用）連接數量，默認值：10
poolMaximumIdleConnections – 任意時間可能存在的空閒連接數。
poolMaximumCheckoutTime – 在被強制返回之前，池中連接被檢出（checked out）時間，默認值：20000 毫秒（即 20 秒）
poolTimeToWait – 這是一個底層設置，如果獲取連接花費了相當長的時間，連接池會打印狀態日誌並重新嘗試獲取一個連接（避免在誤配置的情況下一直失敗且不打印日誌），默認值：20000 毫秒（即 20 秒）。
poolMaximumLocalBadConnectionTolerance – 這是一個關於壞連接容忍度的底層設置，作用於每一個嘗試從緩存池獲取連接的線程。如果這個線程獲取到的是一個壞的連接，那麼這個數據源允許這個線程嘗試重新獲取一個新的連接，但是這個重新嘗試的次數不應該超過 poolMaximumIdleConnections 與 poolMaximumLocalBadConnectionTolerance 之和。默認值：3（新增於 3.4.5）
poolPingQuery – 發送到數據庫的偵測查詢，用來檢驗連接是否正常工作並準備接受請求。默認是“NO PING QUERY SET”，這會導致多數數據庫驅動出錯時返回恰當的錯誤消息。
poolPingEnabled – 是否啓用偵測查詢。若開啓，需要設置 poolPingQuery 屬性為一個可執行的 SQL 語句（最好是一個速度非常快的 SQL 語句），默認值：false。
poolPingConnectionsNotUsedFor – 配置 poolPingQuery 的頻率。可以被設置為和數據庫連接超時時間一樣，來避免不必要的偵測，默認值：0（即所有連接每一時刻都被偵測 — 當然僅當 poolPingEnabled 為 true 時適用）。

JNDI

這個數據源實現是為了能在如 EJB 或應用服務器這類容器中使用，容器可以集中或在外部配置數據源，然後放置一個 JNDI 上下文的數據源引用。這種數據源配置只需要兩個屬性：

initial_context – 這個屬性用來在 InitialContext 中尋找上下文（即，initialContext.lookup(initial_context)）。這是個可選屬性，如果忽略，那麼將會直接從 InitialContext 中尋找 data_source 屬性。
data_source – 這是引用數據源實例位置的上下文路徑。提供了 initial_context 配置時會在其返回的上下文中進行查找，沒有提供時則直接在 InitialContext 中查找。

和其他數據源配置類似，可以通過添加前綴“env.”直接把屬性傳遞給 InitialContext。比如：

env.encoding=UTF8

這就會在 InitialContext 實例化時往它的構造方法傳遞值為 UTF8 的 encoding 屬性。

你可以通過實現接口 org.apache.ibatis.datasource.DataSourceFactory 來使用第三方數據源實現：

public interface DataSourceFactory {
  void setProperties(Properties props);
  DataSource getDataSource();
}

org.apache.ibatis.datasource.unpooled.UnpooledDataSourceFactory 可被用作父類來構建新的數據源適配器，比如下面這段插入 C3P0 數據源所必需的代碼：

import org.apache.ibatis.datasource.unpooled.UnpooledDataSourceFactory;
import com.mchange.v2.c3p0.ComboPooledDataSource;

public class C3P0DataSourceFactory extends UnpooledDataSourceFactory {

  public C3P0DataSourceFactory() {
    this.dataSource = new ComboPooledDataSource();
  }
}

為了令其工作，記得在配置文件中為每個希望 MyBatis 調用的 setter 方法增加對應的屬性。下面是一個可以連接至 PostgreSQL 數據庫的例子：

<dataSource type="org.myproject.C3P0DataSourceFactory">
  <property name="driver" value="org.postgresql.Driver"/>
  <property name="url" value="jdbc:postgresql:mydb"/>
  <property name="username" value="postgres"/>
  <property name="password" value="root"/>
</dataSource>

DataSource的創建過程

MyBatis數據源DataSource對象的創建發生在MyBatis初始化的過程中。下面讓我們一步步地瞭解MyBatis是如何創建數據源DataSource的。

在mybatis的XML配置文件中，使用<dataSource>元素來配置數據源：

<dataSource type="org.myproject.C3P0DataSourceFactory">
  <property name="driver" value="org.postgresql.Driver"/>
  <property name="url" value="jdbc:postgresql:mydb"/>
  <property name="username" value="postgres"/>
  <property name="password" value="root"/>
</dataSource>

MyBatis在初始化時，解析此文件，根據<dataSource>的type屬性來創建相應類型的的數據源DataSource，即：

type=”POOLED” ：MyBatis會創建PooledDataSource實例
type=”UNPOOLED” ：MyBatis會創建UnpooledDataSource實例
type=”JNDI” ：MyBatis會從JNDI服務上查找DataSource實例，然後返回使用

順便説一下，MyBatis是通過工廠模式來創建數據源DataSource對象的，MyBatis定義了抽象的工廠接口:org.apache.ibatis.datasource.DataSourceFactory,通過其getDataSource()方法返回數據源DataSource：

public interface DataSourceFactory { 
    void setProperties(Properties props);  
    // 生產DataSource  
    DataSource getDataSource();  
}

上述三種不同類型的type，則有對應的以下dataSource工廠：

POOLED PooledDataSourceFactory
UNPOOLED UnpooledDataSourceFactory
JNDI JndiDataSourceFactory

其類圖如下所示：

MyBatis創建了DataSource實例後，會將其放到Configuration對象內的Environment對象中，供以後使用。

DataSource什麼時候創建Connection對象

當我們需要創建SqlSession對象並需要執行SQL語句時，這時候MyBatis才會去調用dataSource對象來創建java.sql.Connection對象。也就是説，java.sql.Connection對象的創建一直延遲到執行SQL語句的時候。

比如，我們有如下方法執行一個簡單的SQL語句：

String resource = "mybatis-config.xml";  
InputStream inputStream = Resources.getResourceAsStream(resource);  
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);  
SqlSession sqlSession = sqlSessionFactory.openSession();  
sqlSession.selectList("SELECT * FROM STUDENTS");

前4句都不會導致java.sql.Connection對象的創建，只有當第5句sqlSession.selectList("SELECT * FROM STUDENTS")，才會觸發MyBatis在底層執行下面這個方法來創建java.sql.Connection對象：

protected void openConnection() throws SQLException {  
    if (log.isDebugEnabled()) {  
        log.debug("Opening JDBC Connection");  
    }  
    connection = dataSource.getConnection();  
    if (level != null) {  
        connection.setTransactionIsolation(level.getLevel());  
    }  
    setDesiredAutoCommit(autoCommmit);  
}

不使用連接池的UnpooledDataSource

當 <dataSource>的type屬性被配置成了”UNPOOLED”，MyBatis首先會實例化一個UnpooledDataSourceFactory工廠實例，然後通過.getDataSource()方法返回一個UnpooledDataSource實例對象引用，我們假定為dataSource。

使用UnpooledDataSource的getConnection(),每調用一次就會產生一個新的Connection實例對象。

UnPooledDataSource的getConnection()方法實現如下：

/* 
 * UnpooledDataSource的getConnection()實現 
 */  
public Connection getConnection() throws SQLException  
{  
    return doGetConnection(username, password);  
}  
  
private Connection doGetConnection(String username, String password) throws SQLException  
{  
    //封裝username和password成properties  
    Properties props = new Properties();  
    if (driverProperties != null)  
    {  
        props.putAll(driverProperties);  
    }  
    if (username != null)  
    {  
        props.setProperty("user", username);  
    }  
    if (password != null)  
    {  
        props.setProperty("password", password);  
    }  
    return doGetConnection(props);  
}  
  
/* 
 *  獲取數據連接 
 */  
private Connection doGetConnection(Properties properties) throws SQLException  
{  
    //1.初始化驅動  
    initializeDriver();  
    //2.從DriverManager中獲取連接，獲取新的Connection對象  
    Connection connection = DriverManager.getConnection(url, properties);  
    //3.配置connection屬性  
    configureConnection(connection);  
    return connection;  
}

如上代碼所示，UnpooledDataSource會做以下事情：

初始化驅動：判斷driver驅動是否已經加載到內存中，如果還沒有加載，則會動態地加載driver類，並實例化一個Driver對象，使用DriverManager.registerDriver()方法將其註冊到內存中，以供後續使用。
創建Connection對象：使用DriverManager.getConnection()方法創建連接。
配置Connection對象：設置是否自動提交autoCommit和隔離級別isolationLevel。
返回Connection對象。

上述的序列圖如下所示：

總結：從上述的代碼中可以看到，我們每調用一次getConnection()方法，都會通過DriverManager.getConnection()返回新的java.sql.Connection實例。

為什麼要使用連接池

創建一個java.sql.Connection實例對象的代價

首先讓我們來看一下創建一個java.sql.Connection對象的資源消耗。我們通過連接Oracle數據庫，創建創建Connection對象，來看創建一個Connection對象、執行SQL語句各消耗多長時間。代碼如下：

public static void main(String[] args) throws Exception  {  
 
   String sql = "select * from hr.employees where employee_id < ? and employee_id >= ?";  
   PreparedStatement st = null;  
   ResultSet rs = null;  
 
   long beforeTimeOffset = -1L; //創建Connection對象前時間  
   long afterTimeOffset = -1L; //創建Connection對象後時間  
   long executeTimeOffset = -1L; //創建Connection對象後時間  
 
   Connection con = null;  
   Class.forName("oracle.jdbc.driver.OracleDriver");  
 
   beforeTimeOffset = new Date().getTime();  
   System.out.println("before:\t" + beforeTimeOffset);  
 
   con = DriverManager.getConnection("jdbc:oracle:thin:@127.0.0.1:1521:xe", "louluan", "123456");  
 
   afterTimeOffset = new Date().getTime();  
   System.out.println("after:\t\t" + afterTimeOffset);  
   System.out.println("Create Costs:\t\t" + (afterTimeOffset - beforeTimeOffset) + " ms");  
 
   st = con.prepareStatement(sql);  
   //設置參數  
   st.setInt(1, 101);  
   st.setInt(2, 0);  
   //查詢，得出結果集  
   rs = st.executeQuery();  
   executeTimeOffset = new Date().getTime();  
   System.out.println("Exec Costs:\t\t" + (executeTimeOffset - afterTimeOffset) + " ms");  
 
}

上述程序的執行結果為：

從此結果可以清楚地看出，創建一個Connection對象，用了250 毫秒；而執行SQL的時間用了170毫秒。

創建一個Connection對象用了250毫秒！這個時間對計算機來説可以説是一個非常奢侈的！

這僅僅是一個Connection對象就有這麼大的代價，設想一下另外一種情況：如果我們在Web應用程序中，為用户的每一個請求就操作一次數據庫，當有10000個在線用户併發操作的話，對計算機而言，僅僅創建Connection對象不包括做業務的時間就要損耗10000×250ms= 250 0000 ms = 2500 s = 41.6667 min,竟然要41分鐘！！！如果對高用户羣體使用這樣的系統，簡直就是開玩笑！

問題分析：

創建一個java.sql.Connection對象的代價是如此巨大，是因為創建一個Connection對象的過程，在底層就相當於和數據庫建立的通信連接，在建立通信連接的過程，消耗了這麼多的時間，而往往我們建立連接後（即創建Connection對象後），就執行一個簡單的SQL語句，然後就要拋棄掉，這是一個非常大的資源浪費！

解決方案：

對於需要頻繁地跟數據庫交互的應用程序，可以在創建了Connection對象，並操作完數據庫後，可以不釋放掉資源，而是將它放到內存中，當下次需要操作數據庫時，可以直接從內存中取出Connection對象，不需要再創建了，這樣就極大地節省了創建Connection對象的資源消耗。由於內存也是有限和寶貴的，這又對我們對內存中的Connection對象怎麼有效地維護提出了很高的要求。我們將在內存中存放Connection對象的容器稱之為連接池（Connection Pool）。下面讓我們來看一下MyBatis的線程池是怎樣實現的。

使用了連接池的PooledDataSource

同樣地，我們也是使用PooledDataSource的getConnection()方法來返回Connection對象。現在讓我們看一下它的基本原理：

PooledDataSource將java.sql.Connection對象包裹成PooledConnection對象放到了PoolState類型的容器中維護。 MyBatis將連接池中的PooledConnection分為兩種狀態：空閒狀態（idle）和活動狀態(active)，這兩種狀態的PooledConnection對象分別被存儲到PoolState容器內的idleConnections和activeConnections兩個List集合中：

idleConnections: 空閒(idle)狀態PooledConnection對象被放置到此集合中，表示當前閒置的沒有被使用的PooledConnection集合，調用PooledDataSource的getConnection()方法時，會優先從此集合中取PooledConnection對象。當用完一個java.sql.Connection對象時，MyBatis會將其包裹成PooledConnection對象放到此集合中。
activeConnections: 活動(active)狀態的PooledConnection對象被放置到名為activeConnections的ArrayList中，表示當前正在被使用的PooledConnection集合，調用PooledDataSource的getConnection()方法時，會優先從idleConnections集合中取PooledConnection對象,如果沒有，則看此集合是否已滿，如果未滿，PooledDataSource會創建出一個PooledConnection，添加到此集合中，並返回。

PoolState連接池的大致結構如下所示：

獲取java.sql.Connection對象的過程

下面讓我們看一下PooledDataSource 的getConnection()方法獲取Connection對象的實現：

public Connection getConnection() throws SQLException {  
    return popConnection(dataSource.getUsername(), dataSource.getPassword()).getProxyConnection();  
}  
 
public Connection getConnection(String username, String password) throws SQLException {  
    return popConnection(username, password).getProxyConnection();  
}

上述的popConnection()方法，會從連接池中返回一個可用的PooledConnection對象，然後再調用getProxyConnection()方法最終返回Conection對象。（至於為什麼會有getProxyConnection(),請關注下一節）。

現在讓我們看一下popConnection()方法到底做了什麼：

先看是否有空閒(idle)狀態下的PooledConnection對象，如果有，就直接返回一個可用的PooledConnection對象；否則進行第2步。
查看活動狀態的PooledConnection池activeConnections是否已滿；如果沒有滿，則創建一個新的PooledConnection對象，然後放到activeConnections池中，然後返回此PooledConnection對象；否則進行第三步；
看最先進入activeConnections池中的PooledConnection對象是否已經過期：如果已經過期，從activeConnections池中移除此對象，然後創建一個新的PooledConnection對象，添加到activeConnections中，然後將此對象返回；否則進行第4步。
線程等待，循環2步

/* 
 * 傳遞一個用户名和密碼，從連接池中返回可用的PooledConnection 
 */  
private PooledConnection popConnection(String username, String password) throws SQLException  
{  
   boolean countedWait = false;  
   PooledConnection conn = null;  
   long t = System.currentTimeMillis();  
   int localBadConnectionCount = 0;  
 
   while (conn == null)  
   {  
       synchronized (state)  
       {  
           if (state.idleConnections.size() > 0)  
           {  
               // 連接池中有空閒連接，取出第一個  
               conn = state.idleConnections.remove(0);  
               if (log.isDebugEnabled())  
               {  
                   log.debug("Checked out connection " + conn.getRealHashCode() + " from pool.");  
               }  
           }  
           else  
           {  
               // 連接池中沒有空閒連接，則取當前正在使用的連接數小於最大限定值，  
               if (state.activeConnections.size() < poolMaximumActiveConnections)  
               {  
                   // 創建一個新的connection對象  
                   conn = new PooledConnection(dataSource.getConnection(), this);  
                   @SuppressWarnings("unused")  
                   //used in logging, if enabled  
                   Connection realConn = conn.getRealConnection();  
                   if (log.isDebugEnabled())  
                   {  
                       log.debug("Created connection " + conn.getRealHashCode() + ".");  
                   }  
               }  
               else  
               {  
                   // Cannot create new connection 當活動連接池已滿，不能創建時，取出活動連接池的第一個，即最先進入連接池的PooledConnection對象  
                   // 計算它的校驗時間，如果校驗時間大於連接池規定的最大校驗時間，則認為它已經過期了，利用這個PoolConnection內部的realConnection重新生成一個PooledConnection  
                   //  
                   PooledConnection oldestActiveConnection = state.activeConnections.get(0);  
                   long longestCheckoutTime = oldestActiveConnection.getCheckoutTime();  
                   if (longestCheckoutTime > poolMaximumCheckoutTime)  
                   {  
                       // Can claim overdue connection  
                       state.claimedOverdueConnectionCount++;  
                       state.accumulatedCheckoutTimeOfOverdueConnections += longestCheckoutTime;  
                       state.accumulatedCheckoutTime += longestCheckoutTime;  
                       state.activeConnections.remove(oldestActiveConnection);  
                       if (!oldestActiveConnection.getRealConnection().getAutoCommit())  
                       {  
                           oldestActiveConnection.getRealConnection().rollback();  
                       }  
                       conn = new PooledConnection(oldestActiveConnection.getRealConnection(), this);  
                       oldestActiveConnection.invalidate();  
                       if (log.isDebugEnabled())  
                       {  
                           log.debug("Claimed overdue connection " + conn.getRealHashCode() + ".");  
                       }  
                   }  
                   else  
                   {  
 
                       //如果不能釋放，則必須等待有  
                       // Must wait  
                       try  
                       {  
                           if (!countedWait)  
                           {  
                               state.hadToWaitCount++;  
                               countedWait = true;  
                           }  
                           if (log.isDebugEnabled())  
                           {  
                               log.debug("Waiting as long as " + poolTimeToWait + " milliseconds for connection.");  
                           }  
                           long wt = System.currentTimeMillis();  
                           state.wait(poolTimeToWait);  
                           state.accumulatedWaitTime += System.currentTimeMillis() - wt;  
                       }  
                       catch (InterruptedException e)  
                       {  
                           break;  
                       }  
                   }  
               }  
           }  
 
           //如果獲取PooledConnection成功，則更新其信息  
 
           if (conn != null)  
           {  
               if (conn.isValid())  
               {  
                   if (!conn.getRealConnection().getAutoCommit())  
                   {  
                       conn.getRealConnection().rollback();  
                   }  
                   conn.setConnectionTypeCode(assembleConnectionTypeCode(dataSource.getUrl(), username, password));  
                   conn.setCheckoutTimestamp(System.currentTimeMillis());  
                   conn.setLastUsedTimestamp(System.currentTimeMillis());  
                   state.activeConnections.add(conn);  
                   state.requestCount++;  
                   state.accumulatedRequestTime += System.currentTimeMillis() - t;  
               }  
               else  
               {  
                   if (log.isDebugEnabled())  
                   {  
                       log.debug("A bad connection (" + conn.getRealHashCode() + ") was returned from the pool, getting another connection.");  
                   }  
                   state.badConnectionCount++;  
                   localBadConnectionCount++;  
                   conn = null;  
                   if (localBadConnectionCount > (poolMaximumIdleConnections + 3))  
                   {  
                       if (log.isDebugEnabled())  
                       {  
                           log.debug("PooledDataSource: Could not get a good connection to the database.");  
                       }  
                       throw new SQLException("PooledDataSource: Could not get a good connection to the database.");  
                   }  
               }  
           }  
       }  
 
   }  
 
   if (conn == null)  
   {  
       if (log.isDebugEnabled())  
       {  
           log.debug("PooledDataSource: Unknown severe error condition.  The connection pool returned a null connection.");  
       }  
       throw new SQLException("PooledDataSource: Unknown severe error condition.  The connection pool returned a null connection.");  
   }  
 
   return conn;  
}

對應的處理流程圖如下所示：

如上所示,對於PooledDataSource的getConnection()方法內，先是調用類PooledDataSource的popConnection()方法返回了一個PooledConnection對象，然後調用了PooledConnection的getProxyConnection()來返回Connection對象。

java.sql.Connection對象的回收

當我們的程序中使用完Connection對象時，如果不使用數據庫連接池，我們一般會調用 connection.close()方法，關閉connection連接，釋放資源。如下所示：

private void test() throws ClassNotFoundException, SQLException  
{  
   String sql = "select * from hr.employees where employee_id < ? and employee_id >= ?";  
   PreparedStatement st = null;  
   ResultSet rs = null;  
 
   Connection con = null;  
   Class.forName("oracle.jdbc.driver.OracleDriver");  
   try  
   {  
       con = DriverManager.getConnection("jdbc:oracle:thin:@127.0.0.1:1521:xe", "louluan", "123456");  
       st = con.prepareStatement(sql);  
       //設置參數  
       st.setInt(1, 101);  
       st.setInt(2, 0);  
       //查詢，得出結果集  
       rs = st.executeQuery();  
       //取數據，省略  
       //關閉，釋放資源  
       con.close();  
   }  
   catch (SQLException e)  
   {  
       con.close();  
       e.printStackTrace();  
   }  
}

調用過close()方法的Connection對象所持有的資源會被全部釋放掉，Connection對象也就不能再使用。

那麼，如果我們使用了連接池，我們在用完了Connection對象時，需要將它放在連接池中，該怎樣做呢？

為了和一般的使用Conneciton對象的方式保持一致，我們希望當Connection使用完後，調用.close()方法，而實際上Connection資源並沒有被釋放，而實際上被添加到了連接池中。這樣可以做到嗎？答案是可以。上述的要求從另外一個角度來描述就是：能否提供一種機制，讓我們知道Connection對象調用了什麼方法，從而根據不同的方法自定義相應的處理機制。恰好代理機制就可以完成上述要求.

怎樣實現Connection對象調用了close()方法，而實際是將其添加到連接池中：

這是要使用代理模式，為真正的Connection對象創建一個代理對象，代理對象所有的方法都是調用相應的真正Connection對象的方法實現。當代理對象執行close()方法時，要特殊處理，不調用真正Connection對象的close()方法，而是將Connection對象添加到連接池中。

MyBatis的PooledDataSource的PoolState內部維護的對象是PooledConnection類型的對象，而PooledConnection則是對真正的數據庫連接java.sql.Connection實例對象的包裹器。

PooledConnection對象內持有一個真正的數據庫連接java.sql.Connection實例對象和一個java.sql.Connection的代理，其部分定義如下：

class PooledConnection implements InvocationHandler {  
   
    //......  
    //所創建它的datasource引用  
    private PooledDataSource dataSource;  
    //真正的Connection對象  
    private Connection realConnection;  
    //代理自己的代理Connection  
    private Connection proxyConnection;  
   
    //......  
}

PooledConenction實現了InvocationHandler接口，並且，proxyConnection對象也是根據這個它來生成的代理對象：

public PooledConnection(Connection connection, PooledDataSource dataSource) {  
   this.hashCode = connection.hashCode();  
   this.realConnection = connection;  
   this.dataSource = dataSource;  
   this.createdTimestamp = System.currentTimeMillis();  
   this.lastUsedTimestamp = System.currentTimeMillis();  
   this.valid = true;  
   this.proxyConnection = (Connection) Proxy.newProxyInstance(Connection.class.getClassLoader(), IFACES, this);  
}

實際上，我們調用PooledDataSource的getConnection()方法返回的就是這個proxyConnection對象。當我們調用此proxyConnection對象上的任何方法時，都會調用PooledConnection對象內invoke()方法。

讓我們看一下PooledConnection類中的invoke()方法定義：

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {  
    String methodName = method.getName();  
    //當調用關閉的時候，回收此Connection到PooledDataSource中  
    if (CLOSE.hashCode() == methodName.hashCode() && CLOSE.equals(methodName)) {  
        dataSource.pushConnection(this);  
        return null;  
    } else {  
        try {  
            if (!Object.class.equals(method.getDeclaringClass())) {  
                checkConnection();  
            }  
            return method.invoke(realConnection, args);  
        } catch (Throwable t) {  
            throw ExceptionUtil.unwrapThrowable(t);  
        }  
    }  
}

從上述代碼可以看到，當我們使用了pooledDataSource.getConnection()返回的Connection對象的close()方法時，不會調用真正Connection的close()方法，而是將此Connection對象放到連接池中。

JNDI類型的數據源DataSource

對於JNDI類型的數據源DataSource的獲取就比較簡單，MyBatis定義了一個JndiDataSourceFactory工廠來創建通過JNDI形式生成的DataSource。下面讓我們看一下JndiDataSourceFactory的關鍵代碼：

if (properties.containsKey(INITIAL_CONTEXT) && properties.containsKey(DATA_SOURCE))  
{  
    //從JNDI上下文中找到DataSource並返回  
    Context ctx = (Context) initCtx.lookup(properties.getProperty(INITIAL_CONTEXT));  
    dataSource = (DataSource) ctx.lookup(properties.getProperty(DATA_SOURCE));  
}  
else if (properties.containsKey(DATA_SOURCE))  
{  
    //從JNDI上下文中找到DataSource並返回  
    dataSource = (DataSource) initCtx.lookup(properties.getProperty(DATA_SOURCE));  
}

程序員Seven Blog

@seven97_top

Tags

後端 (618)

JAVA (556)

MySQL (192)

springboot (120)

redis (93)

設計模式 (50)

netty (33)

leetcode (32)

Mybatis (27)

rabbitmq (20)

maven (18)

Stories

《深入理解Mybatis原理》MyBatis數據源與連接池詳解 - Stories Detail