Изящная доработка референта SoftReference

Ответ Тома правильный, однако код, который был добавлен к вопросу, не совпадает с тем, который был предложен Томом. То, что предлагал Том, выглядит примерно так:

class Bloat {  // just a heap filler really
    public Reader res;
    private double a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z;

    private final int ii;

    public Bloat(final int ii, Reader res) {
       this.ii = ii;
       this.res = res;
    }
 }

 // as recommended by Tom Hawtin
 class MySoftBloatReference extends SoftReference<Bloat> {
    public final Reader hardRef;

    MySoftBloatReference(Bloat referent, ReferenceQueue<Bloat> q) {
       super(referent, q);
       this.hardRef = referent.res;
    }
 }

 //...meanwhile, somewhere in the neighbouring galaxy...
 {
    ReferenceQueue<Bloat> rq = new ReferenceQueue<Bloat>();
    Set<SoftReference<Bloat>> set = new HashSet<SoftReference<Bloat>>();
    int i=0;

    while(i<50000) {
        set.add(new MySoftBloatReference(new Bloat(i, new StringReader("test")), rq));

        MySoftBloatReference polled = (MySoftBloatReference) rq.poll();

        if (polled != null) {
            // close the reference that we are holding on to
            try {
                polled.hardRef.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
        i++;
    }
}

Обратите внимание, что большая разница заключается в том, что жесткая ссылка относится к объекту, который необходимо закрыть. Окружающий объект может и будет собираться мусором, поэтому вы не столкнетесь с OOM, однако у вас все еще есть шанс закрыть ссылку. Как только вы выйдете из цикла, он также будет удален сборщиком мусора. Конечно, в реальном мире вы, вероятно, не стали бы делать res общедоступным членом экземпляра.

Тем не менее, если вы держите открытые ссылки на файлы, вы рискуете исчерпать их до того, как у вас закончится память. Возможно, вы также захотите иметь кэш LRU, чтобы гарантировать, что вы храните не более тыкает пальцем в воздух 500 открытых файлов. Они также могут иметь тип MyReference, чтобы при необходимости их также можно было удалить сборщиком мусора.

Чтобы немного прояснить, как работает MySoftBloatReference, базовый класс, то есть SoftReference, по-прежнему содержит ссылку на объект, занимающий всю память. Это объект, который вам нужно освободить, чтобы предотвратить OOM. Однако, если объект освобожден, вам все равно нужно освободить ресурсы, которые использует Bloat, то есть Bloat использует два типа ресурсов, память и дескриптор файла, оба эти ресурса должны быть освобождены, или вы запускаете из тех или иных ресурсов. SoftReference справляется с нагрузкой на ресурс памяти, освобождая этот объект, однако вам также необходимо освободить другой ресурс, дескриптор файла. Поскольку Bloat уже освобожден, мы не можем использовать его для освобождения связанного ресурса, поэтому MySoftBloatReference сохраняет жесткую ссылку на внутренний ресурс, который необходимо закрыть. После получения информации о том, что Bloat был освобожден, т. е. когда ссылка появляется в ReferenceQueue, MySoftBloatReference также может закрыть связанный ресурс через имеющуюся у него жесткую ссылку.

EDIT: Обновлен код, чтобы он компилировался при попадании в класс. Он использует StringReader, чтобы проиллюстрировать концепцию закрытия Reader, который используется для представления внешнего ресурса, который необходимо освободить. В этом конкретном случае закрытие этого потока фактически не является операцией и поэтому не требуется, но показывает, как это сделать, если это необходимо.

Для конечного числа ресурсов: Подкласс SoftReference. Мягкая ссылка должна указывать на окружающий объект. Сильная ссылка в подклассе должна ссылаться на ресурс, поэтому он всегда строго доступен. При чтении через ReferenceQueue poll ресурс может быть закрыт и удален из кеша. Кэш должен быть освобожден правильно (если сам SoftReference является сборщиком мусора, его нельзя поставить в очередь на ReferenceQueue).

Будьте осторожны, чтобы у вас было только конечное количество неиспользованных ресурсов в кеше - удалите старые записи (действительно, вы можете отказаться от мягких ссылок с помощью конечного кеша, если это подходит для вашей ситуации). Обычно более важным является ресурс, не относящийся к памяти, и в этом случае должно быть достаточно кэша LRU-вытеснения без экзотических ссылочных объектов.

(Мой ответ № 1000. Опубликовано с Лондонского дня разработчиков.)

Ахм.
(Насколько я знаю) Палку нельзя держать за оба конца. Либо вы храните свою информацию, либо отказываетесь от нее.
Однако... вы можете сохранить некоторую ключевую информацию, которая позволит вам завершить работу. Конечно, ключевая информация должна быть значительно меньше «реальной информации» и не должна содержать реальную информацию в доступном графе объектов (в этом вам могут помочь слабые ссылки).
Опираясь на существующий пример (обратите внимание на ключевое информационное поле):

public class Test1 {
    static class Bloat {  // just a heap filler really
        private double a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z;

        private final int ii;

        public Bloat(final int ii) {
            this.ii = ii;
        }
    }

    // as recommended by Tom Hawtin
    static class MyReference<T, K> extends SoftReference<T> {
        private final K keyInformation;

        MyReference(T referent, K keyInformation, ReferenceQueue<? super T> q) {
            super(referent, q);
            this.keyInformation = keyInformation;
        }

        public K getKeyInformation() {
            return keyInformation;
        }
    }

    //...meanwhile, somewhere in the neighbouring galaxy...
    public static void main(String[] args) throws InterruptedException {
        ReferenceQueue<Bloat> rq = new ReferenceQueue<Bloat>();
        Set<SoftReference<Bloat>> set = new HashSet<SoftReference<Bloat>>();
        int i = 0;

        while (i < 50000) {
            set.add(new MyReference<Bloat, Integer>(new Bloat(i), i, rq));

            final Reference<? extends Bloat> polled = rq.poll();

            if (polled != null) {
                if (polled instanceof MyReference) {
                    final Object keyInfo = ((MyReference) polled).getKeyInformation();
                    System.out.println("not null, got key info: " + keyInfo + ", finalizing...");
                } else {
                    System.out.println("null, can't finalize.");
                }
                rq.remove();
                System.out.println("removed reference");
            }

Редактировать:
Я хочу подробнее остановиться на «либо храните свою информацию, либо отпустите ее». Предполагая, что у вас был какой-то способ хранить информацию. Это заставило бы GC снять пометку с ваших данных, в результате чего данные фактически были бы очищены только после того, как вы закончите с ними, во втором цикле GC. Это возможно - и это именно то, для чего предназначен finalize(). Поскольку вы заявили, что не хотите повторения второго цикла, вы не можете хранить свою информацию (если a-->b, то !b-->!a). что означает, что вы должны отпустить его.

Edit2:
На самом деле произойдет второй цикл, но для ваших «ключевых данных», а не для ваших «основных данных раздувания». Фактические данные будут очищены в первом цикле.

Edit3:
Очевидно, что реальное решение будет использовать отдельный поток для удаления из эталонной очереди (не poll(), remove(), блокировка в выделенном потоке).

@Paul - большое спасибо за ответ и разъяснение.

@Ran - я думаю, что в вашем текущем коде i++ отсутствует в конце цикла. Кроме того, вам не нужно выполнять rq.remove() в цикле, поскольку rq.poll() уже удаляет верхнюю ссылку, не так ли?

Несколько моментов:

1) Мне пришлось добавить оператор Thread.sleep(1) после i++ в цикле (для обоих решений Пола и Рана), чтобы избежать OOM, но это не имеет отношения к общей картине и также зависит от платформы. Моя машина имеет четырехъядерный процессор и работает под управлением Sun Linux 1.6.0_16 JDK.

2) После просмотра этих решений я думаю, что буду использовать финализаторы. Книга Блоха приводит следующие причины:

• нет никакой гарантии, что финализаторы будут выполнены быстро, поэтому никогда не делайте в финализаторе ничего критичного по времени — и нет никаких гарантий для SoftRerences!
• Никогда не полагайтесь на финализатор для обновления критического постоянного состояния — я не
• существует серьезное снижение производительности при использовании финализаторов - в моем худшем случае я буду финализировать примерно один объект в минуту или около того. Я думаю, я могу жить с этим.
• используйте try/finally -- о да, я обязательно это сделаю!

Необходимость создавать огромное количество лесов только для того, что кажется простой задачей, не кажется мне разумной. Я имею в виду, буквально, скорость WTF в минуту была бы довольно высокой для любого, кто смотрит на такой код.

3) К сожалению, нет возможности разделить баллы между Полом, Томом и Раном :( Надеюсь, Том не будет возражать, поскольку он уже получил их много :) Судить между Полом и Раном было намного сложнее - я думаю, что оба ответа работают и верны. Я устанавливаю флаг принятия только для ответа Пола, потому что он был оценен выше (и имеет более подробное объяснение), но решение Рана совсем неплохое и, вероятно, было бы моим выбором, если бы я решил реализовать его с помощью SoftReferences. Спасибо, парни!