Finding a memory leak

Similar to what sciuriware suggested, I recommend trying to turn off parts of the program bit by bit and see where the leak is located. I find that it usually is not that hard to create a few lines of code that mimic an entire section of the program, but return a fixed static answer without running all the logic. In addition to helping pinpoint the problem it usually makes the program faster, so that the problem occurs faster.
I also recommend limiting the memory given to the program so that the memory leak will become apparent sooner.
Start with the program you have right now, limit the memory (using java.exe -Xmx option) to something low, and let it run, so you can establish a baseline of how soon the memory leak occurs. Then replace a part of your code with a dummy method to simulate its function and see if it got rid of the problem. Do it, narrowing the location, until you find the problem.
Be sure to turn on the PrintGC flags (-XX:-PrintGC -XX:-PrintGCDetails -XX:-PrintGCTimeStamps), to get a feel of how the memory behaves - see http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp

In addition, I found that a lot of times collections (Map, Set, List) are the cause of the problem, since stuff just gets added to them, and sometimes no one deletes it.

HTH

Debugging the code is definitely one way to go.

You could also do actual performance analysis.  JProbe is the best product out there for Java, but it's very expensive now.  It's also hard to use.

Here's a good article from Sun about profiling performance:
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/perf3.html

and another very good article on performance analysis:
http://java.dzone.com/articles/java-performance-tuning

There's a list of free tools at the end of the second article.  JConsole is an easy way to start.

        Hi!

Take a look at these Profilers to see if any of them can help you solve your issue
http://java-source.net/open-source/profilers

Regards,
    Tomas Helgi

Yes, if you look at the articles I provided, they give links to profiler tools.  And as I said, JConsole is an easy way to start.

However, I have to agree with sciuriware and ozlevanon that it's usually faster to look at your code than to dig into profiling it for memory leaks.  That's especially true if you have a version of the code that does not exhibit the bad behavior.

Ok... thanks for all of your input. I have gone with sciuriware's recommendation, and have isolated, identified, and corrected the problematic code. Disabling the code strategically and measuring the results was a great way to go about things.

Thanks!

Thanks!

You are lucky!
Although .....................................

Although?