Java Reference
In-Depth Information
concern. Table 6.4 offers some guidance as to whether memory leaks should
be fixed at all.
Table 6.4 In some circumstances, fixing a memory leak may not be worth the effort. This table
shows common memory leak characteristics, and provides a guideline for whether the fix will be
worthwhile.
Application
Characteristic
Fix Memory
Leak?
Comments
Short application life cycle.
Seldom
Garbage collection may never be run.
Very small footprint.
Seldom
The leak should be fixed only if the application
has a long enough life for the cumulative leaks
to be a problem.
Fixing hurts code readability.
Sometimes
Readability is not the overriding concern,
but may discourage fixing a leak in some
circumstances.
Footprint is large.
Often
The leak should be fixed if the application life
cycle is long or if resources are likely to become
a problem.
Fix is very easy.
Yes
A memory leak is a bug. If the fix has been iden-
tified and has no other side effects, it should be
fixed.
Code runs 24x7.
Yes
The leak will eventually become a problem.
Code is a target for reuse.
Yes
Regardless of other characteristics, if the code
is a reuse target, it should be fixed
You should be especially vigilant about fixing leaks in two instances: when an
application runs 24x7, and when code is a target for reuse. Leaks in either cir-
cumstance should nearly always be plugged. In any case, to prevent the spread
of bugs through cut and paste, if a leak exists and you don't fix it, then you
should at least document it.
6.5.3
Isolate the problem
Once you've determined there is a leak, and that the leak should be fixed, you
need to isolate a test case that creates the problem. Effective testing can be
much more productive than the use of low-level memory debuggers, so it's
important to make the test case as narrow as possible. Unfortunately, that isn't
always possible. The complexity of user scenarios and the degree of coupling
between elements of the application will collectively determine how effectively
