Druid 连接池配置的详解及使用时后台出现大量的close_wait 的日志信息

问题出现原因浮现：

    使用druid 连接池建立inceptor 连接时，每过四个小时出现大量的CLOSE_WAIT 状态的日志，说明套接字是被动关闭的！（被数据库关闭的）通过查看inceptor 配置，发现inceptor有连接保护机制，如果连接超过4个小时，会关闭连接,这个时候连接是被数据库被动关闭的，所以会出现CLOSE_WAIT 状态。

 

因为如果是web 端主动断掉当前连接的话，那么双方关闭这个TCP连接共需要四个packet:

TCP连接关闭的状态图：

ESTABLISHED： 表示连接已经建立了。

FIN_WAIT_1:   这个状态要好好解释一下，其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。

 

FIN_WAIT_2： 上面已经详细解释了这种状态，实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接这就是著名的半关闭的状态了，这是在关闭连接时，客户端和服务器两次握手之后的状态。在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于WAIT_CLOSE状态，而直到应用层来决定关闭这个状态

 

TIME_WAIT:   表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。

 

CLOSING:   这里先说一下另一种状态（同时打开）

CLOSE_WAIT:   这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是查看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。

 

 

TCP 状态图：

 

查看系统网络连接

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

LAST_ACK 1
SYN_RECV 15
CLOSE_WAIT 7729
ESTABLISHED 471
FIN_WAIT1 3
FIN_WAIT2 52
SYN_SENT 1
TIME_WAIT 725

如果这些连接超时失效了，连接池为什么还会获取这些失效的连接呢。

这个和druid 连接池的某些配置有关系：

testOnBorrow=false   

由于我们不检测池里连接的可用性，于是假如连接池中的连接被数据库关闭了，应用通过连接池getConnection 时，都可能获取到这些不可用的连接，且这些连接如果

不被其他线程回收的话，它们不会被连接池删除，也不会重新被创建，占用了连接池的名额。

当testOnBorrow=true 时，有两种情况：

①.当服务重启时，如果连接刚好不处于通信阶段，TCP连接正处于CLOSE_WAIT 状态或已关闭，当应用通过连接池getConnection时，在borrow 时会检测连接，由于连接已关闭，于是报了如下错误，并重新建立连接，此时新连接，连接到应用上。后面就可以正常通信了。

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
    at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3143)
    at com.mysql.jdbc.MysqlIO.readPacket(MysqlIO.java:597)
    ... 21 more

② 应用实例宕掉时，如果连接刚好处于通信阶段，由于客户端无法立即感知服务端已断连接，它可能会报如下错误，等待服务端的响应超时报错。当应用通过

连接池getConnection时，在borrow时会检测连接，由于连接已关闭，于是报了如下错误，并重新建立新连接，此时新连接到应用上。通信正常

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 10,538 milliseconds ago.  The last packet sent successfully to the server was 10,306 milliseconds ago.
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

为了避免获取到的连接是不能用的连接，所以应该增加一些配置：

testWhileIdle=true  # 申请连接的时候检测，如果空闲时间大于timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效
timeBetweenEvictionRunsMillis=180000 # 1) Destroy线程会检测连接的间隔时间  2) testWhileIdle的判断依据，详细看testWhileIdle属性的说明
validationQuery=select 1 #用来检测连接是否有效的sql 如果validationQuery为null，testOnBorrow、testOnReturn、testWhileIdle都不会起作用
testOnBorrow=true  # 申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。
testOnReturn=true # 归还连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能(可以不开启)