tcp端口被一直占用，kill進(jìn)程沒用

flyfeel

今天遇到一個(gè)很奇怪的現(xiàn)象，將自己的一個(gè)demo進(jìn)程kill掉后，他占用的端口8888又被其他進(jìn)程占用了，一直到將所有自己的進(jìn)程殺完后，端口才得到釋放。
因?yàn)檫@些進(jìn)程都是自己的，很清楚沒有用過該端口，我能想到唯一有關(guān)聯(lián)的是這幾個(gè)自己的進(jìn)程都是通過init.d自啟拉起的，會(huì)不會(huì)資源都被init.d接管了？

1. [root@server Service]# netstat -antp | grep 8888
   
2. tcp        0      0 0.0.0.0:8888                0.0.0.0:*                   LISTEN      2848/java           
   
3. tcp        0      0 192.168.20.195:8888         192.168.20.104:59125        ESTABLISHED 2848/java           
   
4. [root@server Service]# kill -9 2848
   
5. [root@server Service]# netstat -antp | grep 8888
   
6. tcp        0      0 0.0.0.0:8888                0.0.0.0:*                   LISTEN      2913/java           
   
7. tcp        0      0 192.168.20.195:8888         192.168.20.104:59125        ESTABLISHED 2913/java           
   
8. [root@server Service]# kill -9 2913
   
9. [root@server Service]# netstat -antp | grep 8888
   
10. tcp        0      0 0.0.0.0:8888                0.0.0.0:*                   LISTEN      2972/sh            
    
11. tcp        0      0 192.168.20.195:8888         192.168.20.104:59125        ESTABLISHED 2972/sh            
    
12. [root@server Service]# kill -9 2972
    
13. [root@server Service]# netstat -antp | grep 8888
    
14. tcp        0      0 0.0.0.0:8888                0.0.0.0:*                   LISTEN      3294/mysqld         
    
15. tcp        0      0 192.168.20.195:8888         192.168.20.104:59125        ESTABLISHED 3294/mysqld         
    
16. [root@server Service]# kill -9 3294
    
17. [root@server Service]# netstat -antp | grep 8888
    
18. tcp        0      0 0.0.0.0:8888                0.0.0.0:*                   LISTEN      3359/Alarm
    
19. tcp        0      0 192.168.20.195:8888         192.168.20.104:59125        ESTABLISHED 3359/Alarm
    
20. [root@server Service]# netstat -antp | grep 8888
    
21. tcp        0      0 192.168.20.195:8888         192.168.20.104:59125        FIN_WAIT2   -

復(fù)制代碼

yjh777

FIN_WAIT2 狀態(tài)，

百度 bing 一下看看

yjh777

有一些客戶端在處理持久連接(aka keepalives)時(shí)存在問題。當(dāng)連接空閑下來服務(wù)器關(guān)閉連接時(shí)(基于KeepAliveTimeout指令)， 客戶端的程序編制使它不發(fā)送FIN和ACK回服務(wù)器。這樣就意味著這個(gè)連接 將停留在FIN_WAIT_2狀態(tài)直到以下之一發(fā)生：
客戶端為同一個(gè)或者不同的站點(diǎn)打開新的連接，這樣會(huì)使它在該個(gè)套接字上完全關(guān)閉以前的連接。
用戶退出客戶端程序，這樣在一些(也許是大多數(shù)？)客戶端上會(huì)使操作系統(tǒng)完全關(guān)閉連接。
FIN_WAIT_2超時(shí)，在那些具有FIN_WAIT_2狀態(tài)超時(shí)設(shè)置的服務(wù)器上。
如果你夠幸運(yùn)，這樣意味著那些有缺陷的客戶端會(huì)完全關(guān)閉連接并釋放你服務(wù)器的資源。 然而，有一些情況下套接字永遠(yuǎn)不會(huì)完全關(guān)閉，比如一個(gè)撥號(hào)客戶端在關(guān)閉客戶端程序之前從ISP斷開。 此外，有的客戶端有可能空置好幾天不創(chuàng)建新連接，并且這樣在好幾天里保持著套接字的有效即使已經(jīng)不再使用。 這是瀏覽器或者操作系統(tǒng)的TCP實(shí)現(xiàn)的Bug。
3、如何解決 www.2cto.com
為 FIN_WAIT_2 增加 超時(shí)機(jī)制