Может ли Java-приложение занимать больше оперативной памяти, чем размер Heap?

Может ли Java-приложение занимать больше памяти, чем размер Heap?

Да, абсолютно может! Это один из самых частых источников проблем в production. Heap - это только часть памяти, потребляемой JVM. Давайте разберёмся.

Структура памяти Java приложения

Освоенная память процессом
├── Heap (управляется GC)
│   ├── Young Generation
│   ├── Old Generation  
│   └── Permanent/Metaspace
├── Stack (потоки)
├── Code Cache (JIT компиляция)
├── Symbols (интернирование строк)
├── Native Memory
│   ├── DirectByteBuffer
│   ├── Библиотеки
│   └── Внешние зависимости
└── Прочее

Компоненты памяти вне Heap

1. Stack (Стек потоков)

// Каждый поток имеет свой stack
public void createThreads() {
    for (int i = 0; i < 1000; i++) {
        new Thread(() -> {
            // Каждый поток занимает ~1-2 MB на stack
            byte[] buffer = new byte[1024 * 1024]; // 1 MB
            try { Thread.sleep(Long.MAX_VALUE); } catch (Exception e) {}
        }).start();
    }
    // 1000 потоков x 1 MB на stack = 1 GB вне Heap!
}

Каждый поток имеет:

• Stack size (по умолчанию 1 MB)
• Локальные переменные
• Данные вызывающего стека (call stack)

2. Code Cache (JIT Compilation)

// Компилированный код хранится в Code Cache
public class HotCode {
    public long calculateSum(long[] numbers) {
        long sum = 0;
        for (long n : numbers) {
            sum += n; // Эта операция будет JIT скомпилирована
        }
        return sum;
    }
}

// При запуске с профилированием:
// java -XX:+UnlockDiagnosticVMOptions \
//      -XX:+PrintCodeCache \
//      -XX:ReservedCodeCacheSize=256M MyApp

Code Cache может занимать от 50MB до 1GB+ в зависимости от работы JIT компилятора.

3. DirectByteBuffer (Off-heap память)

// Самая частая причина утечек вне Heap!
import java.nio.ByteBuffer;

public class DirectMemoryLeak {
    public void allocateDirectMemory() {
        // Выделяем 1 GB off-heap памяти
        ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024 * 1024);
        
        // Эта память НЕ в Heap!
        // Если забыть освободить - утечка!
        // Даже если Heap свободен, приложение съест всю RAM
    }
    
    // Правильно:
    public void allocateDirectMemoryCorrectly() throws Exception {
        ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024 * 1024);
        try {
            // Используем буфер
        } finally {
            // Нужно явно освободить через Cleaner
            if (buffer instanceof sun.nio.ch.DirectBuffer) {
                ((sun.nio.ch.DirectBuffer) buffer).cleaner().clean();
            }
        }
    }
}

4. Metaspace (Metadata для классов)

// Метаинформация о классах хранится вне Heap
public class MetaspaceGrowth {
    // Динамическое создание классов может привести к утечке Metaspace
    public void createClassesDynamically() {
        // Инструментирование (Spring, Hibernate) создаёт прокси-классы
        // Аннотации генерируют синтетические классы
        // Если классов слишком много - переполнение Metaspace
    }
}

// Проверяем Metaspace
// jstat -gcmetacapacity -h10 <pid> 1000

5. String Pool и Interned Strings

public class StringPoolMemory {
    public void intern_strings() {
        // Интернированные строки хранятся в пуле
        // который в Java 7+ находится в Heap, но может причинять проблемы
        for (int i = 0; i < 1_000_000; i++) {
            String s = ("string-" + i).intern();
            // Если много интернированных строк - съедят много памяти
        }
    }
}

6. Внешние библиотеки и JNI

// Например, OpenCV или другие native библиотеки
public class NativeMemory {
    // Некоторые библиотеки выделяют память на уровне C/C++
    // Это не контролируется GC Java
    public native void processImage(byte[] imageData);
    
    // Утечки в native коде = утечки в памяти приложения
}

Практический пример проблемы

public class MemoryLeakExample {
    public static void main(String[] args) throws Exception {
        // Запуск: java -Xmx512M MemoryLeakExample
        
        System.out.println("Starting...");
        
        // 1. Создаём потоки (вне Heap)
        for (int i = 0; i < 500; i++) {
            new Thread(() -> {
                try { Thread.sleep(Long.MAX_VALUE); } catch (Exception e) {}
            }).start();
        }
        // 500 потоков x 1 MB = 500 MB вне Heap
        
        // 2. Allocate DirectByteBuffer (вне Heap)
        ByteBuffer buffer = ByteBuffer.allocateDirect(100 * 1024 * 1024);
        // 100 MB вне Heap
        
        // 3. Создаём объекты в Heap (в оставшихся 412 MB)
        List<byte[]> heapObjects = new ArrayList<>();
        for (int i = 0; i < 100; i++) {
            heapObjects.add(new byte[1024 * 1024]);
            // 100 MB в Heap
        }
        
        // Итого: 500 MB (stack) + 100 MB (direct) + 100 MB (heap) = 700 MB
        // При Xmx512M приложение сожрёт ~700 MB RAM!
        
        Thread.sleep(Long.MAX_VALUE);
    }
}

Как отследить утечки вне Heap

1. Native Memory Tracking

# Запуск с отслеживанием памяти
java -XX:NativeMemoryTracking=detail \
     -XX:+UnlockDiagnosticVMOptions \
     -XX:+PrintNMTStatistics \
     MyApp

# Во время работы:
jcmd <pid> VM.native_memory scale=MB summary
jcmd <pid> VM.native_memory scale=MB detail

2. Mmap и Page Cache (Linux)

# Посмотреть что занимает память процесса
pmap -x <pid>

# Подробнее
cat /proc/<pid>/maps
cat /proc/<pid>/status

3. JVM флаги для диагностики

java -XX:+PrintFlagsFinal \
     -XX:+UnlockDiagnosticVMOptions \
     -XX:+PrintNMTStatistics \
     -XX:ReservedCodeCacheSize=128M \
     -XX:MaxDirectMemorySize=256M \
     MyApp

Best Practices

// 1. Ограничивай DirectByteBuffer
// -XX:MaxDirectMemorySize=256M

// 2. Контролируй количество потоков
ExecutorService executor = Executors.newFixedThreadPool(20);

// 3. Мониторь Metaspace
// -XX:MetaspaceSize=128M -XX:MaxMetaspaceSize=256M

// 4. Очищай DirectByteBuffer
Field cleanerField = sun.nio.ch.DirectBuffer.class.getDeclaredField("cleaner");
cleanerField.setAccessible(true);
sun.misc.Cleaner cleaner = (sun.misc.Cleaner) cleanerField.get(buffer);
if (cleaner != null) cleaner.clean();

// 5. Проверяй утечки с помощью утилит
// - JProfiler
// - YourKit
// - Async Profiler
// - FlightRecorder (JDK 11+)

Итоговый ответ

Да, Java-приложение с Heap=512MB может занимать 1GB+ RAM благодаря:

• Стекам потоков (500 потоков x 1-2 MB)
• DirectByteBuffer (off-heap)
• Code Cache (JIT)
• Metaspace (метаинформация)
• Native memory

Это критично помнить при настройке контейнеров Docker и VM памяти!