Java SoftReference, паникование GC и поведение GC

Question

Я хочу написать кэш, используя SoftReference s, используя как можно больше памяти, если это не становится слишком неэффективным.

Попытка оценить используемый размер путем расчета размеров объекта или путемполучение некоторой аппроксимации используемой памяти JVM - тупики.

Javadoc даже заявляет, что SoftReference s хороши для кэшей с поддержкой памяти, но нет строгого правила относительно реализации JVMсправится SoftReference с.Я говорю только о реализации Oracle JVM (версии 6.22 и выше и версии 7).

Теперь мои вопросы (пожалуйста, не стесняйтесь отвечать частично, сгруппировано или любым другим способом):

1. Учитывает ли JVM последний доступ к объекту и удаляет только старые?Javadoc заявляет: Virtual machine implementations are, however, encouraged to bias against clearing recently-created or recently-used soft references.
2. Что происходит, когда память становится тесной?JVM паникует и просто съедает все объекты?
3. Есть ли параметр, указывающий JVM есть только столько, чтобы выжить (без OOME с) и жить здоровым (не имея только ЦП)запустить GC)

Answer 1

Я не думаю, что есть заказ. (Хотя я не уверен насчет порядка событий)

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

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

Answer 2

Что происходит, когда память становится тесной?JVM паникует и просто ест все объекты?

Я точно знаю, что с Oracle 1.6 JVM это не так.Мне известна ситуация, когда сервер, который обрабатывает параллельные запросы, использует ответ, содержащий фактические данные внутри мягкой ссылки.Я заметил, что, когда один поток сообщает о нехватке памяти, мягкие ссылки других потоков продолжают удерживать свое содержимое (ссылочные объекты).

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

Что достаточно, чтобы выжить?Вы имеете в виду, что если требуется объем памяти X, то только возвращать программные ссылки, пока X не станет доступным?Я не нашел ни одного такого параметра настройки, но, как я уже сказал, JVM, похоже, не восстанавливает все мягкие ссылки, когда требуется вернуть один.

Answer 3

Хотя SoftReferences - отличная функция, я лично не смею использовать их в больших проектах, где я не знаю требований к памяти для всех остальных компонентов.Повлияет ли кэш SoftReference, перегруженный памятью, на другие части, работающие плохо?

Я бы вместо использования SoftReferences рассмотрел бы использование EHCache .Это позволит вам ограничить размер отдельных кэшей с точки зрения количества записей или, что еще лучше, байтов, используемых в памяти (это новая функция в следующей версии 2.5).Разумеется, могут быть настроены разные стратегии выселения, такие как LRU.Есть много вещей, которые вы можете настроить с помощью EHCache.

Если вы используете Spring, то версия 3.1 также предоставит вам несколько хороших аннотаций на уровне методов @Cachable;EHCache можно использовать в качестве реализации кэширования.