Easiest way to cause a memory leak in Java [duplicate]

You cannot really "leak memory" in Java unless you:

• intern strings
• generate classes
• leak memory in the native code called by JNI
• keep references to things that you do not want in some forgotten or obscure place.

I take it that you are interested in the last case. The common scenarios are:

• listeners, especially done with inner classes
• caches.

A nice example would be to:

• build a Swing GUI that launches a potentially unlimited number of modal windows;
• have the modal window do something like this during its initialization:

  StaticGuiHelper.getMainApplicationFrame().getOneOfTheButtons().addActionListener(new ActionListener(){public void actionPerformed(ActionEvent e){// do nothing...}})

The registered action does nothing, but it will cause the modal window to linger in memory forever, even after closing, causing a leak - since the listeners are never unregistered, and each anonymous inner class object holds a reference (invisible) to its outer object. What's more - any object referenced from the modal windows have a chance of leaking too.

This is why libraries such as EventBus use weak references by default.

Apart from listeners, other typical examples are caches, but I cannot think of a nice example.

"A memory leak, in computer science (or leakage, in this context), occurs when a computer program consumes memory but is unable to release it back to the operating system." (Wikipedia)

The easy answer is: You can't. Java does automatic memory management and will free resources that are not needed for you. You can't stop this from happening. It will always be able to release the resources. In programs with manual memory management, this is different. You can get some memory in C using malloc(). To free the memory, you need the pointer that malloc returned and call free() on it. But if you don't have the pointer any more (overwritten, or lifetime exceeded), then you are unfortunately incapable of freeing this memory and thus you have a memory leak.

All the other answers so far are in my definition not really memory leaks. They all aim at filling the memory with pointless stuff real fast. But at any time you could still dereference the objects you created and thus freeing the memory → no lead. acconrad's answer comes pretty close, though as I have to admit, since his solution is effectively to just "crash" the garbage collector by forcing it in an endless loop).

The long answer is: You can get a memory leak by writing a library for Java using the JNI, which can have manual memory management and thus have memory leaks. If you call this library, your Java process will leak memory. Or, you can have bugs in the JVM, so that the JVM loses memory. There are probably bugs in the JVM, and there may even be some known ones since garbage collection is not that trivial, but then it's still a bug. By design this is not possible. You may be asking for some Java code that is affected by such a bug. Sorry, I don't know one and it might well not be a bug any more in the next Java version anyway.

Here's a simple example

public class Finalizer {    @Override    protected void finalize() throws Throwable {        while (true) {            Thread.yield();        }    }    public static void main(String[] args) {        while (true) {            for (int i = 0; i < 100000; i++) {                Finalizer f = new Finalizer();            }            System.out.println("" + Runtime.getRuntime().freeMemory() + " bytes free!");        }    }}