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

最新推荐文章于 2024-08-27 15:30:51 发布

独行客-编码爱好者

最新推荐文章于 2024-08-27 15:30:51 发布

阅读量1.5k

点赞数

分类专栏： java 基础知识文章标签： java 连接池

本文链接：https://blog.csdn.net/donkeyboy001/article/details/119353660

版权

java 基础知识专栏收录该内容

39 篇文章 0 订阅

订阅专栏

参考：https://blog.csdn.net/qq_42763389/article/details/82906354

问题出现原因浮现：

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

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

TCP连接关闭的状态图：

TCP连接终止协议（TCP 四次挥手）

因为tcp 连接是全双工的（即数据在两个方向上能同时传递，可理解为两个方向相反的独立通道），因此每个方向都必须单独进行关闭。这原则是当一方完成数据发送任务后就能发送一个FIN来终止这个方向的连接。当一端收到FIN，内核让read返回0来通知应用层另一端已经终止了向本端的数据传送。发送FIN通常是应用层对socket关闭的结果。

对上述状态图进行拆分：

（图一）

1）ESTAB状态发送FIN即切换到FIN_WAIT1 状态；

2）FIN_WAIT1状态下收到针对FIN的ACK即可离开FIN_WAIT1到达FIN_WAIT2

（图二）

1）CLOSE_WAIT 状态下发送FIN切换到LAST_ACK 状态

2）LAST_ACK 状态下接收到针对FIN的ACK 即可由CLOSE_WAIT 切换到CLOSED 状态

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状态下，需要完成的事情是等待你去关闭连接。

LAST_ACK: 表示被动关闭方发送FIN报文后，等待对方的ACK报文状态，当收到ACK后进入CLOSED状态。

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检测连接是否有效，做了这个配置会降低性能(可以不开启)

Druid 连接池配置完整版：

# Druid DataSource Info
#com.alibaba.druid.pool.DruidDataSource
spring.datasource.filters=mergeStat,log4j
spring.datasource.maxActive=20
spring.datasource.initialSize=1
spring.datasource.maxWait=60000
spring.datasource.minIdle=1
#配置隔多少时间启动销毁线程，
#如果如果空闲时间大于minIdle并超过minEvictableIdleTimeMillis　直接物理关闭
#小于minIdle不处理
spring.datasource.timeBetweenEvictionRunsMillis=60000
#池中某个连接的空闲时间长达到Ｎ毫秒后，连接池在下次检查空闲连接时，回收连接
spring.datasource.minEvictableIdleTimeMillis=300000
#检测归还连接是否有效
spring.datasource.testOnBorrow=true
#检测获取的连接是否有效
spring.datasource.testOnReturn=false
spring.datasource.testWhileIdle=true
spring.datasource.poolPreparedStatements=true
spring.datasource.maxOpenPreparedStatements=20
spring.datasource.removeAbandoned=true
spring.datasource.removeAbandonedTimeout=1800
# Show the slow sql
spring.datasource.connectionProperties=druid.stat.mergeSql=true;druid.stat.slowSqlMillis=5000

独行客-编码爱好者

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
打赏
0
评论
Druid 连接池配置的详解及使用时后台出现大量的close_wait 的日志信息

参考：https://blog.csdn.net/qq_42763389/article/details/82906354问题出现原因浮现：使用druid连接池建立inceptor连接时，每过四个小时出现大量的CLOSE_WAIT状态的日志，说明套接字是被动关闭的！（被数据库关闭的）通过查看inceptor配置，发现inceptor有连接保护机制，如果连接超过4个小时，会关闭连接,这个时候连接是被数据库被动关闭的，所以会出现CLOSE_WAIT状态。因为如果是web端主动断掉...
复制链接

扫一扫