Identifying memory leaks in Android applicationsZachary Blair

Doesn’t Java handle memory management?!!!1

http://memegenerator.net/instance/27508171

Garbage collection != Immunity from memory leaks!

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

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.

What is “eligible for garbage collection”?

Simple Example:

Integer100

Integer volume = new Integer(100); System.out.println(volume); volume = null;

Integer100

Volume

What is “eligible for garbage collection”?

Integer100

Integer volume = new Integer(100); System.out.println(volume); volume = null;

Simple Example:

Volume

What is “eligible for garbage collection”?

Integer100

Integer volume = new Integer(100); System.out.println(volume); volume = null; null

Simple Example:

Volume

What is “eligible for garbage collection”?

Integer volume = new Integer(100); System.out.println(volume); volume = null; null

IntegerGarbagecollected!

Simple Example:

Volume

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!

Integer100

Integer volume = new Integer(100); System.out.println(volume); volumeList.add(volume);

volume = null;

null

Volume volumeList

Haiku Break #1

Memory leak, crash. Lingering reference, why!?

You make GC cry.

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

Reason for garbage collection:GC_CONCURRENTGC_FOR_MALLOCGC_EXTERNAL_ALLOCGC_HPROF_DUMP_HEAPGC_EXPLICIT

Heap statistics

Identifying the source of the leak

• Step #1Use DDMS (Dalvik Debug Monitor Server) to dump heap snapshots (an HPROF file)

− android-sdks\tools\ddms.bat

Identifying the source of the leak

• Step #2Use 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

Identifying the source of the leak

• Step #3Open the converted HPROF using Eclipse Memory Analyzer

Identifying the source of the leak

• Step #4Analyze the results using the “Histogram” view

Identifying the source of the leak

• Step #4Analyze 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.

Identifying the source of the leak

• Step #5Exercise 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 #6Use “hprof-conv” to convert the HPROF file

Identifying the source of the leak

• Step #7Open both HPROF files in Eclipse Memory Analyzer and compare their histograms

Identifying the source of the leak

• Step #7Open 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!

Identifying the source of the leak

• Step #7Open 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!

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).

Haiku Break #2

Unfreed memory,Delta of two HPROF dumps

Who references thou?

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

More Information

• Google I/O 2011: Memory management for Android Apps https://www.youtube.com/watch?v=_CruQY55HOk&feature=relmfu

Thank You