Кэш LRU переменного размера

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

Как правило, более эффективно использовать некоторый подход, основанный на времени, с регулярными сильными ссылками, которые намного дешевле для виртуальной машины, чем подклассы ссылок (быстрее в обработке для программы и GC и не используют дополнительную память для самой ссылки.). т.е. освободить все объекты, которые не использовались в течение определенного времени. Вы можете проверить это с помощью периодического TimerTask, который вам в любом случае понадобится для работы с эталонной очередью. Идея состоит в том, что если для создания объекта требуется, например, 10 мс, и вы сохраняете его не более 1 с после его последнего использования, вы в среднем будете работать только на 1% медленнее, чем если бы вы сохраняли все объекты навсегда. Но поскольку он, скорее всего, будет использовать меньше памяти, на самом деле он будет быстрее.

Изменить. Один из способов реализовать это — использовать 3 корзины внутри. Объекты, помещенные в кеш, всегда вставляются в корзину 0. Когда объект запрашивается, кеш ищет его во всех 3 корзинах по порядку и помещает в корзину 0, если его там еще нет. TimerTask вызывается через фиксированные промежутки времени и просто удаляет корзину 2 и помещает новую пустую корзину в начало списка корзин, так что новая корзина 0 будет пустой, а предыдущая корзина 0 станет 1, а прежняя корзина 1 теперь станет корзиной. 2. Это гарантирует, что бездействующие объекты переживут как минимум один и не более двух интервалов таймера, а объекты, доступ к которым осуществляется более одного раза за интервал, будут очень быстро извлекаться. Общие накладные расходы на обслуживание такой структуры данных будут значительно меньше, чем все, что основано на ссылочных объектах и ​​ссылочных очередях.

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

Приготовьтесь к горячим дискуссиям с вашими системными администраторами, так как они будут жаловаться на то, что в вашем приложении есть утечка памяти и «вылетит в любой момент!» вздыхает

Другой вариант — использовать проверенную библиотеку кеша, такую ​​как EHCache, поскольку она уже знает все, что нужно знать о кеше, и они потратил годы на то, чтобы сделать их правильными - в буквальном смысле. Если вы не хотите тратить годы на отладку своего кода, чтобы заставить его работать с каждым краеугольным камнем модели памяти Java, я предлагаю вам на этот раз не изобретать велосипед.

Я бы использовал LinkedHashMap, поскольку он поддерживает порядок доступа и используется в качестве карты LRU. Он может иметь переменный максимальный размер.

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

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