4. Java/Android Garbage Collection
• All objects created with new are stored on the heap
• GC periodically disposes of objects that are eligible for
garbage collection
• Android GC uses a mark-and-sweep algorithm
5. What is “eligible for garbage collection”?
• Not reachable from any live threads or any static
references
− There are no references to the object!
• Cyclic references are not counted.
6. What is “eligible for garbage collection”?
Simple Example:
Integer volume = new Integer(100);
Integer
System.out.println(volume); 100
volume = null;
Volume
7. What is “eligible for garbage collection”?
Simple Example:
Integer volume = new Integer(100);
Integer
System.out.println(volume); 100
volume = null;
Volume
8. What is “eligible for garbage collection”?
Simple Example:
Integer volume = new Integer(100);
Integer
System.out.println(volume); 100
volume = null; null
Volume
9. What is “eligible for garbage collection”?
Simple Example:
Integer volume = new Integer(100); Integer
Garbage
System.out.println(volume); collected!
volume = null; null
Volume
10. What is “eligible for garbage collection”?
• Lists, Maps, and Sets are prime suspects for memory
leaks, because they can accidentally retain references to
unused objects!
Integer volume = new Integer(100);
Integer
System.out.println(volume); 100
volumeList.add(volume); null
volume = null; Volume volumeList
11. Haiku Break #1
Memory leak, crash.
Lingering reference, why!?
You make GC cry.
12. Detecting a memory leak
Clue #1: Your application crashes with an
java.lang.OutOfMemoryError after running for a long time.
Clue #2: You see frequent GC_ lines in logcat before the
crash.
D/dalvikvm( 1325): GC_CONCURRENT freed 1971K,
18% free 12382K/14983K, paused 3ms+7ms
Heap statistics
Reason for garbage
collection:
GC_CONCURRENT
GC_FOR_MALLOC
GC_EXTERNAL_ALLOC
GC_HPROF_DUMP_HEAP
GC_EXPLICIT
13. Identifying the source of the leak
• Step #1
Use DDMS (Dalvik Debug Monitor Server) to dump heap
snapshots (an HPROF file)
− android-sdkstoolsddms.bat
14. Identifying the source of the leak
• Step #2
Use the Android SDK’s “hprof-conv” tool to convert the
Android-specific HPROF file into a generic HPROF file
that can be analyzed by Eclipse Memory Analyzer
15. Identifying the source of the leak
• Step #3
Open the converted HPROF using Eclipse Memory
Analyzer
16. Identifying the source of the leak
• Step #4
Analyze the results using the “Histogram” view
17. Identifying the source of the leak
• Step #4
Analyze the results using the “Histogram” view
• Identifies types of objects allocated!
• Doesn’t know whether they will eventually be freed!
• We must compare two HPROF snapshots to identify
which objects are responsible for a leak.
18. Identifying the source of the leak
• Step #5
Exercise your app in a way that tends to cause it to
exhibit the memory leak, and then use DDMS to dump
another heap snapshot
• Step #6
Use “hprof-conv” to convert the HPROF file
19. Identifying the source of the leak
• Step #7
Open both HPROF files in Eclipse Memory Analyzer and
compare their histograms
20. Identifying the source of the leak
• Step #7
Open both HPROF files in Eclipse Memory Analyzer and
compare their histograms
− Compare the number of instances and sizes of each type of object
between the two snapshots.
− A sustained increase in the number of objects may indicate a leak!
21. Identifying the source of the leak
• Step #7
Open both HPROF files in Eclipse Memory Analyzer and
compare their histograms
− Compare the number of instances and sizes of each type of object
between the two snapshots.
− An unexplained increase in the number of objects may indicate a
leak!
22. Identifying the source of the leak
• Step #7
Shallow heap: the size of the objects themselves.
Retained heap: the amount that would be freed if we freed
these objects (greater than shallow heap because
referenced objects may also be freed).
23. Haiku Break #2
Unfreed memory,
Delta of two HPROF dumps
Who references thou?
24. Fixing the leak
• The leak must be the result of unused objects still having
references to them so, you can do one of:
− Stop creating the objects
− Stop maintaining references to the objects
− Use weak references (see WeakHashMap) so that those
references are invalidated if they are the only ones to the object.
− Make sure to close() open streams and connections
25. More Information
• Google I/O 2011: Memory management for Android
Apps https://www.youtube.com/watch?v=_
CruQY55HOk&feature=relmfu