There are a number of reasons to avoid using Java Finalization (that is, objects that override the finalize() method). From the GC performance perspective, the main problem with finalization is that when GC determines that a finalizable object F is unreachable, it doesn’t clean up F immediately, as it does with other unreachable objects. Instead, the GC places F on the finalization queue, which is served by a single thread. Only when that thread executes the finalize() method of
In this version: Detection of more anomaliesBug fixes and usability improvements
In this version: Detection of new common memory problems (anomalies): in Netty, Jetty and JDKBetter detection of unfinalized objectsBug fixes and performance improvements
In Java terminology, the “live set” (LS) for a given running app means all objects that are live (that is, not garbage) at the given moment. For most apps with steady workload, objects come and go from the live set, but its size remains pretty stable (after initial warmup). In contrast, if LS keeps growing, the app most likely has a memory leak. If LS size is too close to the maximum heap size (value
This version contains the following improvements and fixes: Added detection and explanation of several common problemsSeveral usability improvementsImproved performance, especially when analyzing dumps with a large number of objects