Использование слабых ссылок - это то, что я никогда не видел в реализации, поэтому я пытаюсь выяснить, каков вариант использования для них и как будет работать реализация. Когда вам нужно было использовать WeakHashMapили WeakReferenceи как это было использовано?

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

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

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

WeakReference против SoftReference

Одно из различий, которое нужно прояснить, - это различие между a WeakReferenceи a SoftReference.

В основном WeakReferenceбудет GC-D в JVM с нетерпением, когда объект ссылки не имеет жестких ссылок на него. С SoftReferenceдругой стороны, объект d будет собираться сборщиком мусора до тех пор, пока ему действительно не понадобится освободить память.

Кэш, где значения хранятся внутри WeakReferences, будет довольно бесполезным (в a WeakHashMapэто ключи, на которые слабо ссылаются). SoftReferencesполезны для переноса значений, когда вы хотите реализовать кеш, который может увеличиваться и уменьшаться с доступной памятью.

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

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

Я должен был сделать это , чтобы добавить некоторые данные , java.awt.Componentчтобы обойти изменения в JRE между 1.4.2 и 1.5, я мог бы закрепил его подклассы каждый компонент я был заинтересован Int ( JButton, JFrame, JPanel....) , но это было много проще с гораздо меньшим количеством кода.

Еще один полезный случай для WeakHashMapи WeakReferenceявляется внедрение слушателем реестра .

Когда вы создаете что-то, что хочет прослушивать определенные события, обычно вы регистрируете слушателя, например

manager.registerListener(myListenerImpl);

Если managerваш слушатель хранит с WeakReference, это означает, что вам не нужно удалять регистр, например с, manager.removeListener(myListenerImpl)потому что он будет автоматически удален, как только ваш слушатель или ваш компонент, удерживающий слушателя, станет недоступным.

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

Откуда берется WeakHashMapкартина?

Реестр слушателей, который хочет хранить зарегистрированных слушателей как WeakReferences, нуждается в коллекции для хранения этих ссылок. В WeakHashSetстандартной библиотеке Java нет реализации, WeakHashMapно мы можем легко использовать последнюю для «реализации» функциональности первой:

Set<ListenerType> listenerSet =
    Collections.newSetFromMap(new WeakHashMap<ListenerType, Boolean>());

При этом listenerSetдля регистрации нового прослушивателя вам просто нужно добавить его в набор, и даже если он не будет удален явно, если на прослушиватель больше не ссылаются, он будет автоматически удален JVM.

Эта запись блога демонстрирует использование обоих классов: Java: синхронизация по идентификатору . Использование идет примерно так:

private static IdMutexProvider MUTEX_PROVIDER = new IdMutexProvider();

public void performTask(String resourceId) {
    IdMutexProvider.Mutex mutext = MUTEX_PROVIDER.getMutex(resourceId);
    synchronized (mutext) {
        // look up the resource and do something with it
    }
}

IdMutextProvider предоставляет объекты на основе идентификатора для синхронизации. Требования следующие:

• должен возвращать ссылку на один и тот же объект для одновременного использования эквивалентных идентификаторов
• должен вернуть другой объект для разных идентификаторов
• нет механизма освобождения (объекты не возвращаются поставщику)
• не должно протекать (неиспользуемые объекты имеют право на сборку мусора)

Это достигается с помощью внутренней карты памяти типа:

WeakHashMap<Mutex, WeakReference<Mutex>>

Объект является как ключом, так и значением. Когда ничто внешнее к карте не имеет жесткой ссылки на объект, это может быть сбор мусора. Значения на карте хранятся с жесткими ссылками, поэтому значение должно быть заключено в WeakReference, чтобы предотвратить утечку памяти. Этот последний момент рассматривается в Javadoc .

Если вы, например, хотите отслеживать все объекты, созданные определенного класса. Чтобы по-прежнему разрешать сборку этих объектов, вы храните список / карту слабых ссылок на объекты вместо самих объектов.

Теперь, если бы кто-то мог объяснить мне фантомные ссылки, я был бы счастлив ...

Как указано выше, слабая ссылка сохраняется до тех пор, пока существует сильная ссылка.

Примером использования может быть использование WeakReference внутри слушателей, чтобы слушатели перестали быть активными после того, как основная ссылка на их целевой объект исчезла. Обратите внимание, что это не означает, что WeakReference удален из списка слушателей, очистка все еще требуется, но может быть выполнена, например, в запланированное время. Это также препятствует тому, чтобы прослушиваемый объект удерживал сильные ссылки и в конечном итоге становился источником раздувания памяти. Пример: компоненты Swing GUI, ссылающиеся на модель с более длинным жизненным циклом, чем у окна.

Играя со слушателями, как описано выше, мы быстро поняли, что объекты собираются «немедленно» с точки зрения пользователя.

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

Я сделал поиск кода Google для "нового WeakHashMap ()".

Я получил кучу совпадений из проекта GNU classpath и

1. Проект Apache xbean: WeakHashMapEditor.java
2. Проект Apache Lucene: CachingWrapperFilter.java

вы можете использовать weakhashmap для реализации бескресурного кэширования для создания обширного объекта.

но обратите внимание, что нежелательно иметь изменяемые объекты. я использовал его для кеширования результатов запроса (выполнение которых занимает около 400 мс) в механизм текстового поиска, который редко обновляется.