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.