If I store bitmaps in a hashmap using SoftReference, will SoftReference call .recycle() on the Bitmap ? And if it doesn't then what would be a way to clear the bitmap properly from memory under the given situation (when bitmaps are inside a HashMap) ?
4 Answers
From Bitmap.recycle doc:
This is an advanced call, and normally need not be called,
since the normal GC process will free up this memory when there
are no more references to this bitmap.
So, to weakly hold the Bitmap is enough. If for some reason you need to agressively free this resource, you're out of luck with a weak reference.
EDIT
I'm not familiar with the Bitmap implementation in android, but what might happen that forces one to deal with Bitmap resources explicitly is the fact that some memory is not created on the heap. So the process may run out of memory while there's no need for GC. Imagine a small object holding a large memory chunk malloced from somewhere else. The finalize of the object may be prepared to free the memory, but there is no reason for the VM to GC, so the native memory is "lost".
But in this case a weak reference will not help either, as it is handled only after a gc. Only thing that helps here is to explicit "recycle" maybe with the help of reference counting.

- 4,720
- 3
- 24
- 33
-
I agree with this, it should be fine without any custom work. – Thomas Vervest Jan 02 '11 at 20:21
-
how about extending from Bitmap class and then overriding it finalize() ? – 2cupsOfTech Jan 02 '11 at 22:15
-
Why should you do? As stated in the docs, resources are freed upon GC. Finalize would do nothing else (but adding overhead). Whats your intention? – mtraut Jan 03 '11 at 11:25
-
Ok - there can be a (known) bug in "Bitmap" so that the statement in the docs is not true. In this case you should look up the corresponding issue and its current state. But i can't believe you'll find one. The other possibility is that other users have other usage scenarios. Maybe they reference the Bitmap instances hard and do not clear the references after use. So **they** must "recycle". I can only tell you from regarding the docs you must do nothing but no longer reference the bitmap. I've added a side not above... – mtraut Jan 04 '11 at 10:22
-
You are right. Weak references does not helps to implement memory cache of images because on pre honeycomb versions memory for images allocated outside heap. – HighFlyer Mar 06 '12 at 07:08
If I store bitmaps in a hashmap using SoftReference, will SoftReference call .recycle() on the Bitmap ?
No. What if instead of a Bitmap
you store a String
or a POJO? Do they have the recycle
method? Of course no. So, the question is: what's SoftReference
for?
You use a
SoftReference
when you want the referenced object to stay alive until the host process is running low on memory. The object will not be eligible for collection until the collector needs to free memory. Loosely stated, binding aSoftReference
means, "Pin the object until you can't anymore." (link)
You don't have to care about clearing the Bitmap (invoking the recycle
method); just let the SoftReference
do its work.
-
5I can't find the comment by romainguy where he mentioned call .recycle() to clear bitmap otherwise you will run into memory problems, if you ask people at android-dev, anyone who has worked with bitmaps on android knows that without calling .recycle() problems start to emerge – 2cupsOfTech Jan 02 '11 at 21:54
-
I agree with 2cupsOfTech. You definitly have to call recycle on Bitmaps, although documentation claims the opposite. Otherwise you will get troubles on devices with small heap size. – Apfelsaft Jun 05 '13 at 08:45
Bitmap's associated resources will be freed upon GC, thanks to it's finalize()
method. recycle()
is to free the resources without waiting for it, if you know it is no longer needed, which is not your case. You use SoftReference
because you want to recycle the image if there is out of memory condition.

- 10,221
- 3
- 55
- 76
If the object referenced by the WeakReference will be GC'd, I'd assume this whill trigger the recycle method on the bitmap. However I'm not sure, so just to be on the safe side you could do something like overriding the WeakReference class, making a Bitmap-specific WeakReference class that calls the recycle method when it's refrence is GC'd.
The solution should ook something like this, but it's untested:
private final class WeakBitmapReference extends WeakReference<Bitmap> {
public WeakBitmapReference(Bitmap b) {
super(b);
}
public void clear() {
Bitmap b = get();
if (b != null && !b.isRecycled())
b.recycle();
super.clear();
}
}

- 2,131
- 1
- 16
- 13
-
I'm afraid this won't work. VM will not call "clear" at any point. Adding to a reference queue won't work either, as "get" no longer will return any result. – mtraut Jan 02 '11 at 20:34