您好,登錄后才能下訂單哦!
小編給大家分享一下怎么解決TCP socket的阻塞問題,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
大家知道,tcp的讀和寫是阻塞的,即讀的時候不知道什么時候讀完,寫的時候不知道什么時候寫完,因此線程就一直暫停在哪里,一般tcp程序用在上位機下位機之間對吧!
下位機一些設備一般會發心跳報文給我們機器,假設為10s發一次吧,當機器超過10s沒接收到數據,那么我們就要考慮把socket斷開,因為不斷開的話設備重新連接可能又會建立新的socket,這樣如果設備反復斷開連接的話,將產生大量的socket,占用大量系統資源,這里我們用socket.setSoTimeout(500)方法解決read方法的阻塞問題,同時設定一個標志位
public void run(){ InputStream is = null; OutputStream os = null; int flag = 0; try { socket.setSoTimeout(500); // 0.5秒就退出read()方法的阻塞 is = socket.getInputStream(); os = socket.getOutputStream(); } catch (Exception e2) { e2.printStackTrace(); } while (true) { try { // 讀取數據 int readlen = is.read(buff); if (readlen > 0) { flag = 0; } byte data[] = Arrays.copyOfRange(buff, 0, readlen); resolveData(data); } catch (IOException e) { try { flag++; if (flag == 200) { is.close(); os.close(); socket.close(); } } catch (Exception e1) { e1.printStackTrace(); } } } }
那么,什么樣的TCP連接屬于上述發生阻塞的異常連接呢?結合線上運維經驗
該連接的Recv_Q的值特別大(超過3M)
該連接的Recv_Q的值持續上漲,造成堆積(在一定滑動時間窗口內)
服務端進程已長時間不再處理該連接的請求(超過90秒)
其中Recv_Q的值可以通過netstat或ss系統工具即可進行Recv_Q隊列大小的采樣,從而進行閥值判斷。
netstat 的結果是讀取/proc/net/tcp文件而來的.
1.nestat -apn | grep xxx查看到對應的連接的進程pid和端口
2. 將上下游端口,轉換為16進制xxxa xxxb
3.然后cat /proc/net/tcp | grep -i xxxa | grep -i xxxb找到該socket連接的inode inodex
4.ls -al /proc/pid/fd | grep inodex即可看見該socket文件的創建時間.
以上是“怎么解決TCP socket的阻塞問題”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。