0

Objective:

To pass data from incoming UDP datagrams to 4 threads waiting on their respective queues. The application is supposed to work non-stop for pumping traffic to a DUT and process the incoming messages. This is what I am doing:

1. Public byte[] receiveData = new byte[512]
2. receivePacket = new DatagramPacket(receiveData, 0 , receiveData.length)
[The above 2 steps are in constructor of the listener class]
3. while (1)
a. ApplicationStart.serversocket.receive(receivePacket)
b. recvData = new String(receivePacket.getData()
. 
. {Processing of data}
.

c. recvData = null

Problem:

The memory is continuously increasing. I suspect this is because it is waiting for GC to claim the unused memory. I wish I can allocate some static memory outside the infinite while loop. The problem I face if I do this is that the “receivePacket.getData()” returns a byte array and to work on the data, I need to convert it into a string. All the data is in text format (to be specific it is MGCP packets). Please suggest any way to make sure that the memory is not exhausted. I don’t want to manually call the garbage collector. I am not sure of the overhead for GC.

Thanks

4

2 に答える 2

0

良い。宿題であり、オフショアプロジェクトではないことを願っています...

実際の質問への回答:

事前に割り当てられた多数のパケットを作成し、それらをキューに追加できます。キューの先頭から使用済みのパッケージを取得し、受信します。ハンドラ スレッドがパケットを処理すると、それをキューの後ろに置きます。

ステップ 3.b は、新しいバイト配列を作成し、パケットのコンテンツをそこにコピーするため、避ける必要があります。そのため、パケット (またはバイト配列) を入力として処理するようにスレッドを書き直してください。

パケットを処理できるよりも速く受信している可能性があります。そして、あなたのコードはすべてのメモリを使い果たします。(パケットと文字列を割り当てて、ハンドラー スレッドのキューに入れます。)

ブロッキング キューを使用していて、「空き」パケットが読み込まれるのを待っている場合、それは起こりません。少なくとも同じ方法ではありません。UDP パケットは、OS または Java のネットワーク スタックのどこかでドロップまたはバッファリング (あるいはその両方) されるため、これに注意する必要があります。これが、実際には「データグラム」を転送するにもかかわらず、ほとんどの「メッセージ指向」プロトコルが TCP/IP を使用することになる理由です。

于 2010-10-14T10:47:45.737 に答える
0

まず、手動で GC を呼び出す必要はありません。通常、そうするのはお勧めできません。

そうは言っても、「メモリが増え続けている」というのが何を意味するのかは不明です。

外部から観察されたアプリケーションのメモリ割り当てが増加しているという意味であれば、それは正常です。Java は可能な限り新しいオブジェクトを割り当て、すぐに使用できるスペースがない場合にのみ GC を実行します。外部からは、JVM がますます多くのメモリを使用しているように見えます。

JVM がヒープ領域が不足していることを報告している場合 (つまり、OutOfMemoryError をスローすることによって)、問題があります。ただし、この問題はGC を実行しても解決されません。代わりに、Java メモリ プロファイラを実行してリークの原因を特定し、修正する必要があります。

(背景: Java のメモリ リークは、(たとえば) C / C++ のメモリ リークとは少し異なります。C / C++ では、不要になったオブジェクトをアプリケーションが無視したときにリークが発生しますfree。Javadeleteでは、メモリ リークが発生します。アプリケーションが、もう使用されないオブジェクトへの参照を誤って保持している場合.アプリケーションがオブジェクトを再度使用する可能性があるとGCが判断した場合、GCはそれを回収できません...したがって、オブジェクトは残ります.)

于 2010-10-14T06:44:36.173 に答える