…total reliance on the garbage collector to identify unreachable objects so that their associated native — and potentially scarce — resources can be reclaimed has a serious flaw: Memory is typically plentiful, and guarding a potentially scarce resource with a plentiful one is not a good strategy. So, when you use an object that you know has native resources associated with it — for example, a GUI component, file, or socket — by all means call its dispose() or equivalent method when you are finished using it. This will ensure the immediate reclamation of the native resources and decrease the probability of resource depletion. Thus, you will use the approaches discussed in this article for postmortem cleanup only as last resorts and not as the main cleanup mechanisms.
You should also use finalization only when it is absolutely necessary. Finalization is a nondeterministic — and sometimes unpredictable — process. The less you rely on it, the smaller the impact it will have on the JVM and your application. See also Joshua Bloch’s book, Effective Java Programming Language Guide, chapter 2, item 6: Avoid finalizers.
Oracle Enterprise Manager Java Application Diagnostic Expert (JADE) improves the availability, performance and provides in-depth diagnostics for Java applications with low overhead. It enables:
1. Production diagnostics with no application instrumentation, saving time in reproducing problems
2. Visibility into Java activity including in-flight transactions, allowing administrators to proactively identify issues rather than diagnosing after-the-fact (application hangs, crashes, memory leaks, locks)
3. Tracing of transactions from Java to Database and vice-versa, enabling faster resolution of problems that span different tiers
4. Differential heap analysis in production applications.
This is Auptyma‘s “Java Application Monitor”. It’s likely Auptyma was acquired by Oracle – its founder and CEO was previously Director of the CRM Performance Group at Oracle.
Cary Milsap, “Optimizing Oracle Performance” (O’Reilly, 2003). On p. 361, there is a definition of scalability expressed in terms of the response time (R). [ed. scalability: The rate of change of response time with respect to some specified parameter. For example, one may speak of the scalability of a query with respect to the number of rows returned, the scalability of a system with respect to the number of CPUs installed, and so on.] This stands in contrast to the way I developed my Universal Scalability Law, which is based on a kind of normalized throughput. … For those of you who haven’t seen it, here’s how it works …