Использование Java ReferenceQueue

Одна общая идиома с эталонными очередями, например. подкласс WeakReference, чтобы прикрепить информацию, необходимую для очистки, а затем опросить ReferenceQueue, чтобы получить задачи очистки.

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().
}

Например, внутреннее устройство реализации CacheBuilder в Guava при выборе weakKeys использует этот подход.

Если у объекта есть только WeakReferences (или вообще нет ссылок!) на него, он может быть удален сборщиком мусора всякий раз, когда Java нужно освободить больше места в памяти. Таким образом, вы используете WeakReference всякий раз, когда хотите, чтобы объект оставался в памяти, но вам не нужно, чтобы он оставался ТАКИМ плохим (например, если Java нужно собрать его мусором, нет проблем, вы можете вернуть его как-нибудь и в то же время Java имеет лучшую производительность)

Постановка в очередь WeakReference позволяет выполнить итерацию ReferenceQueue и определить, какие ссылки были удалены сборщиком мусора, а какие нет. Вот и все — так что делайте это только в том случае, если вам нужно это знать.

Подробнее: http://weblogs.java.net/blog/2006/05/04/understanding-weak-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;
}

Я показываю здесь свою старую школу — в новых java-пакетах, вероятно, есть гораздо более изящные способы сделать это.

Не уверен, в чем здесь вопрос, но:

1) soft ref пытается сохранить ссылку до тех пор, пока jvm действительно не понадобится память. Отлично подходит для кешей, особенно LRU. Посмотрите на множество примеров в Guava.

2) слабая ссылка вообще не пытается помешать gc освободить объект. Они используются, если вы хотите знать, используется ли этот объект где-либо еще. Например, они используются для хранения информации о потоках и классах, поэтому, когда поток или класс больше не используются, мы можем отбросить связанную с ними метаинформацию.

3) фантомная ссылка похожа на слабую, но не позволяет ссылаться на реальный объект. Таким образом, вы можете быть уверены, что передача фантома не может возобновить реальный объект (это риск со слабой ссылкой). Также фантомная ссылка блокирует собираемый объект, пока вы не очистите ссылку.

ReferenceQueue: туда ничего не помещается. gc сделает за вас. Они позволяют вам узнать, когда некоторые ссылки будут выпущены, без необходимости проверять их одну за другой.