использование статического словаря в качестве кеша может привести к утечке?

Это не утечка, если вы удалили все ссылки на нее. Если вы полностью очищаете свою карту, то это не источник утечки. Вы должны учитывать тот факт, что JVM очень часто предпочитает не генерировать постоянную сборку мусора, как не относящийся к вам - важно только то, что у вас нет ссылки на нее, поэтому JVM может собрать ее, если оно хочет.

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

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

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

Как заметил Ромен, статическая карта вызывает подозрения. Если по какой-то причине вы не можете регулярно явно очищать его, вы можете рассмотреть возможность использования WeakHashMap, что

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

К сожалению, для Java6 в стандартной библиотеке отсутствует WeakHashSet, но в сети можно найти несколько реализаций.

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

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

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

Я предлагаю вам проверить содержимое кучи с помощью дампа кучи и анализатора кучи (например, JVisualVM). Это поможет вам найти подозреваемых в утечке. Тот факт, что старое поколение собирается реже, не означает, что утекает больше памяти; помните, что, хотя он может показаться заполненным, только часть его представляет собой живые объекты, а другая часть очищается следующей крупной сборкой мусора. Как уже говорили другие, проблема может быть из-за неполной очистки статических коллекций.

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