LeakCanary: Detect all Android memory leaks
corner.squareup.com
LeakCanary: Detect all Android memory leaks
1–10 of 12 posts
Re: LeakCanary: Detect all Android memory leaks
#2Is 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.
Re: LeakCanary: Detect all Android memory leaks
#3Is 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…
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.
Re: LeakCanary: Detect all Android memory leaks
#4Is 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…
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.
Re: LeakCanary: Detect all Android memory leaks
#5Is 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…
> 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.
Re: LeakCanary: Detect all Android memory leaks
#6Seeing 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.
Re: LeakCanary: Detect all Android memory leaks
#7Seeing 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 ;)
Re: LeakCanary: Detect all Android memory leaks
#8Is 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…
> 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 th…
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.
Re: LeakCanary: Detect all Android memory leaks
#9Is 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…
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.
Re: LeakCanary: Detect all Android memory leaks
#10Is 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…
> 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 th…
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.