3 ms·

> 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 hav

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

digi_owl 12y ago
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.
gumballhead 12y ago
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.
eonwe 11y ago
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.

digi_owl 12y ago

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.

gumballhead 12y ago

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.

eonwe 11y ago

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.