参考: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
#池中某个连接的空闲时间长达到N毫秒后,连接池在下次检查空闲连接时,回收连接
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