Question

In almost all larger Java projects I’ve been involved with I’ve noticed that the quality of service of the application degrades with the uptime of the container. This is most probably due to memory leaks in the code.

The correct way to solve this problem is obviously to trace back to the root cause of the problem and fix the leaks in the code. The quick and dirty way of solving the problem is simply restarting Tomcat (or whichever servlet container you’re using).

These are my three questions:

• Assume that you choose to solve the problem by tracing the root cause of the problem (the memory leaks), how would you collect data to zoom in on the problem?

• Assume that you choose the quick and dirty way of speeding things up by simply restarting the container, how would you collect data to choose the optimal restart cycle?

• Have you been able to deploy and run projects over an extended period of time without ever restarting the servlet container to regain snappiness? Or is an occasional servlet restart something that one has to simply accept?

Answer 1

Assume that you choose to solve the problem by tracing the root cause of the problem (the memory leaks), how would you collect data to zoom in on the problem?

Take a heap dump using jmap and load the dump using Eclipse Memory Analyzer. From there you can analyze which objects are eating up the most memory, which “roots” are preventing other objects from being collected, etc.

There are other heap analysis programs, such as jhat, but I’ve found EMA to be the fastest and best (free) solution.

Assume that you choose the quick and dirty way of speeding things up by simply restarting the container, how would you collect data to choose the optimal restart cycle?

Use JMX to monitor heap size and other heap and GC statistics.

Have you been able to deploy and run projects over an extended period of time without ever restarting the servlet container to regain snappiness?

Yes. By avoiding/fixing memory leaks.