Simple Class - Is it a Memory Leak?

问题:

I've a very simple class which has one integer variable. I just print the value of variable 'i' to the screen and increment it, and make the thread sleep for 1 second. When I run a profiler against this method, the memory usage increases slowly even though I'm not creating any new variables. After executing this code for around 16 hours, I see that the memory usage had increased to 4 MB (initially 1 MB when I started the program). I'm a novice in Java. Could any one please help explain where am I going wrong, or why the memory usage is gradually increasing even when there are no new variables created? Thanks in advance.

I'm using netbeans 7.1 and its profiler to view the memory usage.

    public static void main(String[] args)
    {
        try
        {
            int i = 1;
            while(true)
            {
                System.out.println(i);
                i++;
                Thread.sleep(1000);
            }
        }
        catch(InterruptedException ex)
        {
            System.out.print(ex.toString());
        }
    }

Initial memory usage when the program started : 1569852 Bytes.

Memory usage after executing the loop for 16 hours : 4095829 Bytes

回答1:

It is not necessarily a memory leak. When the GC runs, the objects that are allocated (I presume) in the System.out.println(i); statement will be collected. A memory leak in Java is when memory fills up with useless objects that can't be reclaimed by the GC.

The println(i) is using Integer.toString(int) to convert the int to a String, and that is allocating a new String each time. That is not a leak, because the String will become unreachable and a candidate for GC'ing once it has been copied to the output buffer.

Other possible sources of memory allocation:

• Thread.sleep could be allocating objects under the covers.

• Some private JVM thread could be causing this.

• The "java agent" code that the profiler is using to monitor the JVM state could be causing this. It has to assemble and send data over a socket to the profiler application, and that could well involve allocating Java objects. It may also be accumulating stuff in the JVM's heap or non-heap memory.

But it doesn't really matter so long as the space can be reclaimed if / when the GC runs. If it can't, then you may have found a JVM bug or a bug in the profiler that you are using. (Try replacing the loop with one very long sleep and see if the "leak" is still there.) And it probably doesn't matter if this is a slow leak caused by profiling ... because you don't normally run production code with profiling enabled for that long.

---

Note: calling System.gc() is not guaranteed to cause the GC to run. Read the javadoc.

回答2:

I don't see any memory leak in this code. You should see how Garbage collector in Java works and at its strategies. Very basically speaking GC won't clean up until it is needed - as indicated in particular strategy.

You can also try to call System.gc().

The objects are created probably in the two Java Core functions.

回答3:

It's due to the text displayed in the console, and the size of the integer (a little bit).

Java print functions use 8-bit ASCII, therefor 56000 prints of a number, at 8 bytes each char will soon rack up memory.

回答4:

Follow this tutorial to find your memory leak: Analyzing Memory Leak in Java Applications using VisualVM. You have to make a snapshot of your application at the start and another one after some time. With VisualVM you can do this and compare these to snapshots.

回答5:

Try setting the JVM upper memory limit so low that the possible leak will cause it to run out of memory.

If the used memory hits that limit and continues to work away happily then garbage collection is doing its job.

If instead it bombs, then you have a real problem...

回答6:

This does not seem to be leak as the graphs of the profiler also tell. The graph drops sharply after certain intervals i.e. when GC is performed. It would have been a leak had the graph kept climbing steadily. The heap space remaining after that must be used by the thread.sleep() and also (as mentioned in one of answers above) from the some code of the profiler.

You can try running VisualVM located at %JAVA_HOME%/bin and analyzing your application therein. It also gives you the option of performing GC at will and many more options.

I noted that the more features of VisualVM I used more memory was being consumed (upto 10MB). So this increase, it has to be from your profiler as well but it still is not a leak as space is reclaimed on GC.

回答7:

Does this occur without the printlns? In other words, perhaps keeping the printlns displayed on the console is what is consuming the memory.