New (revolutionary?) solution for Java memory leak discovery: Plumbr explained
plumbr.eu
plumbr.eu
Even if you don't store that information, and even if it is not really useful, you should maybe note somewhere that all the "leak" information is sent to Plumbr servers.
The info is sent when you click the Decrypt button, and there is an explanation right above the button: "You are running Plumbr with evaluation license, which means that all Plumbr reports need to be submitted to our server to see full details. /---/"
Nonetheless, people upvoting my comment probably shows that many people missed that.
This would have been useful 9 months ago when we were tracking an object leak. Stress tests with AB and monitoring with jconsole combined with reading the code were sufficient to find the problem.
I advise caution, particularly with false-positives (objects with long lifecycles). If it was so easy to find the leaks, the GC would be able to resolve the leak itself.
As soon as we learn the best ways to offer this, the "feature" will be packed and released.
So without any way to evaluate the product, I'll be moving on.
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.
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.
a) you usually cannot simulate the exact behavior of users in production environment. Users tend to be quite creative in ways they approach your workflows and your artificial tests might not catch it b) Your dev/test/staging environment is usually not a 100% replica of the production site - you might lack access to some integrated systems, have different datasets for confidentiality reasons, use virtualized machines instead of physical, etc c) Or anything else which all leads to the sad fact that oftentimes you just cannot replicate the leak in any other env than production.
Also - if you can discover the leak in staging, the tool pinpoints the source of the leaks so that you don't have to waste time on reproduction, comparing heap dumps, and crawling through your code.