Thread creat memory leak?

[Tien-Chih Wang]

Hi,
A piece of code running on the server.

for(int i = 0; i < 100; i++)
{
Thread t = new Thread();
t.start();
}

I got several heapdump and javacore files on the server(may caused by out of memory exception). Could this happen and how can I solve this if it's Thread issue?

Best Regards,

Tien-Chih Wang
[ October 24, 2005: Message edited by: Tien-Chih Wang ]

[Ernest Friedman-Hill]

This exact bit of code is unlikely to cause any problems, at least not on a server-class OS (if you're running on, say, Windows 98, then maybe even this is too much for the OS to handle). But if your threads are actually doing some work, and if you're really starting 100 (or more) of them at once, then you could easily exhaust memory or have other problems. It's impossible to give you specific advice without knowing more about what you're doing.

Every running thread requires some dedicated memory for its stack, and perhaps other OS resources. You can only start so many threads before you will have problems, either running out of memory, or bumping into resource limits set by the OS. The exact limit is system-dependent.

[Scott Selikoff]

I agree, creating threads may seem simple, but even 100 (or especially >1000) its not hard at all to run out of memory. One suggestion I have is try running it with 5-10 threads, see if it works, then increment it to see if it is indeed the number of threads that is your problem. 100 isn't that much but if your machine is underpowered or code too memory intensive, it could run out.

Also, try modifying your code to encourage garbage collection (and yes this is something that can not be guarenteed in java). For example, some methods have close() commands such as databases and result sets. Also, if you are completely done with an object set all pointers to be null. This will encourage java to garbage collect it if there are no available references.

The real question I have is, why are you creating threads in a server environment? One of the guidelines for J2EE (if this is a J2EE server) is to avoid manual thread management all together.

The only exception I really know of is the singleton model where you really only want to spawn 1 thread, such as a static instance of a logger. Another rare exception is load balancing and testing although thats usually artificial to begin with.

[Scott Selikoff]

Oh one other memory trick I learned awhile ago is to avoid using 'new' where ever possible. For example, if you are finished with a temporary object like an array and need a new one, don't create a new array, just overwrite the values of the existing one.

The specific situation where this temp variables in loops such as the following:

for(int i=0; i<array.size(); i++) {
  TempObject x = new TempObject();
  // Do some stuff
}

Since this object TempObject may be thrown away after each iteration it would vastly improve performance to define it once and then reset it. Keep in mind this solution does not work if you keep references to the TempObject somewhere such as in a Hash table.

[Ken Blair]

Since you brought up for loops, if you're accessing an array or Collection in 5.0 there's a better way if you don't need specific knowledged of the current index:

Object[] array;
...
for (Object element : array) {
    // Iterates over the array.
}

Very easy to use for an array. Use with Collections requires generics to be of real value:

ArrayList<Thread> threadArray;
...
for (Thread element : threadArray) {
    // Do something with each Thread.
}

Finally, reusing TempObject really shouldn't save much memory. What it will save is time constructing a new TempObject and collecting the old ones, but that's a minimal improvement unless the iteration happens very often or TempObject is expensive to construct. A Calendar, for example, is very expensive whereas a small class with little initialization isn't. Generally it's a good idea to initialize a variable with a scope exactly the same as the for loop in the for loop's initialization, but that's not always practical. If you're going to declare it and initialize it outside of the for loop be sure to either null the reference afterwards or ensure that the rest of the method is short.

[Tien-Chih Wang]

Hi,
Thanks for all the answers. I found I missed to close() streamReader object during the Thread execution. That might be the cause. I modified the code and no more heapdump or javascore so far.

Thanks the help,

Tien-Chih Wang