Cause of memory leaks in Tomcat

Hi everyone!

I am currently hunting down memory leaks in a Tomcat servlet. One I haven't developed myself I must add.

I tried to take an analytical approach to where the leaks might come from, as the application ist about 2000 classes and I have only an architectural overview.

So I asked myself, where memory leaks could general

ly come from. Maybe you've got some more causes or are willing to discuss mine.

Memory Leak Causes
-------------------------
1. Unfinshed Threads
2. Static Attributes
3. Open Connections
3.1 Databases
3.2 Queues
4. References from outside systems

Any suggestions?

Matthias

You can check:

1. Session variables : Dont keep huge data into session
2. Avoid usage of Reflections until it is required.
3. Can use Arrays in place of ArrayList.
4. While invoking the request pass minimum data.Avoid passing unnecessary data between calls.
5. Use cache to keep ejb objects - which will avoid make redundant JNDI lookup.

It all depends upon your application.

These are the all common available checks one can do..

Others if any cann be added..

Hello Mohammed!

Thanks for your reply. These are all important issues when dealing with too much memory consumption.

I am currently focussing on uncleaned sessions. Objects that remain in memory, even though the servlet is quitted and the session invalidated.

Those object never become cleaned up (you have to restart Tomcat).

One issue I have come across is the usage of String concatenation. As far as I've understood, those are never removed from memory. So if you do a lot of string concatening (e.g. for logging or sql statements), than by the time you'll get an OutOfMemoryException.

Is this right?

Yes..thats right.

One issue I have come across is the usage of String concatenation. As far as I've understood, those are never removed from memory.

It is only Strings that are intern()ed that are hard to get rid of - servlet apps constantly build temporary Strings that are disposed like any other object.

Threads that are created but never properly terminated can indeed eventually crash a system but most apps dont create extra Threads.

The servlet container should be able to serialize large session objects out to disk when needed and delete them when the session is invalidated - it is object kept in collections NOT managed by the container that can build up.

Use arrays instead of ArrayList - what a bizarre idea - use either as appropriate, just be sure to discard when finished.

Pass minimum data! Good point - be especially careful with the objects that the container manages such as request and response objects - keeping references to these beyond a single request/response cycle is very very dangerous.

Bill

William Brogden wrote:
Use arrays instead of ArrayList - what a bizarre idea - use either as appropriate, just be sure to discard when finished.

My only intention while saying prefer Array instead of ArrayList was with having below in mind:

If number of elements is determined, use an Array instead of an ArrayList, because it is much faster.
An Array also provides type checking, so there is no need to cast the result when looking up an object.

If number of elements is determined, use an Array instead of an ArrayList, because it is much faster.
An Array also provides type checking, so there is no need to cast the result when looking up an object.

Good point, just use as appropriate. Fortunately there are very convenient methods for converting between arrays and ArrayList collections.

I also forgot to mention that the Tomcat Management application can be very helpful in monitoring - for example I found long running requests that essentially hung due to waiting for a non-existant resource.

Bill

Run a profiler to investigate memory usage.

Hello Bauke!

Sorry, but I am looking for CAUSES of memory leaks

A profiler is just a tool.

Of course I need it to check if my memory usage is okay. But if a timed out session keeps 800 objects (120 classes) in memory, then it's hard to find the cause.

Maybe you can help me now that I have clearified my question.

Matthias Merz wrote:A profiler is just a tool.

And a wrench is just a tool -- why would one use it to tighten a bolt?

Thanks Wiliam!

This is by far the most useful I have heard yet.

I guess most of my problems do indeed come from a thread that is waiting for messages in an oracle queue. I'm currently refactoring it.