LeakCanary: Detect all Android memory leaks | Hacker News Reader

LeakCanary: Detect all Android memory leaks

corner.squareup.com

101 pointsjuandg11 comments

Seeing yet another android related open source project by square, I'd like to use the opportunity to leave a huge "thank you" here.

Between Picasso, Retrofit and especially okhttp, square has done such an amazing job to make android developers lives so much easier. The three projects are a pleasure to work with, have excellent documentation and very clear APIs.

So, yeah, a huge heartfelt "thank you" from me.

Want to come build the next great Android project? https://squareup.com/careers ;)

Is this a true "leak"? Maybe I'm naive but I would think you couldn't have a leak without using JNI. Maybe a reference cycle is hard/impossible to GC?

>Later, in a background thread, it checks if the reference has been cleared and if not it triggers a GC. > If the reference is still not cleared ...

Sounds to me like it's not a leak so much as unbounded-memory-growth.

But sounds like a useful tool. And I guess you can suppress warnings using AndroidExcludedRefs.java if you have intentional cycles.

One could very loosely define a 'leak' as "memory the author didn't expect to be retained past the next few GC cycles".

It looks like this tool helps you check your assumptions about how long your objects are kept alive.

Indeed. In general Java doesn't have memory 'leaks' in the same way as other languages/runtimes, in that things that are kept hanging around are in theory still accessible.

It's possible to have things hanging about that are theoretically access able about but will never be accessed again, which is generally what's meant by 'a memory leak' in a Java context.

> Is this a true "leak"?

By most people's definition of the term, sure. It ends up being a loss of memory within an object or set of objects that no longer have any practical use to the application and the irreclaimable memory can grow over time.

> Maybe a reference cycle is hard/impossible to GC

This is basically the issue.

It is relatively common (particularly among younger programmers who haven't been bitten by this already) to have a situation where you have an Android Activity that creates and holds a reference to an event listener which traps a reference to the activity itself. If the Activity doesn't clean up the the listener reference in its onDestroy (which is an Android lifecycle callback, not related to the Java GC) and neither reference is a WeakReference you wind up with a listener object which references the activity and an activity which references the listener object, neither of which is suitable for naive garbage collection... so now you have this lingering Activity object that is probably no longer associated with the application's window but lives on. If the app is designed such that the user keeps pathing through this Activity and the activity consumes lots of memory, it isn't hard to get fatal OOMs from this situation.

I guess this is why i from time to time come across one or more process that can't be killed by any means short of a device reboot, and all it does is hog memory.

From what I've seen, Java's GC is smart enough to clean up circular references. That actually surprised me. The main danger I've seen in Android is that there is a lot of passing around Contexts as a dependency for accessing Android resources, many of which are meant to be short lived, like Activities. Sometimes a class will save that context as an instance variable. And sometimes you might want to cache that class statically, so if you aren't careful, you'll prevent something like an Activity from garbage collection.

Android has precise GC so it will free the unused memory even if there are loops within it.

What it won't help with are cases like: public class MainStuff { private byte[] myBuffer;

      public void doStuff() {
          myBuffer = new byte[20 * 1024 * 1024];
          doStuffWithBuffer(myBuffer);
      }
  
      private void doStuffWithBuffer(byte[] buffer) {
          /* omitted */
      }
  
  }

Here, we program keeps myBuffer around as long as MainStuff lives which can be very long if it is, say, a main class of your program.

It's just that the cases where the memory is kept around are not as easy for the programmer to spot as this example for reference-hierarchies are deeper.

A "garbage collection leak" is a leak if you have a reference to an object that you don't really need anymore.

Consider a Document Object Model tree with 20 MB of memory. Each child holds a reference to its parent. If there are no references from outside the tree to anywhere inside it, it will eventually be collected. But one single reference to a DOM node from anywhere outside the DOM, and you've leaked twenty meg.

The most common large leak I have seen in Android apps is created that way : -create an object containing a strong reference to an Activity. Activity is kind of a god object in the Android framework. It can loosely be defined as a screen in the app. Views for example always contain a reference to their parent activity.

-Make a screen rotation and persist that object.

-During the rotation, the Activity reaches the end of its lifecycle and a new one is created.

-The retained object keeps a reference to its Activity. It should be collectable by the GC by now but it is not possible because of this object holding a strong reference to it. It does not stop here, the Activity almost certainly contains references to many other objects that similarly cannot be reclaimed.

It might not be very similar to the leaks encountered in c/c++ but it is very easy to create such issues in GC languages such as Java.

Reply on news.ycombinator.com