Weakhashmap java что это

Руководство по WeakHashMap на Java

Объяснение карты weakhash-как она работает, когда ее использовать, и небольшой пример.

1. Обзор

Чтобы понять структуру данных, мы будем использовать ее здесь для развертывания простой реализации кэша. Однако имейте в виду, что это предназначено для понимания того, как работает карта, и создание собственной реализации кэша почти всегда является плохой идеей.

2. Сильные, мягкие и Слабые ссылки

2.1. Сильные Ссылки

Переменная prime имеет сильную ссылку на Целое число объект со значением 1. Любой объект, на который есть сильная ссылка, указывающая на него, не подходит для GC.

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

Давайте посмотрим, как мы можем создать SoftReference в Java:

Объект prime имеет сильную ссылку, указывающую на него.

2.3. Слабые ссылки

Объекты, на которые ссылаются только слабые ссылки, охотно собирают мусор; в этом случае GC не будет ждать, пока ему понадобится память.

Мы можем создать Слабую ссылку в Java следующим образом:

3. WeakHashMap как эффективный кэш памяти

Допустим, мы хотим создать кэш, в котором большие объекты изображений будут храниться в качестве значений, а имена изображений-в качестве ключей. Мы хотим выбрать правильную реализацию карты для решения этой проблемы.

Использование простого HashMap не будет хорошим выбором, потому что объекты значений могут занимать много памяти. Более того, они никогда не будут извлечены из кэша процессом GC, даже если они больше не используются в нашем приложении.

К счастью, WeakHashMap обладает именно этими характеристиками. Давайте протестируем нашу WeakHashMap и посмотрим, как она себя ведет:

4. Заключение

В этой статье мы рассмотрели типы ссылок в Java, чтобы полностью понять, как java.util. WeakHashMap работает. Мы создали простой кэш, который использует поведение WeakHashMap и проверяем, работает ли он так, как мы ожидали.

Источник

weakReference

— И снова здравствуйте!

Сейчас я расскажу тебе еще про одну замечательную штуку — WeakReference – слабые ссылки.

Выглядит она почти так же, как и SoftReference:

У слабой ссылки есть другая особенность.

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

— А можно еще раз, в чем отличия между этими ссылками?

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

Объект, который удерживает от смерти только WeakReference не переживает ближайшей сборки мусора. Но пока она не произошла, его можно получить, вызвав метод get() у WeakReference и вызвать его методы или сделать что-нибудь еще.

— А если на объект ссылаются и SoftReference и WeakReference?

— Тут все просто. Если на объект есть хотя бы одна обычная ссылка – он считается живым. Такие ссылки, кстати, называются StrongReference.

Если на объект нет обычных ссылок, но есть SoftReference, то он – SoftReference.

Если на объект нет обычных ссылок и SoftReference, но есть WeakReference, то он – WeakReference.

Подумай сам, SoftReference защищает объект от удаления и гарантирует, что объект будет удален только при нехватке памяти. WeakReference удерживает объект до ближайшей сборки мусора. SoftReference удерживает от удаления сильнее.

— Отлично, тогда расскажу тебе про еще одну занимательную штуку с использованием WeakReference – это WeakHashMap.

— А то! WeakHashMap – это HashMap, у которого ключи – это слабые ссылки – WeakReference.

Т.е. ты добавляешь в такой HashMap объекты и работаешь с ними. Все как обычно.

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

Но, представь, что во всем приложении больше не осталось ссылок на эти объекты. Все что удерживает их от смерти – это несколько WeakReference внутри WeakHashMap. Тогда после ближайшей очистки мусора такие объекты исчезнут из WeakHashMap. Сами. Как будто их там и не было.

— Не уверен, что понял.

— Ты хранишь в WeakHashMap пары объектов – ключ и значение. Но WeakHashMap ссылается на ключи не прямо, а через WeakReference. Поэтому, когда объекты, используемые в качестве ключей, станут слабодостижимыми, они уничтожатся при ближайшей сборке мусора. А значит, из WeakHashMap автоматически удалятся и их значения.

В WeakHashMap очень удобно хранить дополнительную информацию к каким-то объектам.

Во-первых, ее очень легко получить, если использовать сам объект в качестве ключа.

Во-вторых, если объект будет уничтожен, из HashMap исчезнет и он, и все привязанные к нему данные.

— Выглядит как мощный инструмент. А где можно его использовать?

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

— Звучит интересно. Сразу чувствуется, ну не писал я еще серьезных программ на Java, чтобы задействовать такие мощные механизмы. Но я буду расти в эту сторону, спасибо большое, Элли, за такой интересный урок.

Источник

30.17. Java – Класс WeakHashMap

Класс WeakHashMap – это реализация интерфейса Map, в котором хранятся только слабые ссылки на его ключи. Хранение только слабых ссылок позволяет собрать пару с ключом-значением, когда его ключ больше не ссылается за пределы WeakHashMap.

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

Функции WeakHashMap в Java идентичны HashMap с одним очень важным исключением: если диспетчер памяти Java больше не имеет сильной ссылки на объект, указанный в качестве ключа, то запись на Map будет удалена.

Слабая ссылка. Если единственными ссылками на объект являются слабые ссылки, сборщик мусора может вернуть память объекта в любое время. Ему не нужно ждать, пока система исчерпает память. Обычно он будет освобожден при следующем запуске сборщика мусора.

Содержание

Конструкторы

Ниже приведен список конструкторов, поддерживаемых классом WeakHashMap.

Методы

Помимо методов, унаследованных от его родительских классов, TreeMap определяет следующие методы:

Пример

Следующая программа демонстрирует работу нескольких методов, поддерживаемых WeakHashMap в Java:

Источник

Weakhashmap java что это

Both null values and the null key are supported. This class has performance characteristics similar to those of the HashMap class, and has the same efficiency parameters of initial capacity and load factor.

Like most collection classes, this class is not synchronized. A synchronized WeakHashMap may be constructed using the Collections.synchronizedMap method.

This class is intended primarily for use with key objects whose equals methods test for object identity using the == operator. Once such a key is discarded it can never be recreated, so it is impossible to do a lookup of that key in a WeakHashMap at some later time and be surprised that its entry has been removed. This class will work perfectly well with key objects whose equals methods are not based upon object identity, such as String instances. With such recreatable key objects, however, the automatic removal of WeakHashMap entries whose keys have been discarded may prove to be confusing.

The behavior of the WeakHashMap class depends in part upon the actions of the garbage collector, so several familiar (though not required) Map invariants do not hold for this class. Because the garbage collector may discard keys at any time, a WeakHashMap may behave as though an unknown thread is silently removing entries. In particular, even if you synchronize on a WeakHashMap instance and invoke none of its mutator methods, it is possible for the size method to return smaller values over time, for the isEmpty method to return false and then true, for the containsKey method to return true and later false for a given key, for the get method to return a value for a given key but later return null, for the put method to return null and the remove method to return false for a key that previously appeared to be in the map, and for successive examinations of the key set, the value collection, and the entry set to yield successively smaller numbers of elements.

Each key object in a WeakHashMap is stored indirectly as the referent of a weak reference. Therefore a key will automatically be removed only after the weak references to it, both inside and outside of the map, have been cleared by the garbage collector.

Implementation note: The value objects in a WeakHashMap are held by ordinary strong references. Thus care should be taken to ensure that value objects do not strongly refer to their own keys, either directly or indirectly, since that will prevent the keys from being discarded. Note that a value object may refer indirectly to its key via the WeakHashMap itself; that is, a value object may strongly refer to some other key object whose associated value object, in turn, strongly refers to the key of the first value object. If the values in the map do not rely on the map holding strong references to them, one way to deal with this is to wrap values themselves within WeakReferences before inserting, as in: m.put(key, new WeakReference(value)), and then unwrapping upon each get.

Note that the fail-fast behavior of an iterator cannot be guaranteed as it is, generally speaking, impossible to make any hard guarantees in the presence of unsynchronized concurrent modification. Fail-fast iterators throw ConcurrentModificationException on a best-effort basis. Therefore, it would be wrong to write a program that depended on this exception for its correctness: the fail-fast behavior of iterators should be used only to detect bugs.

This class is a member of the Java Collections Framework.

Источник

Руководство по WeakHashMap в Java

Руководство по WeakHashMap в Java

1. обзор

В этой статье мы рассмотримWeakHashMap из пакетаjava.util.

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

Запись вWeakHashMap будет автоматически удалена, когда ее ключ больше не используется в обычном режиме, а это означает, что нет ни одногоReference, указывающего на этот ключ. Когда процесс сборки мусора (GC) отбрасывает ключ, его запись эффективно удаляется с карты, поэтому этот класс ведет себя несколько иначе, чем другие реализацииMap.

2. Сильные, мягкие и слабые ссылки

2.1. Сильные Ссылки

Переменнаяprime имеетstrong reference для объектаInteger со значением 1. Любой объект, на который есть сильная ссылка, не имеет права на сборщик мусора.

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

Проще говоря, объект, на который указываетSoftReference, не будет обрабатываться сборщиком мусора, пока JVM полностью не понадобится память.

Давайте посмотрим, как мы можем создатьSoftReference в Java:

Объектprime имеет сильную ссылку, указывающую на него.

Затем мы превращаем сильную ссылкуprime в мягкую. После создания этой сильной ссылкиnull объектprime имеет право на сборщик мусора, но будет собран только тогда, когда JVM абсолютно потребуется память.

2.3. Слабые ссылки

Объекты, на которые ссылаются только слабые ссылки, быстро собираются мусором; В этом случае сборщик мусора не будет ждать, пока ему понадобится память.

Мы можем создатьWeakReference в Java следующим образом:

Когда мы создали ссылкуprimenull, объектprime будет удален сборщиком мусора в следующем цикле сборки мусора, поскольку на него нет другой сильной ссылки.

Ссылки типаWeakReference используются как ключи вWeakHashMap.

3. WeakHashMap как эффективный кэш памяти

Использование простогоHashMap не будет хорошим выбором, поскольку объекты значений могут занимать много памяти. Более того, они никогда не будут извлечены из кеша процессом сборки мусора, даже если они больше не используются в нашем приложении.

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

К счастью,WeakHashMap обладает именно этими характеристиками. Давайте протестируем нашWeakHashMap и посмотрим, как он себя ведет:

Мы создаем экземплярWeakHashMap, в котором будут храниться наши объектыBigImage. Мы помещаем объектBigImage в качестве значения и ссылку на объектimageName в качестве ключа. imageName будет сохранен на карте как типWeakReference.

Мы вызываемSystem.gc(), чтобы заставить JVM запустить процесс сборки мусора. После цикла GC нашWeakHashMap будет пустым:

4. Заключение

В этой статье мы рассмотрели типы ссылок в Java, чтобы полностью понять, как работаетjava.util.WeakHashMap. Мы создали простой кеш, который использует поведениеWeakHashMap и проверяет, работает ли он так, как мы ожидали.

Реализацию всех этих примеров и фрагментов кода можно найти вGitHub project, который является проектом Maven, поэтому его должно быть легко импортировать и запускать как есть.

Источник