Короткий ревью причины утечки
- Проблемный код: `class Cache { private static List data = new ArrayList(); void add(Object o){data.add(o);} }`
- Почему утечка: поле `static` — корень GC, `data` живёт пока класс загружен; список растёт без ограничений, объекты в нём никогда не удаляются => не может быть собрано сборщиком мусора.
Что исправить (конкретные предложения)
1) Убрать глобальную `static`‑переменную или ограничить жизненный цикл кеша:
- Сделать кеш экземпляром, а не статической переменной, и управлять его временем жизни через DI или явную инициализацию/закрытие.
2) Ограничить размер и/или время жизни элементов:
- Использовать LRU (ограничение по размеру) или TTL (время жизни) — чтобы коллекция не растала бесконечно.
3) Использовать надежную реализацию кеша вместо самодельных коллекций:
- Библиотеки: Caffeine, Guava Cache — имеют политики eviction, таймауты и потокобезопасность.
4) Для слабых ссылок (если объекты должны удаляться при отсутствии сильных ссылок):
- Использовать `WeakReference`/`WeakHashMap` (освобождает по ключам) или `WeakReference`/`SoftReference` для значений + `ReferenceQueue` для детектирования удаления. Осторожно: `SoftReference` непредсказуем в современных JVM.
Примеры изменений
1) Ограниченный LRU‑кеш на LinkedHashMap (без статического поля):
```java
public class Cache {
private final int maxSize;
private final Map data;
public Cache(int maxSize) {
this.maxSize = maxSize;
this.data = Collections.synchronizedMap(new LinkedHashMap(/*default*/) {
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
return size() > Cache.this.maxSize;
}
});
}
public void put(K key, V value) { data.put(key, value); }
public V get(K key) { return data.get(key); }
public void clear() { data.clear(); }
}
```
В конфигурации задайте `maxSize` (например, `$1000$`) в зависимости от доступной памяти.
2) Использование Guava/Caffeine (рекомендуется для боевых систем):
```java
// пример с Guava
Cache cache = CacheBuilder.newBuilder()
.maximumSize(MAX_SIZE) // MAX_SIZE ≈ $1000$ .expireAfterAccess(MAX_TTL, TimeUnit.MINUTES)
.build();
```
Caffeine аналогично, но быстрее и современнее.
3) Если нужно, чтобы значения не удерживали объекты в памяти:
```java
Map<Key, WeakReference> map = new ConcurrentHashMap();
// при доступе надо разворачивать WeakReference и обрабатывать null
```
Но учтите: объекты могут исчезать неожиданно, это влияет на логику.
Паттерны и практики для избегания подобных проблем
- Не хранить большие объекты в статических коллекциях без явной политики очистки.
- Использовать bounded cache (размер/время), LRU или политики eviction.
- Применять проверенные библиотеки (Caffeine/Guava) вместо ручных реализаций.
- Документировать владелец/жизненный цикл кеша; предоставлять метод `close()`/`clear()` для очистки при завершении.
- Писать тесты на утечки (нагружать добавлением и проверять рост heap'а).
- Мониторить приложение: GC‑метрики, heap dumps (jmap / jcmd / VisualVM / MAT), профилирование, alert при росте памяти.
- Для многопоточных приложений — использовать потокобезопасные коллекции и проверенные реализации кешей.
Краткое резюме
- Причина: статический, неограниченный список — GC root + без эвикции => утечка.
- Быстрая починка: убрать `static` или ввести ограничение (LRU/TTL) либо заменить на Guava/Caffeine с `maximumSize`/`expireAfter*`.
- Для критичных систем — добавить мониторинг и тесты на рост памяти.