Dave Landers

Finding a leak is only the first step. Usually, the leak will be some Map or field that holds some Object or Class or whatever that eventually anchors the ClassLoader.Using a profiler like YourKit, you can find the cause of the leak. But the real solution to the problem requires you to figure out:

• Where was this anchor established (created)?
• Why is it there?
• Is it necessary, or can it go away (or be done some other way)? 
  • For example, can it be held weakly (WeakReference)?
• If it must remain, how should it get cleaned up?

Sometimes, the answer to the above is obvious. But other times, the first question (where was it established) is difficult to see.

YourKit and other profilers have the ability to record allocation stack traces (where the stack trace of every object allocation is recorded). This is one way to go, but it seriously slows down the running of the server (it is off by default in YourKit, for example). I also found that in a system as large as WebLogic Portal, I never really got adequate data because there was just way too much for the profiler to record (so it often gave up before I saw what I needed).

The next option would be to run with a debugger, assuming you have the appropriate source available in your IDE, etc.

But often the easiest way to go is to add some System.out.println and Thread.dumpStack calls in strategic places in the code. Then you can see the call stack of the one place you are interested in without having to record all allocations or figure out how to run with a debugger.

Once you find that root cause, you can move on to a reproducible test case, and then a fix.

Technorati Tags: leak, memory, portal, WebLogic