4 ms·

How and how often do Java memory leaks actually happen? It's never stricken me as a problem. I guess some kind of global variables are involved.

mvanga 15y ago
You might, for example, insert an entry into a hashtable and forget to remove it. The garbage collector can't go and clean it up because it can't know whether you plan to use it or not. This way, over time, the memory usage keeps growing.
- riffraff 15y ago
  also, as grandparent guessed, static and thread local variables do not have the same lifecycle of the "normal" objects, I've been bitten more than once by some "clever" optimization caching stuff in those places.
spacemanaki 15y ago
Here's a rather complicated example from Android: http://developer.android.com/resources/articles/avoiding-memory-leaks.html http://developer.android.com/resources/articles/avoiding-mem... It's pretty Android specific, but the general idea probably can happen in other contexts (pun intended), when some framework or other retains a reference to something you expect to be garbage collected.
raganwald 15y ago
Speaking as a fellow who won a Jolt Award for JProbe, ( shoots cuffs), there are lots of ways memory leaks can happen. A "Lapsed Listener" occurs when an object is no longer active but is pinned by another object observing it for changes. The infrastructure should have removed the observer's reference of used a weak reference. A "Lingerer" is an object that should be garbage collected when it is no longer needed, but is not garbage collected until another object replaces it. For example, if you have some sort of process pool like a pool of database connections or request handlers, you might have memory that is needed to handle a request. Many naïve programs free that memory when creating another request by overwriting references to it. However, it should be freed when the request has completed. Although the memory is not permanently pinned, performance suffers by having it "linger" unecessarily. These types of memory leak anti-patterns apply to all garbage-collected languages.

mvanga 15y ago

You might, for example, insert an entry into a hashtable and forget to remove it. The garbage collector can't go and clean it up because it can't know whether you plan to use it or not. This way, over time, the memory usage keeps growing.

riffraff 15y ago
also, as grandparent guessed, static and thread local variables do not have the same lifecycle of the "normal" objects, I've been bitten more than once by some "clever" optimization caching stuff in those places.

spacemanaki 15y ago

Here's a rather complicated example from Android: http://developer.android.com/resources/articles/avoiding-memory-leaks.html http://developer.android.com/resources/articles/avoiding-mem... It's pretty Android specific, but the general idea probably can happen in other contexts (pun intended), when some framework or other retains a reference to something you expect to be garbage collected.

raganwald 15y ago

Speaking as a fellow who won a Jolt Award for JProbe, ( shoots cuffs), there are lots of ways memory leaks can happen. A "Lapsed Listener" occurs when an object is no longer active but is pinned by another object observing it for changes. The infrastructure should have removed the observer's reference of used a weak reference. A "Lingerer" is an object that should be garbage collected when it is no longer needed, but is not garbage collected until another object replaces it. For example, if you have some sort of process pool like a pool of database connections or request handlers, you might have memory that is needed to handle a request. Many naïve programs free that memory when creating another request by overwriting references to it. However, it should be freed when the request has completed. Although the memory is not permanently pinned, performance suffers by having it "linger" unecessarily. These types of memory leak anti-patterns apply to all garbage-collected languages.