druid 的 minIdle -》 maxActive 和 hikariCP 的 minimumIdle -》 maximumPoolSize， 他們都是為了維護連接池內有足夠的連接可用， 並且應對一定的流量突增； 這一點和線程池的 corePoolSize =》maxPoolSize 語義類似
執行邏輯
當前總連接數 = 池內連接數(空閑) + 活躍連接數
在總連接不超過 max 的前提下，如果池內空閑連接數 < minIdle ， 則會去創建連接
線程池 ThreadPoolExecutor 里邊的線程其實 worker角色， corePoolSize 這些線程是一直處於工作狀態的，
而db連接池只是連接資源的容器，歸還到db連接池內的連接就是空閑的，所以是 minIdle
一般建議 minimumIdle 和 maximumPoolSize 設置成一樣大，因為db連接建立非常耗時；
比如hikariCP就直接建議不單獨設置 minimumIdle，默認和max一樣大
for maximum performance and responsiveness to spike demands, we recommend not setting this value and instead allowing HikariCP to act as a fixed size connection pool. Default: same as maximumPoolSize
可以把 minIdle 概念換成 minSize最小連接數（空閑+活躍）嗎？
那么當前連接數小於 minSize 就直接判斷需要創建新的連接； 當前連接數 == minSize后，如果再次申請連接，這個時候要去判斷空閑狀態的是否夠用，不夠用才去繼續創建連接 直到 max； 從這個角度看是可以的
空閑超時檢測，minSize 內和 min ~ max之間的時長區別，邏輯上也是可以
區別是，當較繁忙的時候 (active連接較多)，minIdle 的判斷邏輯會比minSize更早就去填充連接池 性能更優
總之，代碼邏輯要和語義匹配