6

たとえば、呼び出してソケットを開いたり閉じたりすると

Socket s = new Socket( ... );
s.setReuseAddress(true);
in = s.getInputStream();
...
in.close(); 
s.close();

Linux は、このソケットがまだ開いているか、少なくとも接続用のファイル記述子が存在すると述べています。このプロセスの開いているファイルを lsof で照会すると、閉じられた接続のエントリがあります。

COMMAND  PID   USER   FD   TYPE DEVICE     SIZE   NODE NAME
java    9268 user    5u  sock    0,4           93417 can't identify protocol

このエントリは、プログラムが終了するまで残ります。最終的にソケットを閉じる他の方法はありますか? Java アプリケーションが多くのファイル記述子をブロックするのではないかと少し心配しています。これは可能ですか？または、ReuseAdress が設定されていても、Java はこれらのソケットを再利用するために保持しますか?

4

5 に答える 5

5

それらのソケットがすべて TIME_WAIT 状態にある場合、少なくともしばらくの間は正常です。netstat で確認してください。新しいソケットのポートを再利用する前に、ソケットからの散在するデータが正常に破棄されるように、ソケットが数分間ぶらぶらするのが一般的です。

于 2009-01-09T21:40:48.997 に答える
3

を確認することもでき/proc/<pid>/fdます。ディレクトリには、現在開いているすべてのファイル記述子が含まれます。ソケットを閉じた後にファイルが消えても、問題は発生しません (少なくともファイル記述子に関しては:)。

于 2009-01-09T23:04:55.300 に答える
1

あなたのプログラムの問題ではないと思います。

SUN_Java では、ソケット関連のネイティブ lib をロードすると、MAGIC_SOCK fd が作成されます。

MAGIC_SOCK への書き込みは Connect Rest Exception となり、MAGIC_SOCK への読み取りは EOF となります。

magic_sock のピアは完全に閉じられており、magic_sock 自体は half_closed であり、状態は「プロトコルを識別できません」のままになります。

于 2011-12-09T08:08:23.507 に答える
0

たぶんそれは、最初のソケットで作成される何かを行うために実装で内部的に使用される他のプロトコルのソケットです (「プロトコルを識別できません」ですか?)。

これらのソケットが本当に存続するかどうかを確認するために、ソケットの作成とクローズを繰り返してみましたか? これは一過性の可能性が高いと思われます。

Java はおそらく多くのことのためにソケットを内部的に使用します - それらは Unix、Netlink (Linux の下)、または他のタイプのソケットかもしれません。

于 2009-01-09T21:19:39.897 に答える
0

特定のアプリまたは pid の開いているソケットを監視する小さな bash スクリプトを作成し、Java アプリのテスト中に実行します。

とにかく、ソケットはLinux / UNIXの世界で非常に使用されており、この種の問題は非常に迅速に発生するため、このことに何らかのリークがあるとは思えません

于 2009-01-09T22:47:29.140 に答える