В чем разница между SoftReference и WeakReference в Java?

Слабые ссылки собираются с нетерпением. Если сборщик мусора обнаруживает, что объект слабо достижимый (достижимый только через слабые ссылки), он очистит слабые ссылки на этот объект немедленно. Таким образом, они хороши для сохранение ссылки на объект, для которого ваша программа также хранит (сильно упоминается) какая-то "связанная информация", например, кешированная информация об отражении о классе или оболочке для объекта и т. д. Все, что не имеет смысла хранить после объекта, с которым оно связано с GC-изд. Когда слабая ссылка очищается, она ставится в очередь в ссылочная очередь, которую ваш код где-то опрашивает, и отбрасывает связанные объекты. То есть вы храните дополнительную информацию о объект, но эта информация не нужна, если объект, на который она ссылается уходит. Фактически, в определенных ситуациях вы даже можете создать подкласс WeakReference и сохранить связанную дополнительную информацию об объекте. в полях подкласса WeakReference. Еще одно типичное использование WeakReference используется вместе с Maps для хранения канонических экземпляров.

SoftReferences, с другой стороны, хороши для кеширования внешних, воссоздаемых ресурсов. поскольку GC обычно задерживает их очистку. Однако гарантируется, что все SoftReferences будут очищены перед выбросом OutOfMemoryError, поэтому они теоретически не может вызвать OOME [*].

Типичный пример использования - сохранение проанализированной формы содержимого из файл. Вы бы реализовали систему, в которой вы загружали бы файл, анализировали его и сохраняли SoftReference на корневой объект анализируемого представления. В следующий раз вам нужен файл, вы попытаетесь получить его через SoftReference. Если вы можете получить его, вы избавили себя от еще одной загрузки / синтаксического анализа, и если сборщик мусора тем временем очистил, перезагружаешь. Таким образом, вы используете бесплатно память для оптимизации производительности, но не рискуйте OOME.

Теперь о [*]. Сохранение SoftReference само по себе не может вызвать OOME. Если с другой стороны, вы по ошибке используете SoftReference для задачи, подразумевается WeakReference для использования (а именно, вы каким-то образом сохраняете информацию, связанную с объектом имеет сильную ссылку, и отбросьте ее, когда объект Reference получит очищен), вы можете запустить OOME в качестве кода, который опрашивает ReferenceQueue и отбрасывает связанные объекты, которые могут не запускаться вовремя мода.

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

SoftReference предназначен для кешей. Когда обнаруживается, что WeakReference ссылается на другой недостижимый объект, он немедленно очищается. SoftReference можно оставить как есть. Обычно существует некоторый алгоритм, связанный с объемом свободной памяти и временем последнего использования, чтобы определить, следует ли ее очистить. Текущий алгоритм Sun состоит в том, чтобы очистить ссылку, если она не использовалась столько секунд, сколько мегабайт свободной памяти в куче Java (настраивается, сервер HotSpot проверяет максимально возможную кучу, установленную -Xmx). SoftReference будут очищены до того, как будет брошен OutOfMemoryError, если не будет достигнуто иное.

Из Понимание слабых ссылок, от Итана Николаса:

Weak references

A weak reference, simply put, is a reference that isn't strong enough to force an object to remain in memory. Weak references allow you to leverage the garbage collector's ability to determine reachability for you, so you don't have to do it yourself. You create a weak reference like this:

WeakReference weakWidget = new WeakReference(widget);

and then elsewhere in the code you can use weakWidget.get() to get the actual Widget object. Of course the weak reference isn't strong enough to prevent garbage collection, so you may find (if there are no strong references to the widget) that weakWidget.get() suddenly starts returning null.

...

Soft references

A soft reference is exactly like a weak reference, except that it is less eager to throw away the object to which it refers. An object which is only weakly reachable (the strongest references to it are WeakReferences) will be discarded at the next garbage collection cycle, but an object which is softly reachable will generally stick around for a while.

SoftReferences aren't required to behave any differently than WeakReferences, but in practice softly reachable objects are generally retained as long as memory is in plentiful supply. This makes them an excellent foundation for a cache, such as the image cache described above, since you can let the garbage collector worry about both how reachable the objects are (a strongly reachable object will never be removed from the cache) and how badly it needs the memory they are consuming.

И Питер Кесслер добавил в комментарии:

The Sun JRE does treat SoftReferences differently from WeakReferences. We attempt to hold on to object referenced by a SoftReference if there isn't pressure on the available memory. One detail: the policy for the "-client" and "-server" JRE's are different: the -client JRE tries to keep your footprint small by preferring to clear SoftReferences rather than expand the heap, whereas the -server JRE tries to keep your performance high by preferring to expand the heap (if possible) rather than clear SoftReferences. One size does not fit all.

Единственная реальная разница между мягкой и слабой ссылкой состоит в том, что

the garbage collector uses algorithms to decide whether or not to reclaim a softly reachable object, but always reclaims a weakly reachable object.

Слабая ссылкаhttp://docs.oracle.com/javase/1.5.0/docs/api/java/lang/ref/WeakReference.html

Принцип:weak reference относится к сборке мусора. Обычно объект, имеющий один или несколько reference, не подлежит сборке мусора. Вышеупомянутый принцип не применим, если это weak reference. Если объект имеет только слабую ссылку с другими объектами, он готов к сборке мусора.

Давайте посмотрим на приведенный ниже пример: У нас есть Map с объектами, где ключ ссылается на объект.

import java.util.HashMap;   
public class Test {

    public static void main(String args[]) {
        HashMap<Employee, EmployeeVal> aMap = new 
                       HashMap<Employee, EmployeeVal>();

        Employee emp = new Employee("Vinoth");
        EmployeeVal val = new EmployeeVal("Programmer");

        aMap.put(emp, val);

        emp = null;

        System.gc();
        System.out.println("Size of Map" + aMap.size());

    }
}

Теперь во время выполнения программы мы сделали emp = null. Map, удерживающий ключ, здесь не имеет смысла, так как это null. В приведенной выше ситуации сборщиком мусора не выполняется.

WeakHashMap

WeakHashMap - это тот, где записи (key-to-value mappings) будут удалены, когда их больше невозможно будет получить из Map.

Позвольте мне показать пример выше с WeakHashMap

import java.util.WeakHashMap;

public class Test {

    public static void main(String args[]) {
        WeakHashMap<Employee, EmployeeVal> aMap = 
                    new WeakHashMap<Employee, EmployeeVal>();

        Employee emp = new Employee("Vinoth");
        EmployeeVal val = new EmployeeVal("Programmer");

        aMap.put(emp, val);

        emp = null;

        System.gc();
        int count = 0;
        while (0 != aMap.size()) {
            ++count;
            System.gc();
        }
        System.out.println("Took " + count
                + " calls to System.gc() to result in weakHashMap size of : "
                + aMap.size());
    }
}

Выход: Взял 20 calls to System.gc(), чтобы получить aMap size из: 0.

WeakHashMap имеет только слабые ссылки на ключи, а не сильные ссылки, как у других классов Map. Есть ситуации, о которых вам нужно позаботиться, когда на значение или ключ есть сильная ссылка, хотя вы использовали WeakHashMap. Этого можно избежать, заключив объект в WeakReference.

import java.lang.ref.WeakReference;
import java.util.HashMap;

public class Test {

    public static void main(String args[]) {
        HashMap<Employee, EmployeeVal> map = 
                      new HashMap<Employee, EmployeeVal>();
        WeakReference<HashMap<Employee, EmployeeVal>> aMap = 
                       new WeakReference<HashMap<Employee, EmployeeVal>>(
                map);

        map = null;

        while (null != aMap.get()) {
            aMap.get().put(new Employee("Vinoth"),
                    new EmployeeVal("Programmer"));
            System.out.println("Size of aMap " + aMap.get().size());
            System.gc();
        }
        System.out.println("Its garbage collected");
    }
}

Мягкие ссылки.

Soft Reference немного сильнее этого слабого эталона. Мягкая ссылка разрешает сборку мусора, но просит сборщик мусора очистить ее, только если нет другого варианта.

Сборщик мусора не собирает агрессивно легко достижимые объекты, как это происходит со слабодоступными - вместо этого он собирает мягко доступные объекты только в том случае, если ему действительно «нужна» память. Мягкие ссылки - это способ сказать сборщику мусора: «Пока память не слишком тесна, я хотел бы оставить этот объект под рукой. Но если память становится действительно тесной, идите и соберите его, и я разберусь с ним. с этим. " Сборщик мусора должен очистить все мягкие ссылки, прежде чем он сможет выбросить OutOfMemoryError.

В Java; По порядку от сильнейшего к самому слабому: Сильный, Мягкий, Слабый и Призрачный.

Сильная ссылка - это обычная ссылка, которая защищает упомянутый объект от сбора сборщиком мусора. т.е. никогда не собирает мусор.

Мягкая ссылка имеет право на сбор сборщиком мусора, но, вероятно, не будет собираться, пока его память не понадобится. т.е. мусор собирается до OutOfMemoryError.

Слабая ссылка - это ссылка, которая не защищает объект, на который указывает ссылка, от сбора сборщиком мусора. т.е. мусор собирается, когда нет сильных или мягких ссылок.

Фантомная ссылка - это ссылка на объект, на который фантомно ссылаются после того, как он был завершен, но до того, как его выделенная память будет освобождена.

Источник

Аналогия: Предположим, что JVM - это королевство, Object - король королевства, а GC - атакующий королевство, который пытается убить короля (объект).

• Когда король Сильный, GC не может его убить.
• Когда король Мягкий, GC атакует его, но король правит королевством с защитой до тех пор, пока не будут доступны ресурсы.
• Когда король Слабый, GC атакует его, но правит королевством без защиты.
• Когда король Фантом, GC уже убил его, но король доступен через его душу.

Шесть типов состояний достижимости объектов в Java:

1. Сильныйly достижимые объекты - GC не будет собирает (вернуть память, занятую) этот вид объекта. Это достижимый через корневой узел или другой сильно достижимый объект (т.е. через локальные переменные, переменные класса, переменные экземпляра и т. д.)
2. Мягкийly достижимые объекты - GC может попытаться для сбора такого типа объектов в зависимости от нехватки памяти. Они доступны из корня через один или несколько мягкие справочные объекты
3. Слабыйly достижимые объекты - GC должен собирает такие объекты. Эти доступны из корня через один или несколько слабые опорные объекты
4. Объекты Воскрешающий - GC уже собирает эти объекты. Но они могут вернуться в одно из состояний - Сильный / Мягкий / Слабый исполнением какого-то финализатора
5. Фантомly достижимый объект - GC уже находится в процессе сбора этих объектов и определил, что их нельзя воскресить никаким финализатором (если он сам объявляет метод finalize (), то его финализатор будет запущен). Они доступны из корня через один или несколько фантомные опорные объекты
6. Объект Недоступен - объект не является ни сильно, ни мягко, ни слабо, ни фантомно достижимым и не может быть воскрешен. Эти объекты готовы к рекультивации.

Подробнее: https://www.artima.com/insidejvm/ed2/gc16.html «свернуть

Следует знать, что объект со слабыми ссылками будет собран только тогда, когда он имеет ТОЛЬКО слабые ссылки. Если у него есть хотя бы одна сильная ссылка, она не будет собрана, независимо от того, сколько у нее слабых ссылок.

Единственная реальная разница

Согласно документ, свободные WeakReferences должен очищаются работающим сборщиком мусора.

Согласно документ, свободные SoftReferences должен должны быть очищены до того, как будет брошен OOM.

Это единственная реальная разница. Все остальное не является частью контракта. (Я предполагаю, что последние документы являются договорными.)

SoftReferences полезны. Кеши, чувствительные к памяти, используют SoftReferences, а не WeakReferences.

Что касается использования WeakReference неверный, список бесконечен:

• паршивый хак для реализации softreference с приоритетом 2, так что вам не нужно писать его, все же он не работает должным образом, потому что кеш будет очищен при запуске каждый GC, даже если есть свободная память. См. https://stackoverflow.com/a/3243242/632951 для фаилов. (Кроме того, что, если вам нужно более двух уровней приоритета кеша? Для этого вам все равно понадобится настоящая библиотека.)

• паршивый способ связать данные с объектом существующего класса, все же, он создает утечку памяти (OutOfMemoryError), когда ваш GC решает сделать перерыв после создания ваших слабых ссылок. Кроме того, это безобразно: лучший подход - использовать кортежи.

• паршивый способ связать данные с объектом существующего класса, когда у класса хватит смелости сделать себя неклассифицированным, и он используется в существующий код функции, который вам нужно вызвать. В таком случае правильное решение - либо отредактировать класс и сделать его подклассом, либо отредактировать функцию и заставить ее использовать интерфейс вместо класса, либо использовать альтернативную функцию.

WeakReference: объекты, на которые имеются только слабые ссылки, собираются в каждом цикле сборки мусора (второстепенном или полном).

SoftReference: когда собираются только мягкие объекты, зависит от:

1. -XX: флаг SoftRefLRUPolicyMSPerMB = N (значение по умолчанию - 1000, или 1 секунда)

2. Количество свободной памяти в куче.

   Пример:

   • в куче 10 МБ свободного места (после полной сборки мусора);
   • -XX: SoftRefLRUPolicyMSPerMB = 1000

   Затем объект, на который ссылается только SoftReference, будет собран, если последний раз, когда к нему обращались, больше 10 секунд.

Этот статья может быть очень полезным для понимания сильных, мягких, слабых и фантомных ссылок.

Чтобы дать вам резюме,

Если у вас есть только слабые ссылки для объекта (без сильных ссылок), то объект будет возвращен GC в следующем цикле GC.

Если у вас есть только мягкие ссылки для объекта (без сильных ссылок), то объект будет возвращен GC только тогда, когда JVM исчерпает память.

Таким образом, вы можете сказать, что сильные ссылки имеют высшая сила (никогда не могут быть собраны GC)

Мягкие ссылки - это мощный, чем слабые ссылки (поскольку они могут выйти из цикла GC, пока JVM не исчерпает память)

Слабые ссылки - это еще менее мощный, чем мягкие ссылки (поскольку они не могут исключать какой-либо цикл GC и будут восстановлены, если у объекта нет другой сильной ссылки).

Ресторанная аналогия

• Официант - GC
• Вы - объект в куче
• Площадь / пространство ресторана - Пространство в куче
• Новый клиент - новый объект, которому нужен столик в ресторане

Теперь, если вы являетесь сильный клиент (аналогично сильной ссылке), то даже если в ресторан зайдет новый клиент или что-то подобное случится, вы никогда не покинете свой стол (область памяти в куче). Официант не имеет права сказать вам (или даже попросить) покинуть ресторан.

Если вы являетесь мягкий клиент (аналог мягкой ссылки), то, если в ресторан заходит новый клиент, официант не будет просить вас покинуть стол, если только не останется другого пустого стола для размещения нового клиента. (Другими словами, официант попросит вас покинуть столик только в том случае, если зайдет новый клиент и для этого нового клиента не останется другого стола)

Если вы слабый покупатель (аналог слабой ссылки), то официант по своему желанию может (в любой момент) попросить вас покинуть ресторан: P

Чтобы дать представление об использовании памяти в действии, я провел эксперимент с сильными, мягкими, слабыми и фантомными ссылками при большой нагрузке с тяжелыми объектами, сохраняя их до конца программы. Тогда отслеживаемое использование кучи и поведение сборщика мусора. Эти показатели могут варьироваться от случая к случаю, но, безусловно, дают понимание на высоком уровне. Ниже приведены результаты.

Поведение кучи и сборщика мусора при большой нагрузке

• Сильная / жесткая ссылка - По мере продолжения программы JVM не могла собрать сохраненный объект с сильной ссылкой. В конце концов оказался в «java.lang.OutOfMemoryError: пространство кучи Java»
• Мягкая ссылка - По мере продолжения программы использование кучи продолжало расти, но сборщик мусора OLD gen происходил, когда он приближался к максимальной куче. GC запустился немного позже по времени после запуска программы.
• Слабая ссылка - При запуске программы объекты начали завершаться и собираться почти сразу. В основном объекты собирались при сборке мусора молодого поколения.
• Призрачная ссылка - Подобно слабой ссылке, объекты, на которые ссылаются фантомы, также начали немедленно завершаться и собираться мусор. Не было сборщика мусора старого поколения, и все объекты собирались в самой сборке мусора молодого поколения.

Вы можете получить более подробную информацию о графики, статистика, наблюдения для этого эксперимента здесь.