Бывают ли в Java утечки памяти? (1/2)
Сначала стоит сказать, что это такое. Утечка памяти (memory leak) в широком смысле – потеря доступа к некоторой сущности, которая при этом всё еще остается «живой» и расходует ресурсы компьютера.
Основное отличие Java от языков вроде C – автоматическое управление памятью. В общем случае вам не нужно думать об удалении объекта из памяти. Когда он перестал быть нужен, сборщик мусора сделает это за вас.
Но всё-таки бывают случаи, когда JVM не способна помочь, и прибираться за собой нужно вручную:
1. Объекты в статических полях. Обычно они живут пока живёт класслоадер, который обычно живет до конца работы приложения. В эту же группу риска попадают синглтоны, которые обычно базируются на статиках. Отдельного внимания заслуживает случай утечки ThreadLocal.
2. Взаимодействие с нативным кодом и ручное управление памятью. Когда вы решаетесь на ручное/внешнее управление, вся ответственность за сборку мусора переходит на вас. Это касается использования Unsafe и нативных библиотек. Сюда же попадают различные утечки внешних ресурсов: например соединений с базой через нативный драйвер.
3. Неправильное использование коллекций. Несогласованность методов equals-hashCode может позволить ключам теряться внутри HashMap/HashSet. Размер зарезервированной памяти часто не совпадает с размером содержимого: тот же HashMap, однажды раздувшись, не умеет уменьшаться.
#JVM
@javatg
Сначала стоит сказать, что это такое. Утечка памяти (memory leak) в широком смысле – потеря доступа к некоторой сущности, которая при этом всё еще остается «живой» и расходует ресурсы компьютера.
Основное отличие Java от языков вроде C – автоматическое управление памятью. В общем случае вам не нужно думать об удалении объекта из памяти. Когда он перестал быть нужен, сборщик мусора сделает это за вас.
Но всё-таки бывают случаи, когда JVM не способна помочь, и прибираться за собой нужно вручную:
1. Объекты в статических полях. Обычно они живут пока живёт класслоадер, который обычно живет до конца работы приложения. В эту же группу риска попадают синглтоны, которые обычно базируются на статиках. Отдельного внимания заслуживает случай утечки ThreadLocal.
2. Взаимодействие с нативным кодом и ручное управление памятью. Когда вы решаетесь на ручное/внешнее управление, вся ответственность за сборку мусора переходит на вас. Это касается использования Unsafe и нативных библиотек. Сюда же попадают различные утечки внешних ресурсов: например соединений с базой через нативный драйвер.
3. Неправильное использование коллекций. Несогласованность методов equals-hashCode может позволить ключам теряться внутри HashMap/HashSet. Размер зарезервированной памяти часто не совпадает с размером содержимого: тот же HashMap, однажды раздувшись, не умеет уменьшаться.
#JVM
@javatg