Um, slightly too strong a statement. As soon as it's not used outside the cache, it's ELIGIBLE for garbage collection, which is likely to happen soon.
There are times this is appropriate for a cache. If the objects you're likely to look up again, are also likely to still be live, but expensive to find, but can be expected to eventually drop out of use (and liveness), then WeakReference is the right choice. Or when your cached object is so big, you want them to go away as soon as possible, but sometimes you reference them again before they've gone dead, or before the GC actually got a chance to collect them. Typically such a cache might only hold the one or two latest objects. Not your typical general-purpose cache scenarios, however. My main concern with your statement is that it would imply that there's some mechanism that instantly nulls out the reference as soon as the last live reference is dropped. It's not instant -- but that WOULD be the ideal behavior for a GC, and one benefit of good GC techniques is that they improve the odds of early collection of short- lived garbage. WeakReferences are more useful for associating an object for as long as it exist, without prolonging that existence. I find it harder to explain what that means, than to actually decide when they're needed. On Jul 22, 11:26 am, Romain Guy <romain...@android.com> wrote: > You definitely do NOT want to use a WeakReference to cache object. If > you do so, as soon as your data is put in the cache and not used > outside of the cache, it gets garbage collected. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
