Using Java's ReferenceQueue

半世苍凉 提交于 2019-11-27 06:49:54
Louis Wasserman

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.

Patashu

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

PaulMurrayCbr

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.

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!