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. /---/"
Neat idea, but not working for me. I tried with with Day CQ5 CMS, and Plumbr starts but it looks like it stops while loading the Lucene indices.
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.
I suppose this only detects intermittent leaks? If a particular class always leaks then this tool would have no frame of reference to detect it, right?
You are so right, this is indeed what Plumbr lacks at the moment. There are a few possibilities to teach Plumbr already now hacked in, but these are not advertised and we are testing them with users who have had a bigger need for them.
As soon as we learn the best ways to offer this, the "feature" will be packed and released.
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.
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.
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.
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.
Detecting memory leaks is easy: run some stress tests before deploying to production!
I mean, I don't see the use of this tool. Attach it to a live JVM to detect leaks which shouldn't be there?
If you haven't had any memory leaks slip into production, you're in luck.
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.
It tends to be more complex than this for several reasons:
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.
Totally agree and this tool might help in this situations but still I find it more suitable to simply watch the memory usage, which in a sane application, should have a pattern.
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.