jb2works.com
>
Java Memory Leak FAQ
eng
|
de
Java Memory Leak - Frequently Asked Questions
Why doesn't my program release the memory? Why don't my objects get garbage-collected?
- This are questions often raised in larger java projects. This site explains why such things
happen, how you find and fix a memory leak and what you can typically do to avoid memory leaks from the beginning.
Why doesn't my application release the memory?
Why doesn't my object get garbage-collected?
If an object is still alive even after you called the garbage-collection,
nearly always the reason is that your object is still strongly reachable from a static
root or from the main instance. At least one other object does reference
to your object. So the Virtual Machine assumes that your object is in use and
prevents the garbage-collection.
If a program leaks memory because it does not clean-up the references
then we call it 'Data Cancer'. The heap grows and grows. In the
worst case the program later runs out of memory.
For Java, memory leaks are typically of the 'Data Cancer' typ.
What else can cause memory leaks?
Memory leaks that are not 'Data Cancers':
Native memory leaks - e.g. forgotten dispose() calls or bugs in the JVM,
Wrong implementations of finalizers - finalizers are not destructors,
Pending objects in finalizer queues and reference queues, and
Cascading effects with objects of type 'java.lang.Reference'.
These problems occur very seldom compared with 'Data Cancer' issues.
Is it possible that dependencies between objects are too strong?
So that the JVM is not able anymore to clean-up?
We think this mythos is wrong. Whenever we heard that the JVM is not able anymore to clean-up,
then we found an ordinary memory leak. Often the usual JVMPI Profilers have problems to
find all references or to clearly arrange the reference graph.
Why not simple try more than one tool?
What can I do against memory leaks?
One of the most successful methods is this one:
Define 2 points in time to take a heap snapshot.
Create a diff from the snapshots.
Analyze the reference graphs to instances remaining in the diff.
Simulate one or more solutions.
Implement one solution.
Choose the second point in time so heap neutral as possible compared
with the first one. Do return to an state where on the heap you would not expect more
objects than before.
Please think also about pending changes (do save?), histories,
undo-lists, caches, pools etc. .
What features should a tool have to fix memory leaks?
A short list of features which we find well suited:
Can take heap snapshots.
Can create a diff from snapshots.
Finds all references to an instance.
Show the reference graph from reference up to a static root or the main instance.
Should be able to simulate solutions because off a reference can often be reached on multiple
ways.
Show the heap so as the garbage collection would work on the fly.
Because you should not need to pay attention to the garbage collection.
Important too is how a tool lets you navigate through a reference graph
and how intuitively it displays the information. A tool showing only one
level of a reference graph will not help very much. Reference graphs not seldom reach
more than 100 levels.
Which tool you do recommend?
We recommend Reference Scanner from our website.
We wrote it because we found the known popular tools didn't help us very much in our daily work.
It has all the features described above, is fast and has a low memory consumption.
You can also use one of the conventional JVMPI profilers, which use another
approach as our tool and have some support in find memory leaks.
The most known tools are OptimizeIt and JProbe.
What can I do to prevent memory leaks when I write code?
We've listed the few coding patterns that usually cause memory leaks.
Please look at The Top Five - Why we have a data cancer.
| |
 |
|
Reference Scanner
Inspect your running Java application from a web browser:
Create heap snapshots and snapshot diffs. View and eliminate memory leaks.
Analyze full object reference graphs ...
More ...
| |
|
|
