Druid连接池源码解析（4）Connection

1 获取Connection

DruidDataSource初始化完成后，即可获取connection与数据库进行交互了。
获取如果有Filter，从filterChain中获取connection，否则调用getConnectionDirect()直接获取。
两者返回的都是经过封装的DruidPooledConnection，类图：

DruidPooledConnection.png

看下构造函数，需要传入holder，从中获取实际的Connection
扩展定义了abandoned、running、disable和close的状态
beforeExecute()和afterExecute() 处理running状态的修改，影响DataSource中的removeAbandoned(),执行中的connection跳过清理
abandoned 在recycle()中影响是否回收
disable和close用处比较多，主要就是标记连接是否可用

2 getConnection详解

getConnectionDirect()方法开始，主要流程：

• 死循环开始直到获取可用链接为止
• 调用getConnectionInternal获取DruidPooledConnection
• 如果testOnBorrow为true，则进行对连接进行校验
• 如果testWhileIdle为true，距离上次激活时间超过timeBetweenEvictionRunsMillis，则进行清理。
• 如果removeAbandoned为true，则会把连接存放在activeConnections中，清理线程会对其定期进行处理。

getConnectionInternal()方法，主要流程：

• 检查等待线程数和错误线程数，超过设置了，抛异常
• createScheduler存在且可用，标志位createDirect置为true，重新开始循环，进入直接创建连接流程，创建新的物理连接和holder，加锁校验连接数有没有超设置，超过便discord，否则即完成创建
• 调用pollLast(nanos)-有超时，或者 takeLast()获取holder，如果获取holder失败，构建异常消息，抛异常
• 否则，以holder为参new一个DruidPooledConnection返回

takeLast()主要就是从连接数组中获取最后一个可用的返回

获取到链接之后，就可以调用conn.prepareStatement来执行sql了

3 连接回收

DruidPooledConnection实现了JDBC的close方法，
从holder中获取Datasource，判断当前线程是否归属线程，不是的话，就加锁关闭
否则直接进行关闭
分发当前连接关闭的事件到ConnectionEventListener
最终都到recycle()方法中进行回收，而不是真正的关闭，主要流程如下：
同样判断当前线程是否归属线程，不是的话，就加锁操作
将当前线程从活跃线程组 activeConnections 中移除，主要是方便后面的丢弃或者回收的工作。
然后检查是否需要进行回滚，不需要继续往下走。
reset 当前 connection 的 holder 的相关配置。
接下来是对各项信息进行检查，主要是看连接是否还可以重用。
锁住然后进行真正的回收工作，这里回收交给了 putLast 方法。
putLast 呼应前面的takeLast，就是把连接放回connections数组中

4 总结

获取和回收连接的过程中，定义了一大堆状态和计数器，主要用于统计和各种加锁的场景，锁的粒度已经控制得非常精细了。比想象地要复杂很多，锁的粒度精细化有助于提高并发场景的性能，但是带来的代码复杂度的提升不是一点点。实际工程中，不仅要平衡两者，还要对自己加锁的操作，有100%的确信度。