java連接池Druid連接回收DestroyConnectionThread&DestroyTask
Druid連接池的連接回收線程DestroyThread
接上一篇文章，研究Druid連接池的連接回收線程DestroyThread，通過調用destroyTask.run->DruidDataSourcek.shrink完成過期連接的回收。
DruidDataSourcek.shrink
理解DruidDataSourcek的連接回收方法shrink有一個必要前提：Druid的getConnection方法總是從connectoins的尾部獲取連接，所以閑置連接最有可能出現(xiàn)在connections數(shù)組的頭部，閑置超期需要被回收的連接也應該處于connections的頭部（數(shù)組下標較小的對象）。
在這個基礎上，我們開始分析代碼。
public void shrink(boolean checkTime, boolean keepAlive) {
try {
lock.lockInterruptibly();
} catch (InterruptedException e) {
return;
}
boolean needFill = false;
int evictCount = 0;
int keepAliveCount = 0;
int fatalErrorIncrement = fatalErrorCount - fatalErrorCountLastShrink;
fatalErrorCountLastShrink = fatalErrorCount;獲取鎖資源，并初始化控制變量
try {
if (!inited) {
return;
}
final int checkCount = poolingCount - minIdle;
final long currentTimeMillis = System.currentTimeMillis();
for (int i = 0; i < poolingCount; ++i) {
DruidConnectionHolder connection = connections[i];
if ((onFatalError || fatalErrorIncrement > 0) && (lastFatalErrorTimeMillis > connection.connectTimeMillis)) {
keepAliveConnections[keepAliveCount++] = connection;
continue;
}如果初始化尚未完成，則不能開始做清理動作，直接返回。
計算checkCount，checkCount的意思是本次需要清理、或者需要檢查的連接數(shù)量，checkCount等于連接池數(shù)量減去參數(shù)設置的需要保持的最小空閑連接數(shù)。很好理解，清理完成之后仍然需要確保最小空閑連接數(shù)。
之后循環(huán)逐個檢查連接池connections中的所有連接，從頭部(connections[0])開始。
如果清理過程中發(fā)生了錯誤，并且錯誤發(fā)生的時間是在當前連接的連接獲取時間之后，則將當前連接放入keepAliveConnections中，繼續(xù)檢查下一個連接。
然后：
if (checkTime) {
if (phyTimeoutMillis > 0) {
long phyConnectTimeMillis = currentTimeMillis - connection.connectTimeMillis;
if (phyConnectTimeMillis > phyTimeoutMillis) {
evictConnections[evictCount++] = connection;
continue;
}
}
long idleMillis = currentTimeMillis - connection.lastActiveTimeMillis;
if (idleMillis < minEvictableIdleTimeMillis
&& idleMillis < keepAliveBetweenTimeMillis
) {
break;
}
if (idleMillis >= minEvictableIdleTimeMillis) {
if (checkTime && i < checkCount) {
evictConnections[evictCount++] = connection;
continue;
} else if (idleMillis > maxEvictableIdleTimeMillis) {
evictConnections[evictCount++] = connection;
continue;
}
}
if (keepAlive && idleMillis >= keepAliveBetweenTimeMillis) {
keepAliveConnections[keepAliveCount++] = connection;
}
}這段代碼對應的條件是checkTime，checkTime的意思是：是否檢查數(shù)據(jù)庫連接的空閑時間，是調用shrink方法時傳入的，destoryThread任務調用shrink方法時傳入的是true，所以會走到這段代碼邏輯中。
如果參數(shù)設置的phyTimeoutMillis，即物理連接的超時時間>0的話，則檢查當前連接創(chuàng)建以來到現(xiàn)在的時長如果已超時的話，當前連接放入evictConnections中，準備回收。
然后計算當前連接的空閑時間idleMillis，如果空閑時間小于參數(shù)設置的連接最小空閑回收時間minEvictableIdleTimeMillis，并且也小于保持存活時間keepAliveBetweenTimeMillis，則結束當前循環(huán)，不再檢查連接池中剩余連接。
這里的邏輯其實也是基于connections的特性：數(shù)組第一個元素空閑時間最長，從左到右的空閑時間越來越短，如果從左到右檢查過程中發(fā)現(xiàn)當前元素空閑時間沒有達到需要回收的時長的話，就沒必要檢查連接池中后續(xù)的元素了。
否則如果當前連接空閑時長idleMillis大于等于minEvictableIdleTimeMillis的話，則判斷checkTime && i < checkCount的話則將當前連接放入evictConnections中準備回收。此處i < checkCount的意思就是，回收后的連接數(shù)量仍然能夠確保最小空閑連接數(shù)的要求，則直接回收當前連接。
否則，就是i>=checkCount情況，這種情況下如果發(fā)生回收的話，必然會導致連接池中的剩余連接數(shù)不能滿足參數(shù)設置的最小空閑連接數(shù)的要求、必須要重新創(chuàng)建連接了。但是如果空閑時長大于maxEvictableIdleTimeMillis，也必須是要回收的，所以，將當前連接放入evictConnections準備回收。
有關連接回收，多說一句，連接池參數(shù)maxEvictableIdleTimeMillis一般會根據(jù)數(shù)據(jù)庫端的參數(shù)進行配置，連接閑置超過一定時長的話，數(shù)據(jù)庫會主動關閉連接，這種情況下即使應用端連接池不關閉連接，該連接也不可用了。所以為了確保連接可用，一般情況下應用端數(shù)據(jù)庫連接池的maxEvictableIdleTimeMillis應該設置為小于數(shù)據(jù)庫端的最大空閑時長。
然后判斷如果keepAlive（參數(shù)設置，默認false）并且當前連接的空閑時間idleMillis大于等于參數(shù)設置的?；顣r長keepAliveBetweenTimeMillis的話，則當前連接放入keepAliveConnections中?；睢?/p>
接下來：
} else {
if (i < checkCount) {
evictConnections[evictCount++] = connection;
} else {
break;
}
}
}就是checkTime=false的情況，意思就是不檢查空閑時長，那么能夠確保最小空閑連接數(shù)的前提下，其他連接都可以回收，所以要把connections中小于checkCount（(i < checkCount）的連接全部放入evictConnections中回收。
連接池中的連接檢查完畢，該回收連接放在evictConnections中，該?；畹姆旁趉eepAliveConnections中。接下來的代碼開始真正處理回收和保活。
清理連接池connections
int removeCount = evictCount + keepAliveCount;
if (removeCount > 0) {
System.arraycopy(connections, removeCount, connections, 0, poolingCount - removeCount);
Arrays.fill(connections, poolingCount - removeCount, poolingCount, null);
poolingCount -= removeCount;
}計算需要移除的連接數(shù)量removeCount等于回收數(shù)量與保活數(shù)量之和，然后將connections中的位于removeCount之后的元素前移，使其處于connnections數(shù)組的頭部，并重新計算poolingCount。
接下來計算?；顢?shù)量
keepAliveCheckCount += keepAliveCount;
if (keepAlive && poolingCount + activeCount < minIdle) {
needFill = true;
}
} finally {
lock.unlock();
}累加keepAliveCheckCount，并且判斷如果連接池數(shù)量小于最小空閑數(shù)的話，設置needFill為true。
釋放鎖資源。
然后回收連接：
if (evictCount > 0) {
for (int i = 0; i < evictCount; ++i) {
DruidConnectionHolder item = evictConnections[i];
Connection connection = item.getConnection();
JdbcUtils.close(connection);
destroyCountUpdater.incrementAndGet(this);
}
Arrays.fill(evictConnections, null);
}將evictConnections中的連接逐個回收：關閉連接，并累加destroyCount，并重新初始化evictConnections。
接下來處理?；钸B接：
if (keepAliveCount > 0) {
// keep order
for (int i = keepAliveCount - 1; i >= 0; --i) {
DruidConnectionHolder holer = keepAliveConnections[i];
Connection connection = holer.getConnection();
holer.incrementKeepAliveCheckCount();
boolean validate = false;
try {
this.validateConnection(connection);
validate = true;
} catch (Throwable error) {
if (LOG.isDebugEnabled()) {
LOG.debug("keepAliveErr", error);
}
// skip
}
boolean discard = !validate;
if (validate) {
holer.lastKeepTimeMillis = System.currentTimeMillis();
boolean putOk = put(holer, 0L);
if (!putOk) {
discard = true;
}
}
if (discard) {
try {
connection.close();
} catch (Exception e) {
// skip
}
lock.lock();
try {
discardCount++;
if (activeCount + poolingCount <= minIdle) {
emptySignal();
}
} finally {
lock.unlock();
}
}
}
this.getDataSourceStat().addKeepAliveCheckCount(keepAliveCount);
Arrays.fill(keepAliveConnections, null);
}逐個處理keepAliveConnections中的連接
調用validateConnection方法檢查當前連接是否可用，如果連接仍然可用，則更新連接的lastKeepTimeMillis為當前系統(tǒng)時間后，調用put方法將連接重新放回連接池connections中。如果放回失敗則關閉連接。連接關閉后檢查當前連接池數(shù)量activeCount + poolingCount <= minIdle則調用emptySignal();創(chuàng)建連接。
之后將keepAliveCount加入到連接統(tǒng)計分析數(shù)據(jù)中，重置keepAliveConnections數(shù)組。
最后：
if (needFill) {
lock.lock();
try {
int fillCount = minIdle - (activeCount + poolingCount + createTaskCount);
for (int i = 0; i < fillCount; ++i) {
emptySignal();
}
} finally {
lock.unlock();
}
} else if (onFatalError || fatalErrorIncrement > 0) {
lock.lock();
try {
emptySignal();
} finally {
lock.unlock();
}
}
}檢查如果needFill，說明當前連接池數(shù)量不能滿足參數(shù)設置的最小空閑連接數(shù)，則獲取鎖資源，計算需要創(chuàng)建的連接數(shù)，調用emptySignal();創(chuàng)建連接填充連接池直到連接數(shù)滿足要求。
否則，如果發(fā)生錯誤onFatalError，說明有可能創(chuàng)建連接發(fā)生錯誤，則調用emptySignal()，檢查并繼續(xù)創(chuàng)建連接。
Druid連接回收部分的代碼分析完畢！
小結
通過兩篇文章學習分析了Druid連接池的初始化及連接回收過程，還有連接獲取及關閉兩部分重要內(nèi)容，下一篇文章繼續(xù)分析，更多關于java連接池Druid連接回收的資料請關注腳本之家其它相關文章！
相關文章
這篇文章主要介紹了Java并發(fā)CopyOnWrite容器原理解析,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-01-01
這篇文章主要介紹了java編寫的簡單移動方塊小游戲代碼,涉及Java簡單圖形繪制與事件響應的相關技巧,需要的朋友可以參考下2015-12-12
如何使用intellij IDEA搭建Spring Boot項目
這篇文章主要介紹了如何使用intellij IDEA搭建Spring Boot項目,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下2020-07-07
這篇文章主要為大家詳細介紹了java實現(xiàn)簡單猜拳小游戲，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2021-11-11
通過重寫Schedu lingConfigurer方法實現(xiàn)對定時任務的操作，單次執(zhí)行、停止、啟動三個主要的基本功能，動態(tài)的從數(shù)據(jù)庫中獲取配置的定時任務cron信息，通過反射的方式靈活定位到具體的類與方法中2023-02-02
java文件操作報錯:java.io.FileNotFoundException(拒絕訪問)問題
在進行編程時,經(jīng)常會遇到因疏忽小細節(jié)而導致的錯誤,如忘記在路徑后添加文件名,本文通過一個具體的修改前后對比示例,解釋了錯誤原因,并給出了解決方案,這類經(jīng)驗分享對編程學習者具有參考價值2024-10-10
這篇文章主要給大家介紹了關于Spring Boot啟動banner定制的相關資料，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧。2018-03-03
文件上傳是許多項目都有的功能,用戶上傳小文件速度一般都很快,但如果是大文件幾個g,幾十個g的時候,上傳了半天,馬上就要完成的時候,網(wǎng)絡波動一下,文件又要重新上傳,所以本文給大家介紹了Java實現(xiàn)瀏覽器大文件上傳的示例,需要的朋友可以參考下2024-07-07
這篇文章主要介紹了2020 IDEA安裝教程與激活(idea2020激活碼),本文通過圖文并茂的形式給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2020-11-11
@Transactional注解是Spring提供的一種聲明式事務管理方式，這篇文章主要為大家詳細介紹了@Transactional注解的原理分析及使用，需要的可以參考一下2023-05-05