Java Performance Tuning Course
Chania Crete, May 17-20, 2010
Sun Extreme Learning EXL-2025
Houston, December 1-4,2009
New York, December 8-11, 2009
Washington DC, January 5-8, 2010
San Francisco, January 11-14
Anti-if
My RSS Feeds
Send me your memory leaks
posted Wednesday, 7 February 2007
At this years JavaPolis I endeavored to have the audience work through a performance tuning exercise during our University session. In planning for this session I fretted over just how hard a problem I should give. In the process of setting the level of difficulty I came to the conclusion that the difficulty was not with the problem but rather with the tools I was using (I used quite a few different ones including the usual suspects).
What I was looking for was a reliable way to locate the leak using a set of instructions that I could give to my mother (ok,, maybe not that simple but...). Problem was, it just wasn't happening and I didn't want to stand up in front of 300+ people and say, to diagnose a memory leak you need to perform some black magic. Unfortunately this is just about what I did during that session. So, since then I've been doing a lot of thinking about the problem. I've also had some interesting conversations on the subject with a number of people and know have some idea's I'd like to try out.
The true test is; can I find the leak with minimal interaction with the code. I.E. I want to do this using instrumentation only looking to the code at the end of the exercise. So, I'd like to try it out on a few use cases. If you have or had a particularly nasty memory leak in your Java application, I'd be interested in hearing from you. I should add that any derived technique will end up in the public domain.
What I was looking for was a reliable way to locate the leak using a set of instructions that I could give to my mother (ok,, maybe not that simple but...). Problem was, it just wasn't happening and I didn't want to stand up in front of 300+ people and say, to diagnose a memory leak you need to perform some black magic. Unfortunately this is just about what I did during that session. So, since then I've been doing a lot of thinking about the problem. I've also had some interesting conversations on the subject with a number of people and know have some idea's I'd like to try out.
The true test is; can I find the leak with minimal interaction with the code. I.E. I want to do this using instrumentation only looking to the code at the end of the exercise. So, I'd like to try it out on a few use cases. If you have or had a particularly nasty memory leak in your Java application, I'd be interested in hearing from you. I should add that any derived technique will end up in the public domain.
comments (2)
1. Rickard left...
Thursday, 8 February 2007 1:09 pm
One of my favourites involve threadlocals. I found this one in Struts 2.0,
but the problem is pretty general. If you have a threadlocal in a webapp
which stores some context for each request, and this is populated by for
example a servlet filter, then it is vital that the threadlocal is cleared
when the request is done. What might otherwise happen is that a redeploy of
the webapp will not release the previous version, since there is a
reference in a threadlocal.
2. Sergey Zeltnysh left...
Wednesday, 14 March 2007 1:39 pm
Hi Kirk,