Бывают ли в Java утечки памяти?


Сначала стоит сказать, что это такое. Утечка памяти (memory leak) в широком смысле – потеря доступа к некоторой сущности, которая при этом всё еще остается «живой» и расходует ресурсы компьютера.

Основное отличие Java от языков вроде C – автоматическое управление памятью. В общем случае вам не нужно думать об удалении объекта из памяти. Когда он перестал быть нужен, сборщик мусора сделает это за вас.

Но всё-таки бывают случаи, когда JVM не способна помочь, и прибираться за собой нужно вручную:

1. Объекты в статических полях. Обычно они живут пока живёт класслоадер, который обычно живет до конца работы приложения. В эту же группу риска попадают синглтоны, которые обычно базируются на статиках. Отдельного внимания заслуживает случай утечки ThreadLocal.

2. Взаимодействие с нативным кодом и ручное управление памятью. Когда вы решаетесь на ручное/внешнее управление, вся ответственность за сборку мусора переходит на вас. Это касается использования Unsafe и нативных библиотек. Сюда же попадают различные утечки внешних ресурсов: например соединений с базой через нативный драйвер.

3. Неправильное использование коллекций. Несогласованность методов equals-hashCode может позволить ключам теряться внутри HashMap/HashSet. Размер зарезервированной памяти часто не совпадает с размером содержимого: тот же HashMap, однажды раздувшись, не умеет уменьшаться.
4. Использование finalize. Вмешиваясь в нормальную работу GC, вы, естественно, можете её нарушить. Поток финализации имеет низкий приоритет – даже корректная реализация метода может не успеть выполниться и привести к OutOfMemoryError.

5. Утечка inner-класса. В отличие от nested, inner класс содержит неявную ссылку на своего хозяина. Так что экземпляр хозяина гарантированно будет жить пока живут экземпляры его inner-классов.

6. Интернированные строки. Вызовом String.intern() вы подписываетесь под тем, что осознаете что делаете. Ручное использование оптимизационных хитростей JVM не может не сопровождаться риском. Поведение этого метода зависит от версии Java и реализации JVM.

7. Паттерн Flyweight/object pool. И пул строк, и вся модель памяти реализуют его. Неправильная программная реализация паттерна также может привести к утечке объектов – зависанию их в пулле без реальных применений снаружи.

8. Всевозможные логические утечки. Нарушение консистентности модели бизнес-данных может приводить к забытым объектам. Технически это всё еще один из пунктов выше. Типичный пример такой утечки – утечка Activity в Android.

Так что ответ на вопрос – редко, но бывают.


👉@BookJava