No, I don't think it's a leak. In Java, a "memory leak" is when objects you no longer need are still referenced, so the garbage collector can't discard them, so they pile up and eventually you run out of memory. What you have is simply too much garbage -- you're allocating too many objects and then throwing them away.
Without looking through the code, I obviously can't tell you where that's happening. If you watched the JProbe memory graph as the application ran, you'd see which bars were growing the fastest, and shrank the most when the garbage collector ran. Those 3200 large bytes look suspicious, but I can't tell from this snapshot. I suspect your data structures could be more efficient if you'd like to bring down the total memory requirement, as well. Hell, you could save megabytes just by giving an argument of "2" to all those ArrayList constructors to make the initial size of the internal array smaller, and you could save even more by combining them all into one. There's no way every tile in the game has a large collection of each of those different object types.
The truth is, though, that in general you shouldn't call System.gc() yourself. Java knows how to manage memory very well, thank you very much, and by calling gc() explicitly, you almost always make things worse, not better. If your application isn't actually running out of memory -- and it's not, apparently -- then there's really not a problem here.
I haven't used JProbe in years, but in general these tools have some way to get a list of all the objects og a given type (maybe just double-clicking a bar in this bar graph) and then in the ensuing list, you can get some additional info about each object by double-clicking again. Info about where each object is allocated may be part of that; if not, there may be a setting you can make to turn collection of that info on.
John Carr wrote:I have been using JProbe, and in the application, the ActiveTile class is using tons of memory, and total memory usage increases, then when a GC is called it cleans it all.
Is there a way to stop this, and is it a memory leak?
This is normal heap behaviour - memory size of objects allocated on heap increases, then if there is no more free memory to allocate a new object, JVM runs GC and cleans not reachable objects from heap.
This is not a symptom of the leak.
I don't know JProbe, but there must be a screen that shows memory usage on the heap over time.
Look at this example pictures from JConsole:
On the first picture, there is probably no memory leak - the amount of used memory after GC reaches the same minimum level after long running tme.
On this picture there is an obvious signal that there is probably a leak in the code - the amount of used (not freed) memory after GC increases over time.
To examine if there is a memory leak, run JProbe for 5 or 10 hours then examine screens of memory usage and you'll see it.
Today you are you, that is turer than true. There is no one alive who is youer than you! - Seuss. Tiny ad:
a bit of art, as a gift, that will fit in a stocking