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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…