Druid连接池源码解析（9）pool包小结

1 pool包

pool包是Druid连接池的核心包之一，主要实现了数据库连接池化的功能；
连接池的产生的缘由，我自己拍脑门想了一下大概是这样的：

• 数据库连接的创建和销毁太消耗资源了，于是有了长链接
• 维护一个长链接在并发的时候肯定是不够用的，于是就需要很多个连接
• 多个连接的情况下，就会需要有调度策略，来一个请求，如何分配一个连接
• 连接用完了不销毁，则需要回收，下次继续分配给需要的请求
• 要保持大量的连接也很耗费资源，于是需要控制连接的数量
• 并不是所有的连接都是活跃的，空闲的连接时间长了难免会出现异常，在MySQL中也有服务端废弃策略等情况，于是就有了连接可用性的检测，确保从连接池拿出去的连接都是可用的， 不用业务自己校验
• 出现了异常的连接，需要废弃释放系统资源

上述粗体便是一个连接池的基础功能了， 有机缘可以试着自己手撸

---

Driud在基本功能之上，还封装了HA，多个数据源的高可用，在多数据源的情况下，对XA事务的支持；
在数据库操作上，增强了Statement的能力，增加了语句的池化、缓存，更适配池化的连接场景
当然还有最重要的监控、统计的功能，给数据库操作的优化提供了数据支撑

2 连接的状态

在保持长连接的情况下，各个连接的状态在不断的变换，加上并发的情况，对于连接的状态控制就非常重要，Druid定义了许多额外的连接状态，加上非常细粒度的ReentrantLock的，很精妙地控制着连接的状态

基础状态的流转.png

状态	说明
active	活动状态,默认值为false,getConnectionInternal之后设置为true,discardConnection设置为false,recycle如果物理连接被关闭或者测试连接不通，以及回收成功，都修改为false
running	运行状态，执行Statement之前的beforeExecute设置为true,执行完成之后afterExecute方法设置为false
closed	关闭状态，recycle到连接池中的连接会修改为true，判断连接是否关闭需要结合(closed or disable)
disable	不可用状态，当连接出现异常调用handleFatalError之后，将此状态设置为true
discard	关闭状态，默认为false,调用discardConnection方法 或者recycle出现异常的时候改为true,之后关闭连接
traceEnable	traceEnable跟踪开关，默认为false,这个开关配合abandoned使用，当DruidDataSource开启removeAbandoned之后，这个状态设置为true,当连接从activeConnections中取出的时候，设置为false
***abandoned ***	*** 连接废弃检测状态，默认为false,当removeAbandoned开始执行之后，对执行超时的连接设置状态为true，然后统一close，与disable&close强相关***

3 监控

监控则是在DruidDataSource中直接定义了很多需要统计的维度字段,通过对MBean的实现，能够在运行时快速获取当前数据源的统计信息，并辅以StatFilter，用责任链的设计模式，能够灵活配置需要监控的对象；
另外定义了各种StatManager，分别管理DataSource、Connection、Statement、ResultSet等各环节组件的状态