Миф: мне НЕ нужно заниматься управлением памятью в Java, потому что GC все делает за меня
Garbage Collector (GC) действительно очищает неиспользуемые объекты, на которые больше нет активных ссылок. Благодаря этому в Java не нужно вручную освобождать память, как в C++.
Несколько предпосылок, из которых обычно рождается этот тезис:
- В языках с ручным управлением памятью (C, C++) утечки очевидны: если забыл вызвать
free(), память потеряна навсегда.- В Java GC работает автоматически, поэтому кажется, что он сам решает все проблемы.
- «Ну раз есть GC, значит о памяти можно больше не думать» - типичная ошибка.
GC удаляет только те объекты, на которые больше нет активных ссылок. Если объект остается доступным, но фактически уже не используется, он будет занимать память до завершения приложения.
* Несколько случаев утечек памяти
[1] Статические коллекции (заполняем, но не очищаем)
Если создать
static List и постоянно добавлять в него объекты, GC их никогда не освободит, потому что статические поля живут в течение всего времени работы приложения.public class MemoryLeak {
private static final List<byte[]> cache = new ArrayList<>();
public static void main(String[] args) {
while (true) {
cache.add(new byte[10 * 1024 * 1024]);
System.out.println("Added 10MB to the cache. Used memory: " +
(Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()) / (1024 * 1024) + "MB");
}
}
}Через пару минут -
OutOfMemoryError.[2] Переменные потока (
ThreadLocal)Объекты, сохраненные в
ThreadLocal, привязаны к потоку, а в пуле потоков могут жить дольше, чем нужно.public class ThreadLocalLeak {
private static final ThreadLocal<byte[]> threadLocalData = new ThreadLocal<>();
public static void main(String[] args) {
ExecutorService executor = Executors.newFixedThreadPool(5);
for (int i = 0; i < 10; i++) {
executor.execute(() -> {
threadLocalData.set(new byte[10 * 1024 * 1024]); // 10MB per thread
System.out.println("Memory occupied by the thread!");
});
}
executor.shutdown();
}
}Поток завершится, но память останется занятой, потому что
ThreadLocal не очищается автоматически.[3] Внутренние классы и «утекшие» ссылки
Если анонимный класс или lambda-ссылка захватывает внешний объект, это может мешать GC освободить его.
public class InnerClassLeak {
private String data = "Very important data";
public void createAnonymousClass() {
Runnable task = new Runnable() {
@Override
public void run() {
System.out.println("Using: " + data);
}
};
new Thread(task).start();
}
}task держит ссылку на data, и даже если InnerClassLeak больше не используется, GC не сможет очистить объект.Миф развенчан. GC не всесилен, и даже с ним придется учиться правильно работать с памятью в Java.
👉 Java Portal