Using Java's ReferenceQueue

2020-01-27 13:16发布

问题:

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?

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



回答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



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



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