根據(jù)綜合性能，可靠性，穩(wěn)定性，擴展性，易用性等因素替換成最優(yōu)的數(shù)據(jù)庫連接池。
Druid:druid-1.0.29
數(shù)據(jù)庫 Mysql.5.6.17
替換目標:替換掉C3P0,用druid來替換
替換原因:
1、性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免鎖競爭。
2、druid功能最為全面，sql攔截等功能，統(tǒng)計數(shù)據(jù)較為全面，具有良好的擴展性。
3、綜合性能，擴展性等方面，可考慮使用druid或者hikariCP連接池，比較方便對jdbc接口進行監(jiān)控跟蹤等。
4、可開啟prepareStatement緩存，對性能會有大概20%的提升。
psCache是connection私有的，所以不存在線程競爭的問題，開啟pscache不會存在競爭的性能損耗。
psCache的key為prepare執(zhí)行的sql和catalog等，value對應(yīng)的為prepareStatement對象。開啟緩存主要是減少了解析sql的開銷。
5、3p0歷史悠久，代碼及其復(fù)雜，不利于維護。并且存在deadlock的潛在風險。
6、Druid可以打印SQL，慢查詢方面的日志
Druid 參數(shù)
| 配置參數(shù) | 缺省值 | 游戲服設(shè)置的值 | 參數(shù)說明 |
| initialSize | 0 | 4 | 初始化連接數(shù)量 |
| minIdle | 0 | 4 | 最小空閑連接數(shù) |
| maxActive | 8 | 8 | 最大并發(fā)連接數(shù) |
| maxWait | -1L | 60000 |
獲取連接時最大等待時間，單位毫秒。配置了maxWait之后， 缺省啟用公平鎖，并發(fā)效率會有所下降， 如果需要可以通過配置useUnfairLock屬性為true使用非公平鎖。 |
| timeBetweenEvictionRunsMillis | 60000 | 60000 |
配置間隔多久才進行一次檢測，檢測需要關(guān)閉的空閑連接，單位是毫秒 Destroy線程會檢測連接的間隔時間 |
| minEvictableIdleTimeMillis | 1800000 | 1800000 | 配置一個連接在池中最小生存的時間，單位是毫秒 |
| validationQuery | null | select 1 | 用來檢測連接是否有效的sql，要求是一個查詢語句 |
| testOnBorrow | FALSE | FALSE | 申請連接時執(zhí)行validationQuery檢測連接是否有效，做了這個配置會降低性能。 |
| testOnReturn | FALSE | FALSE | 歸還連接時執(zhí)行validationQuery檢測連接是否有效，做了這個配置會降低性能 |
| testWhileIdle | TRUE | TRUE |
建議配置為true，不影響性能，并且保證安全性。 申請連接的時候檢測，如果 空閑時間大于 timeBetweenEvictionRunsMillis， 執(zhí)行validationQuery檢測連接是否有效。 |
| poolPreparedStatements | FALSE | TRUE |
false 是否緩存preparedStatement，也就是PSCache。 PSCache對支持游標的數(shù)據(jù)庫性能提升巨大，比如說oracle。 在mysql5.5以下的版本中沒有PSCache功能，建議關(guān)閉掉。 5.5及以上版本有PSCache，建議開啟。 |
| maxPoolPreparedStatementPerConnectionSize | 10 | 100 |
要啟用PSCache，必須配置大于0，當大于0時， poolPreparedStatements自動觸發(fā)修改為true。 單個connnection獨享一個statement cache，也就是說maxOpenPreparedStatements是針對單個connection鏈接的 |
運行原理:
數(shù)據(jù)庫連接池在初始化的時候會創(chuàng)建initialSize個連接，當有數(shù)據(jù)庫操作時，會從池中取出一個連接。如果當前池中正在使用的連接數(shù)等于maxActive，則會等待一段時間，等待其他操作釋放掉某一個連接，如果這個等待時間超過了maxWait，則會報錯；如果當前正在使用的連接數(shù)沒有達到maxActive，則判斷當前是否空閑連接，如果有則直接使用空閑連接，如果沒有則新建立一個連接。在連接使用完畢后，不是將其物理連接關(guān)閉，而是將其放入池中等待其他操作復(fù)用。 同時連接池內(nèi)部有機制判斷，如果當前的總的連接數(shù)少于miniIdle，則會建立新的空閑連接，以保證連接數(shù)得到miniIdle。如果當前連接池中某個連接在空閑了timeBetweenEvictionRunsMillis時間后仍然沒有使用，則被物理性的關(guān)閉掉。有些數(shù)據(jù)庫連接的時候有超時限制（mysql連接在8小時后斷開），或者由于網(wǎng)絡(luò)中斷等原因，連接池的連接會出現(xiàn)失效的情況，這時候設(shè)置一個testWhileIdle參數(shù)為true，可以保證連接池內(nèi)部定時檢測連接的可用性，不可用的連接會被拋棄或者重建，最大情況的保證從連接池中得到的Connection對象是可用的。當然，為了保證絕對的可用性，你也可以使用testOnBorrow為true（即在獲取Connection對象時檢測其可用性），不過這樣會影響性能。
如果要進行SQL監(jiān)控，可以加入以下代碼:
|
1
2
3
4
5
6
7
8
9
10
|
Log4j2Filter log4j2 = new Log4j2Filter(); log4j2.setResultSetLogEnabled(false); log4j2.setStatementSqlPrettyFormat(false); log4j2.setStatementExecutableSqlLogEnable(true); log4j2.setDataSourceLogEnabled(false); log4j2.setConnectionLogEnabled(false); log4j2.setStatementLogEnabled(false); log4j2.setResultSetLogEnabled(false); ret.setProxyFilters(Arrays.asList(log4j2)); |
閑置檢測，創(chuàng)建連接，廢棄連接清理由這三線程管理
|
1
2
3
|
Daemon Thread [Abandoned connection cleanup thread] Daemon Thread [Druid-ConnectionPool-Create-1184124073] Daemon Thread [Druid-ConnectionPool-Destroy-1184124073] |
總結(jié)
以上就是本文關(guān)于數(shù)據(jù)庫連接池Druid使用說明的全部內(nèi)容，希望對大家有所幫助。感興趣的朋友可以參閱：MySQL prepare原理詳解等及其他相關(guān)專題，有什么問題可以隨時留言，小編會及時回復(fù)大家的。
原文鏈接：http://blog.csdn.net/jiangguilong2000/article/details/68483886
