Java Memory Leaks
I was testing one of my programs for runtime speed, so I had a for-loop call one of my methods 10,000,000 times. I used the System.nanoTime() method to have my program print out the amount of time it took each iteration. After examining my data, I found a spike-and-plateau pattern: it'd take 10,000 nanoseconds for a few iterations, then the runtime length would spike, and then it'd go back down to a lower level (like 9,000 nanoseconds). It would keep doing this until it reached a steady state, where it alternated between 2235 and 2514 ns. Could my computer be experiencing a memory leak?
[602 byte] By [
lil_weezya] at [2007-11-27 7:28:32]
Runtime wouldn't be a good indicator of a memory leak. Look at the heap for something like that. And if the value being tracked (heap or runtime or anything) spikes but then comes down to a lower, steady level, then it's probably not a leak of anything. In memory leaks, the memory usage just climbs and climbs until it's constantly swapping virtual and physical memory, and that's when time becomes an issue.
Probably the spikes were just garbage collections. Not a problem.
About the garbage collections...
I'm not sure if that really is the reason. After collecting this data, I rewrote my program so that every time the for-loop runs, it calls the Java garbage collector (System.gc();). I remembered to put it outside the timing statements so that it wouldn't get factored in to the recorded runtime. I collected my data again, and I got different results. This time, there was no "spike-and-plateau" pattern. Instead, the data points hovered around 30,000 nanoseconds.
It just so happens that before I wrote in this garbage collection, my program started out taking 30,000 nanoseconds before spiking and plateauing at a lower value.
gc() doesn't force garbage collection; it's just a suggestion to the JVM to do so.Anyway, the results you mention seem to confirm that it's garbage collection, not refute it.But this is all speculation. You should just start using a profiler, and get some harder data.
Your CPU will also be doing things other than executing your Java app. Between that and GC, it's absolutely expected that there are variations in the time to run any given piece of code.
If there's any I/O (don't know if that apples in your case) or if the are multiple threads--as with a GUI app--(again, don't know if it applies), then that will further mess with predictability.
jverda at 2007-7-12 19:08:40 >
