druid数据库连接池在使用中遇到的一些问题和说明
get connection timeout retry : 1
2024-02-06 11:18:26.364 ERROR 23752 --- [eate-1838225797] com.alibaba.druid.pool.DruidDataSource : create connection SQLException, url: jdbc:oracle:thin:@192.168.66.88:1521:orcl, errorCode 17002, state 08006
有正在执行的SQL时，连接不可用就会触发重试，进而报错。
com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 20000, active 68, maxActive 200, creating 1, createElapseMillis 3099, createErrorCount 7, runningSqlCount 68 : SELECT xxx
breakAfterAcquireFailure默认是false,意思是重试失败可以一直尝试，也就是当数据库恢复、网络恢复时，数据库连接也会跟着恢复。
正常情况是这样的，除非发现有连接泄露。是在不行就立即平滑重启先。
有时候看到数据库连接异常日志，未必是数据库服务器、网络等问题，也未必是数据库连接池的问题，根本的原因是多样化的。
比如数据库系统、应用系统等对长连接超时的设置。比如应用服务代码问题导致内存不足、CPU不足等原因，应用被判定为不可用进而下线等原因。
低版本的keepAlive属性未设置导致的创建连接失败问题。默认是关闭的。建议直接使用1.2.20以上版本即可
通过JVM启动参数配置
-Ddruid.keepAlive=true
或者springboot的配置姿势。
打开KeepAlive之后的效果
初始化连接池时会填充到minIdle数量。
连接池中的minIdle数量以内的连接，空闲时间超过minEvictableIdleTimeMillis，则会执行keepAlive操作。
当网络断开等原因产生的由ExceptionSorter检测出来的死连接被清除后，自动补充连接到minIdle数量。
Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 60000, active 0, maxActive 100, creating 1, createElapseMillis 686180, createErrorCount 3
还有一种情况是并发量高，超过了线程池的最大连接数时，就会异常：
也就是一直在 “超时”范围内创建不了足够的线程。
org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is com.alibaba.druid.pool.GetConnectionTimeoutException: wait millis 2005, active 13, maxActive 15, creating 1, createElapseMillis 22
最小空闲连接是2，最大Active允许20；minEvictableIdleTimeMillis为31秒，初始化完成后，先运行5个，之后在运行3个
，
ActiveCount就是8个，池中0个
{
CreateTime:"2024-02-07 15:35:54",
ActiveCount:8,
PoolingCount:0,
CreateCount:8,
DestroyCount:0,
CloseCount:0,
ConnectCount:8,
Connections:[
]
}
先运行的5个完成后：将连接放回池中，因此运行中是3个，池中是5
{
CreateTime:"2024-02-07 15:35:54",
ActiveCount:3,
PoolingCount:5,
CreateCount:8,
DestroyCount:0,
CloseCount:5,
ConnectCount:8,
Connections:[
{ID:1630226699, ConnectTime:"2024-02-07 15:36:44", UseCount:1, LastActiveTime:"2024-02-07 15:36:51"},
{ID:1829353693, ConnectTime:"2024-02-07 15:36:45", UseCount:1, LastActiveTime:"2024-02-07 15:36:51"},
{ID:1368894668, ConnectTime:"2024-02-07 15:36:44", UseCount:1, LastActiveTime:"2024-02-07 15:36:51"},
{ID:41020387, ConnectTime:"2024-02-07 15:36:44", UseCount:1, LastActiveTime:"2024-02-07 15:36:51"},
{ID:1931842658, ConnectTime:"2024-02-07 15:36:44", UseCount:1, LastActiveTime:"2024-02-07 15:36:51"}
]
}
等8个都运行完成后，池中剩余3个，是因为配置的minEvictableIdleTimeMillis是31秒，上面的5个在池中已经空闲超过这个时间点
{
CreateTime:"2024-02-07 15:35:54",
ActiveCount:0,
PoolingCount:3,
CreateCount:8,
DestroyCount:5,
CloseCount:8,
ConnectCount:8,
Connections:[
{ID:18126972, ConnectTime:"2024-02-07 15:36:45", UseCount:1, LastActiveTime:"2024-02-07 15:37:41"},
{ID:1695936491, ConnectTime:"2024-02-07 15:36:45", UseCount:1, LastActiveTime:"2024-02-07 15:37:42"},
{ID:978119236, ConnectTime:"2024-02-07 15:36:45", UseCount:1, LastActiveTime:"2024-02-07 15:37:42"}
]
}
再过timeBetweenEvictionRunsMillis时间之后，池中最终剩余2个
{
CreateTime:"2024-02-07 15:35:54",
ActiveCount:0,
PoolingCount:2,
CreateCount:8,
DestroyCount:6,
CloseCount:8,
ConnectCount:8,
Connections:[
{ID:1695936491, ConnectTime:"2024-02-07 15:36:45", UseCount:1, LastActiveTime:"2024-02-07 15:37:42"},
{ID:978119236, ConnectTime:"2024-02-07 15:36:45", UseCount:1, LastActiveTime:"2024-02-07 15:37:42"}
]
}
上面的情况是连接没来得及归还到连接池（比如业务方法执行时间长，或者正在归还时，新的连接请求又来了，那么就会创建新的线程来执行业务）
如果不满足时，就按照设置的从连接池获取连接的超时来异常提示。
当然如果业务方法执行快，连接被复用时是下面这样，useCount就是被复用的次数
{
CreateTime:"2024-02-07 15:58:31",
ActiveCount:0,
PoolingCount:5,
CreateCount:5,
DestroyCount:0,
CloseCount:8,
ConnectCount:8,
Connections:[
{ID:1829353693, ConnectTime:"2024-02-07 15:59:22", UseCount:1, LastActiveTime:"2024-02-07 15:59:27"},
{ID:41020387, ConnectTime:"2024-02-07 15:59:22", UseCount:1, LastActiveTime:"2024-02-07 15:59:27"},
{ID:1931842658, ConnectTime:"2024-02-07 15:59:22", UseCount:2, LastActiveTime:"2024-02-07 16:00:33"},
{ID:1630226699, ConnectTime:"2024-02-07 15:59:22", UseCount:2, LastActiveTime:"2024-02-07 16:00:33"},
{ID:1368894668, ConnectTime:"2024-02-07 15:59:22", UseCount:2, LastActiveTime:"2024-02-07 16:00:33"}
]
}
