В Java существует ли SoftHashMap?

63
задан Mike B. 23 November 2018 в 14:52
поделиться

5 ответов

Редактирование (август 2012):

оказывается, что в настоящее время лучшим решением является, вероятно, Гуава 13.0's Cache классы, объясненные на Wiki Гуавы - это - то, что я собираюсь использовать. Это даже поддерживает создание SoftHashMap (см. CacheBuilder.newBuilder().softKeys()), но это, вероятно, не, что Вы хотите, как эксперт по Java Jeremy Manson объясняет (ниже, Вы найдете ссылку).

<час>

Не то, чтобы я знаю о (ноябрь 2008), но Вы добрая находка некоторая реализация SoftHashMap в сети.

Как этот: SoftHashMap или этот .

<час>

Редактирование (ноябрь 2009)
Как [1 111] упоминания Matthias в комментариях, Google Guava MapMaker действительно использует SoftReferences:

А ConcurrentMap разработчик, обеспечивая любую комбинацию этих функций:

  • мягкие или слабые ключи,
  • мягкие или слабые значения,
  • синхронизированное истечение, и
  • вычисление по запросу значений.

, Как упомянуто в [1 114] этот поток , другой кандидат JSR166y:

jsr166y. ConcurrentReferenceHashMap

, который Это предоставляет альтернативной параллельной ссылочной карте реализации Google (который полагается на фоновый поток для выселения записей)

<час>

Редактирование (август 2012)

реализация Google использует фоновый поток только, когда синхронизированное истечение записей требуют. В частности, это просто использует java.util.Timer, который не так навязчив как наличие отдельного фонового потока.

Jeremy Manson рекомендует, для любого кэша, используя эту функцию для предотвращения опасностей SoftReference: http://jeremymanson.blogspot.de/2009/07/how-hotspot-decides-to-clear_07.html

существует другая реализация от [1 117] Apache палата общин , а именно, org.apache.commons.collections.map. ReferenceMap; это не поддерживает синхронизированное удаление, но это действительно поддерживает выбор, должны ли ключи быть сравнены идентификационными данными или равенством. Кроме того, эта реализация не параллельна - это может быть сделано синхронизируемым, но это работает менее хорошо под доступами от нескольких потоков.

29
ответ дан 8 revs, 4 users 40% 24 November 2019 в 16:28
поделиться

Я знаком с двумя библиотеками, которые предлагают реализацию SoftHashMap:

  1. Apache палата общин : org.apache.commons.collections.map. Google Collections ReferenceMap

  2. : com.google.common.collect. ReferenceMap

20
ответ дан Gili 24 November 2019 в 16:28
поделиться

Существует реализация в качестве примера в 98 выпусков новостной рассылки

для специалистов по Java
4
ответ дан jb. 24 November 2019 в 16:28
поделиться

Если Вы хотите реализовать кэш softreferences, определенно лучшая идея, чем слабые ссылки, но это помещает Вашу всю политику удаления кэша в руки сборщика "мусора". который является, вероятно, не, что Вы хотите.

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

Runtime.getRuntime().getFreeMemory();

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

вот кэш LRU , я разработал с O (1) вставка, удаление и время поиска, которое имеет настраиваемое макс. число элементов. Если Вы хотите кэш, это будет лучшим решением, по моему скромному мнению, чем SoftHashMap.

softreferences являются отличным способом создать growable кэш. Таким образом, идеальное решение должно было бы использовать SoftHashMap наряду с регулярным кэшем фиксированного размера. имейте всех, вставляет в кэш, входят и в фиксированный кэш и в мягкую карту хеша затем для ссылки на что-то, просто видят, если в мягком hashmap (и обновляют ссылочное время в кэше). этим путем все Ваши самые важные объекты (согласно Вашей выбранной политике LRU, MFU...) никогда не будут удаляться, потому что на них трудно ссылаются в кэше, но Вы будете также держаться за большее количество вещей (без управления политикой) как долго, поскольку существует достаточная память.

1
ответ дан Community 24 November 2019 в 16:28
поделиться

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

2
ответ дан 24 November 2019 в 16:28
поделиться
Другие вопросы по тегам:

Похожие вопросы: