Using Java's ReferenceQueue

Question

Do SoftReference and WeakReference really only help when created as instance variables? Is there any benefit to using them in method scope?

The other big part is ReferenceQueue. Besides being able to track which references are determined garbage, can Reference.enqueue() be used to forcibly register an object for garbage collection?

For example, would it be worth to create a method that takes some heavy memory resources (held by strong references) in an object and creating References to enqueue them?

Object bigObject;
public void dispose() {
    ReferenceQueue<Object> queue = new ReferenceQueue<Object>();
    WeakReference<Object> ref = new WeakReference<Object>(bigObject, queue);
    bigObject = null;
    ref.enqueue();
}

(Imagine that Object in this case represents an object type that uses a lot of memory... like BufferedImage or something)

Does this have any realistic effect? Or is this just a waste of code?

Solution 1

One common idiom with reference queues is to e.g. subclass WeakReference to attach information that's needed to clean up things, and then to poll a ReferenceQueue to get cleanup tasks.

ReferenceQueue<Foo> fooQueue = new ReferenceQueue<Foo>();

class ReferenceWithCleanup extends WeakReference<Foo> {
  Bar bar;
  ReferenceWithCleanup(Foo foo, Bar bar) {
    super(foo, fooQueue);
    this.bar = bar;
  }
  public void cleanUp() {
    bar.cleanUp();
  }
}

public Thread cleanupThread = new Thread() {
  public void run() {
    while(true) {
      ReferenceWithCleanup ref = (ReferenceWithCleanup)fooQueue.remove();
      ref.cleanUp();
    }
  }
}

public void doStuff() {
  cleanupThread.start();
  Foo foo = new Foo();
  Bar bar = new Bar();
  ReferenceWithCleanup ref = new ReferenceWithCleanup(foo, bar);
  ... // From now on, once you release all non-weak references to foo,
      // then at some indeterminate point in the future, bar.cleanUp() will
      // be run. You can force it by calling ref.enqueue().
}

For example, the internals of Guava's CacheBuilder implementation when weakKeys are selected uses this approach.

Solution 2

If an object has only WeakReferences (or no references whatsoever!) towards it, it can be garbage collected whenever Java needs to make more room in memory. So, you use WeakReferences whenever you want an object to remain in memory, but you don't need it to remain THAT badly (e.g. if Java needs to garbage collect it, no problem, you can get it back somehow and in the mean time Java has better performance)

Enqueuing a WeakReference allows you to iterate the ReferenceQueue and determine which references have been garbage collected and which have not. That's all - so only do it if you need to know this.

Read more: http://weblogs.java.net/blog/2006/05/04/understanding-weak-references

Solution 3

One common thing to do is to create maps of soft references.

Map<String, SoftReference<BigThing>> cache = new HashMap<>();
Set<String> thingsIAmCurrentlyGetting = new HashSet<String>();
Object mutex = new Object();

BigThing getThing(String key) {
  synchronized(mutex) {
    while(thingsIAmCurrentlyGetting.contains(key)) {
      mutex.wait();
    }
    SoftReference<BigThing> ref = cache.get(key);
    BigThing bigThing = ref == null ? null : ref.get();
    if(bigThing != null) return bigThing;
    thingsIAmCurrentlyGetting.add(key);
  }

  BigThing bigThing = getBigThing(key); // this may take a while to run.

  synchronized(mutex) {
    cache.put(key, bigThing);
    thingsIAmCurrentlyGetting.remove(key);
    mutex.notifyAll();
  }

  return bigThing;
}

I'm showing my old school here - the new java packages probably have much neater ways to do this.

Solution 4

Not sure what is the question here but:

1) soft ref try to keep the reference until jvm really really needs the memory. Great for caches, esp LRU ones. Look at many examples in Guava.

2) weak ref don't try to prevent gc to free the object at all. They are used if you want to know if that object is still used somewhere. For example they are used to store info about threads and classes, so that when the thread or the class is not used anymore we can discard the metainfo related to that.

3) phantom ref are like weak but without letting you reference the actual object. In this way you can be sure that passing the phantom around cannot resume the actual object (this is a risk with weak ref). Also phantom ref are blocking the object to be collected until you clear the ref.

ReferenceQueue: you don't enque stuff in there. gc will do for you. They allows you to know when some references get released, without having to check them one by one.

View more solutions

Comments

[Pacerier]

Mildly related: codereview.stackexchange.com/q/28534/4394

[bgroenks]

I know that. But my question is, does the enqueue() method force the WeakReference to be garbage collected or registered for garbage collection?

[Patashu]

No. If you need it to be garbage collected right now, remove all strong references and tell the garbage collector to run.

[bgroenks]

So is it waiting until the reference is enqueued, then invoking cleanUp? Do they ever actually invoke enqueue()?

[bgroenks]

I don't think that's guaranteed to do it though. What does enqueue() actually do?

[Louis Wasserman]

As per the enqueue doc, you don't actually need to call enqueue. The reference object gets added to the reference queue when the referred object gets GC'd.

[bgroenks]

It also says the GC doesn't use it. So why does it exist I wonder?

[Louis Wasserman]

In case you want to call it explicitly. Lots of these things have extraordinarily narrow use cases, but exist because they would be impossible to get unless explicitly provided.

[bgroenks]

When would you want to explicitly invoke it?

[Louis Wasserman]

I've never heard of a convincing use case, but maybe if you wanted to explicitly clean something up whether or not the reference had actually been GC'd.

[bgroenks]

Hmmm. I guess I can see why someone might need that. At least maybe in the context of a larger system that depended on the results returned by ReferenceQueue. Thanks for your help!

[arkon]

@bgroenks Enqueueing refers to the act of placing in item at the tail of an associated queue. You technically can't force the GC to do anything. The GC never even invokes the enqueue() method, it enqueues references directly. The only way to ensure an object is eligible for garbage collection is by destroying any and all live references to that object.

[PaulMurrayCbr]

Oh, hang on - this is not what your question was about at all! Its completely irrelevant!

[nsayer]

You would explicitly enqueue an object if you had a path that included a facility to call a cleanup method, but were using WeakReferences and a ReferenceQueue is a defense against resource exhaustion by sloppy code. Things like third-party connection pool classes would do this.

[Gavriel]

@Patashu, why do I need a ReferenceQueue to "determine which references have been GC-d", if I can do if (weekReference.get() == null) ?

[Ajax]

Honestly, this is actually a very good real-world example of how to correctly use a soft/weak reference to correctly lazy-initialize objects (without race conditions or Lock), which notifies other waiting threads... He forgot to say that no, creating and enqueuing references will not help at all, and is a waste of code. You need all YOUR non-gc'd references to a big object to be nulled out (lest they prevent GC...)

[Tavian Barnes]

@Gavriel Because a busy-loop like while (weakReference.get() != null) burns too much CPU. ReferenceQueue lets you sleep until an object is available for you to finalize.

[Pacerier]

@Patashu, Since there's already WeakHashMap, is it true to say that ReferenceQueue is pointless?

[Pacerier]

@LouisWasserman, There's no use case for it. @nsayer, Even third-party connection pool classes don't need it. enqueue is a failed API only used by phail code.

[Dominique Unruh]

Is there a reason why this example uses a WeakReference and not a PhantonReference? Since the get method of the reference is never called, a PhantonReference should work, and I guess (although I am not sure of this) that it makes sense to use the weakest possible reference to give the GC as much flexibility as possible.

[Aleksandr Dubinsky]

"Also phantom ref are blocking the object to be collected until you clear the ref." That doesn't make sense.

[user102008]

@AleksandrDubinsky: In Java 8 and below, phantom references are not automatically cleared when they are enqueued into the ReferenceQueue, so the object they reference will remain phantom-reachable and cannot be reclaimed until you take the phantom reference out of the ReferenceQueue. This was changed in Java 9 to have phantom references be cleared when they are enqueued.