提交訂單效能優化系列之002-引入自己編寫的資料庫連線池
資料庫連線池對效能的影響
總是在各種地方看到類似的說明：“資料庫連線池是非常昂貴的資源。” 那麼請問“非常昂貴”到底是有多昂貴呢？
在我的機器上的測試結果是：從資料庫獲取一個連線的平均耗時大約是3到4毫秒。
在沒有使用資料庫連線池的時候，測試的結果是這樣的：
提交每個訂單平均耗時的毫秒數：157 每秒鐘可以提交的訂單數：6
在使用了資料庫連線池以的一，測試的結果是這樣的：
提交每個訂單平均耗時的毫秒數：99 每秒鐘可以提交的訂單數：10
當然了，每次執行得到的結果會有差別，但是大體是一致的。
如果用“提交每個訂單平均耗時的毫秒數”來計算的話：157 - 99 / 99 * 100% = 58.58%，也就是說，在單執行緒測試時，使用資料庫連線池可以提升大約60%的效能。
自已編寫資料庫連線池的關鍵點
關鍵點：在Connection的例項呼叫它的close()方法的時候，不要真的close，而是放在記憶體裡面，以備下一次使用。下次使用的時候就直接從記憶體裡面取就可以了。
實現方法就是：建一個代理類，讓外部不直接呼叫實際的Connection，而是呼叫代理Connection，讓外部以為自己已經close了，而實際卻沒有close。
002版本更新說明
002版在001版的基礎上做了一些結構上的調整，主要有以下兩點：
- 測試包路徑與原始碼包路徑保持一致
- 原始碼包中的類不再宣告為
public的，這樣就保證只有同名的包下的類才能訪問到這些類，杜絕了錯誤引用的可能性
同時這一版優化了列印日誌的體驗，增加了一些進度日誌（以防止因為沒有耐心而停止測試），同時也增加了一些分隔線，用於更清晰地展現日誌。
這一版本的日誌完整日誌如下：
—————————— 分隔線 Version001Test : initDb —————————— 正在初始化資料庫：shop_order_test_version001 初始化資料庫完成：shop_order_test_version001 —————————— 分隔線 Version001Test : singleThread —————————— 當前迴圈的序號：0 當前迴圈的序號：11 當前迴圈的序號：22 當前迴圈的序號：33 當前迴圈的序號：44 當前迴圈的序號：55 當前迴圈的序號：66 當前迴圈的序號：77 當前迴圈的序號：88 當前迴圈的序號：99 提交每個訂單平均耗時的毫秒數：157 每秒鐘可以提交的訂單數：6 提交訂單之前的庫存：100 提交訂單之前的銷量：0 提交訂單之後的庫存：0 提交訂單之後的銷量：100 —————————— 分隔線 Version002Test : initDb —————————— 正在初始化資料庫：shop_order_test_version002 初始化資料庫完成：shop_order_test_version002 獲取一個數據庫連線平均耗時：3 毫秒 初始化資料庫連線池完成，數量為：100 —————————— 分隔線 Version002Test : singleThread —————————— 當前迴圈的序號：0 當前迴圈的序號：11 當前迴圈的序號：22 當前迴圈的序號：33 當前迴圈的序號：44 當前迴圈的序號：55 當前迴圈的序號：66 當前迴圈的序號：77 當前迴圈的序號：88 當前迴圈的序號：99 提交每個訂單平均耗時的毫秒數：99 每秒鐘可以提交的訂單數：10 提交訂單之前的庫存：100 提交訂單之前的銷量：0 提交訂單之後的庫存：0 提交訂單之後的銷量：100
總結
從資料庫獲取一個連線的平均耗時大約是3到4毫秒。在本次測試時，使用資料庫連線池可以提升大約60%的效能。由此可見，資料庫連線確實是“非常昂貴的資源”。