Take the 2-minute tour ×


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


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.


share|improve this question
What does your title have to do with your question? –  EJP Oct 14 '10 at 7:05
Post some code.That will be helpful to understand the problem. –  Emil Oct 14 '10 at 10:08
add comment

2 Answers

First, you shouldn't need to call the GC by hand, and it is generally a bad idea to do so.

Having said that, it is unclear what you mean by "the memory is continuously increasing".

If you mean that your application's memory allocation as observed from the outside is increasing, then that is normal. Java will allocate new objects as long as it can, and only run the GC when there is no space immediately available. From the outside, it looks like the JVM is using more and more memory.

If you mean that the JVM is reporting that it is running out of heap space (i.e. by throwing OutOfMemoryError), then you have a problem. However, this problem won't be cured by running the GC. Instead, you need to run a Java memory profiler to find the source of the leak, and fix it.

(Background: Java memory leaks are a bit different to (for instance) C / C++ memory leaks. In C / C++ a leak happens when your application neglects to free / delete an object when it is no longer needed. In Java, a memory leak happens when your application accidentally keeps a reference to an object that is no longer going to be used. If the GC thinks that the application might use the object again, it cannot reclaim it ... and hence the object stays around.)

share|improve this answer
add comment

Well. I sure hope its homework and not an offshored project...

Answer to your actual question:

You can create a number of preallocated packets, and add them to a queue. Grab an usued package from the start of the queue, and receive into it. When a handler-thread has handled the packet, it puts it at the back of queue.

Step 3.b should be avoided, as it creates a new byte array and copies the content from the packet into it, so rewrite the threads to handle packets (or byte arrays) as input.

It IS possible that you are receiveing packets faster than you can handle them; and then your code will use up all memory. (As you allocate the packets and strings and putting them in the handler threads' queues.)

If you are using a blocking queue, and waiting for "free" packets to read into, that won't happen; at least not in the same way. The UDP packets will be dropped or buffered (or probably both) somewhere in the OS's or javas network stack, so you need to take care of that. Which is why most "message oriented" protocol ends up using TCP/IP though they actually transport "datagrams"

share|improve this answer
add comment

Your Answer


