java druid活跃数占满 druid poolingcount

在Druid连接池的工作过程中，会用到一些计数器对Druid的情况进行判断。然后根据计数器的数据采取一系列操作，整理如下:

1.统计类的计数器

变量名	类型	说明
connectCount	long	getConnectionInternal被调用之后就会增加，意味着连接被get的次数。
closeCount	long	连接调用recycle中，包括回收、关闭等情况，成功之后会增加，标识连接关闭的次数。
recycleCount	long	连接调用recycle成功之后才会增加，不包括在回收过程中关闭的情况。标识连接真正回收的次数。
removeAbandonedCount	long	连接调用removeAbandoned成功之后才会增加，标识连接跟踪泄露机制的执行次数。
notEmptyWaitCount	long	连接调用pollLast或者tackLast之后就会增加，实际上是触发notEmpty.await的的次数.
notEmptySignalCount	long	连接触发notEmpty的signal的次数。
discardCount	volatile long	调用discard成功之后的次数。

上述long类型的计数器，全部只会增加，不会减少，在Druid工作的过程中进行统计和监控作用。

2.状态相关的计数器

变量名	类型	说明
poolingCount	int	DruidConnectionHolder[] connections数组中连接的数量。
activeCount	int	Map<DruidPooledConnection, Object> activeConnections 中的连接数量。
notEmptyWaitThreadCount	int	连接被取出之后，触发notEmpty进行wait线程的数量。
activePeak	int	activeCount出现的峰值。
poolingPeak	int	poolingCount出现的峰值。
createTaskCount	int	创建连接线程数的计数器。

3.相关的判断逻辑：

poolingCount < initialSize 时，创建连接以达到初始化连接数。 poolingCount >= maxActive 时，回收的连接会被拒绝放入connections中。

activeCount + poolingCount >= maxActive时， empty.await()，创建连接的线程会被取消。 activeCount + poolingCount <= minIdle 时，通知emptySignal(),通知继续创建连接。 keepAlive && poolingCount + activeCount < minIdle 时，再shrink方法中needFill为true,会触发通知emptySignal(),继续创建连接。 activeCount + poolingCount + createTaskCount >= maxActive 时，开启了createScheduler，则会取消createScheduler的创建任务。 activeCount <= minIdle 时，触发emptySignal()，创建连接。

4.存储Connection的容器

变量名	类型	说明
connections	DruidConnectionHolder[]	连接存放的数组。
keepAliveConnections	DruidConnectionHolder[]	keepAlive连接存放的数组。只会在shrink中开启了keepalive才会使用。
evictConnections	DruidConnectionHolder[]	需要关闭的连接存放的数组。shrink中该数组中的连接都会被关闭掉。
activeConnections	Map<DruidPooledConnection, Object>	getConnection之后，存放的容器。

5.思考的问题

问题：既然poolingCount，和activeCount都与其容器的数量一致，为什么不直接使用数组的length或者map的size. 另外一个问题，为什么不使用类似于线程持的状态机。状态定义得比较混乱。

------------------------------------------------------------------
-----------------------------------------------------------
---------------------------------------------
朦胧的夜 留笔~~