上图是tcp连接主动关闭端的状态转换图：
（1）应用层调用close函数发起关闭连接请求
（2）发送FIN到对端，关闭写通道，自己进入FIN_WAIT1状态
（3）等待对端的确认ACK到来，接受到ACK后进入FIN_WAIT2状态；如果在超时时间内没有收到确认ACK直接进入CLOSED状态
（4）如果在FIN_WAIT1状态时收到了对端的FIN则进入CLOSING状态（双发都发出了关闭连接请求）
（5）在FIN_WAIT2接受到了对端FIN后进入TIME_WAIT状态；如果在超时时间内没有收这个FIN则直接进入CLOSED状态
（6）在TIME_WAIT状态等待2个MSL（2个报文最长存活周期）后进入CLOSED状态
被动关闭TCP链接端状态转换图
上图是tcp连接被动关闭方的状态转换图
（1）收到对端FIN后，关闭读通道进入CLOSE_WAIT状态
（2）在CLOSE_WAIT状态等待应用层调用close函数关闭连接
（3）如果在超时时间内调用了close，则进入LAST_ACK状态；否则直接进入CLOSED状态
（4）在LAST_ACK状态，发送FIN到对端并等待对端的确认ACK
（5）如果在超时时间内收到了确认ACK则进入CLOSED状态，否则直接进入CLOSED状态
状态分析
FIN_WAIT1
主动方调用close函数关闭连接后立刻进入FIN_WAIT1状态，此时只要收到对端确认ACK后马上会进入FIN_WAIT2状态。
出现场景：主动方等待ACK过程中网络断掉了，导致长时间收不到ACK，主动方就会停留在CLOSE_WAIT1状态上（超时时间：一般默认60s超时）。此时我们可以使用netstat -anpt 命令看到这种状态。这个状态在实际的工作中很少见。
FIN_WAIT2
主动端在等待对端FIN到来过程中，会一你直保持这个状态（超时时间：一般默认是60s）。由于网络中断，或者对端很忙还没来得及发送FIN、或者对端有bug忘记关闭连接等都会导致主动端长时间处于FIN_WAIT2状态。如果主动方发现大量FIN_WAIT2状态时，应该引起相关人员的注意，这可能是网络不稳、对端程序bug的表现。 这个状态比较常见。
TIME_WAIT
主动方收到对端的FIN后进入TIME_WAIT状态。然后发送最后一个确认ACK到对端。之后等待2个最大的报文存活周期，正常的关闭流程客户端TCP连接都会经过这个状态，最终进入CLOSED状态。所以我们使用netstat -anpt命令发现客户端有很多的TIME_WAIT，一般这是正常的现象。 这个状态最常见。
CLOSING
双发几乎同时都调用了close接口主动关闭连接，此时都进入了FIN_WAIT1状态。如果在FIN_WAIT1状态期望收到对方的ACK但却收到了对方的FIN，这时候双方都进入CLOSING状态。然后都给对方一个ACK确认，收到了ACK后就会进入CLOSED状态了。
CLOSE_WAIT
这个状态表明TCP连接等待被关闭。只可能在被动方出现。如果被动方存在大量的CLOSE_WAIT状态需要因为我们的特别注意了。我们要仔细研究确认为什么被动方迟迟不愿关闭连接（或许是我们程序中的bug开启了连接，用完后却忘记关闭）
目前开发过程中遇到如下这个场景导致被动方有很多的CLOSE_WAIT状态：
A是一个应用程序，B是一个tomcat服务器
A开了一个连接Conn，发送请求给B
A接受相应数据后没有调用Conn.close关闭连接，在A端垃圾回收这些Conn对象前，这些连接一直保持着
B端的连接超时后会主动发起关闭连接请求给A，此时A进入了CLOSE_WAIT状态，B进入了FIN_WAIT2状态，由于A迟迟不发送FIN给B，B端触发timeout直接进入了CLOSED状态。
这样一个场景B端由于有超时设置一个为60s，不会存在大量的FIN_WAIT2状态
但是A端就会残留大量的CLOSE_WAIT状态（CLOSE_WAIT状态也有超时，但是太大，默认为43200s，详情见tcp_timeout_close_wait系统配置）。还好A端的java虚拟机的最大对内存配置较小，由于CLOSE_WAIT状态连接同样占用了内存资源，数量很多后就会触发垃圾回收，此时A端的CLOSE_WAIT的连接Conn对象就会被销毁了（同时内存和句柄、端口等资源也被释放了）
LAST_ACK
当被动端调用close接口关闭连接后便会进入这个状态，同时发送一个FIN给对端。在接受对端的ACK确认后便会进入CLOSED状态，这个状态一般不易出现，除非网络中断，一般对端会很快给与响应的。这个状态只可能在被动端出现。
状态总结
主动端可能出现的状态：FIN_WAIT1、FIN_WAIT2、CLOSING、TIME_WAIT
被动端可能出现的状态：CLOSE_WAIT LAST_ACK
NOTE：
（1）主动端出现大量的FIN_WAIT1时需要注意网络是否畅通、出现大量的FIN_WAIT2需要仔细检查程序为何迟迟收不到对端的FIN（可能是主动方或者被动方的bug）、出现大量的TIME_WAIT需要注意系统的并发量/socket句柄资源/内存使用/端口号资源等。
（2）被动端出现大量的 CLOSE_WAIT 需要仔细检查为何自己迟迟不愿调用close关闭连接（可能是bug，socket打开用完没有关闭）