0

したがって、私の現在のJava実装は次のとおりです。

  1. スレッドを使用して UDP ソケットから UDP パッケージを受信し、パケットを非ブロッキング キューに入れます。
  2. 300 のスレッドの 1 つがこの非ブロッキング キューを読み取り、このパケットを TCP ホスト/ポートに接続されたソケットへの要求として処理します。
  3. 応答を待って、これを UDP ソケットに返します。

この部分はすべて問題なく動作しますが、高負荷時の TCP ソケット部分の分析から、TCP ソケット部分が完了するまでに約 2 ～ 5 秒かかるランダムなケースがあることがわかりました。通常、この部分には 2 ～ 3 ミリ秒かかります。私の疑問は、ランダムなスレッド実行で TCP ソケットをヒットしているだけで、スレッド操作の FIFO がないことです。

「要求」情報と現在のスレッド参照 (「応答」を処理するスレッドを知っていると思います) を FIFO ブロッキング キューに配置して、TCP ソケット要求を確実にするために最も古いスレッドが最初に処理されるようにする方法はありますか? /response 操作にかかる時間は最小限です。

4

2 に答える 2

0

あなたはConcurrentLinkedQueueを探していると思います-これが私からの強調を加えた説明です。

リンクされたノードに基づく無制限のスレッドセーフキュー。このキューは、要素FIFO（先入れ先出し）を注文します。キューの先頭は、キューに最も長く存在している要素です。キューの末尾は、キューに最も短い時間存在した要素です。新しい要素はキューの末尾に挿入され、キュー取得操作はキューの先頭にある要素を取得します。ConcurrentLinkedQueueは、多くのスレッドが共通のコレクションへのアクセスを共有する場合に適切な選択です。このキューはnull要素を許可しません。

于 2012-09-06T22:48:59.417 に答える
0

「リクエスト」情報と現在のスレッド参照を配置する方法はありますか

リクエストごとにインクリメントされるAtomicLongリクエストカウンターがあります。次に、カウンタは、リクエスト マップ内の UDP ソケットに、その他のリクエストごとの情報とともに関連付けられます。カウンターも TCP ソケット経由で送信されます。TCP ソケットからの応答は要求カウンターと共に返され、リーダー スレッドは適切な UDP ソケットを介して応答を返すか、スレッド プールでスケジュールします。

要求カウンターを取得すると、TCP ソケットは要求/応答ストリームになり、必要に応じて順不同で送信できます。スレッドがリモート サーバーに要求を送信し、別のスレッドが応答を読み取り、UDP クライアントへの応答をスケジュールします。必要に応じてFIFOの順序を保証できますが、別の応答の準備ができている場合、順序が間違っているという理由だけで待機する必要がある理由がわかりません。

サーバー側では、同様のリーダー スレッドとライター スレッドがあり、どちらもワーク キューから消費します。

于 2012-09-06T22:43:03.597 に答える