Большинство разработчиков, говоря о памяти JVM, представляют всего две области:

• Heap — где хранятся объекты;
• Stack — где находятся локальные переменные и вызовы методов.
Для начала этого достаточно. Но в реальных проектах такая модель слишком упрощена.
На самом деле память процесса JVM состоит из нескольких областей, каждая из которых выполняет свою задачу.
- Heap — хранит объекты Java. Именно здесь работает Garbage Collector.
- Thread Stack — у каждого потока свой стек. В нём находятся локальные переменные, параметры методов и цепочка вызовов.
- Metaspace — хранит метаданные загруженных классов: информацию о полях, методах, аннотациях и другую служебную информацию, необходимую JVM.
- Code Cache — область, где JIT-компилятор сохраняет уже скомпилированный машинный код, чтобы приложение выполнялось быстрее.
- Native Memory — память вне Heap. В неё входят Direct Memory, стеки потоков, Code Cache, Metaspace, внутренние структуры JVM, память JNI-библиотек и другие служебные области.
Именно поэтому распространённое утверждение:

«OutOfMemoryError означает, что закончился Heap»

не всегда верно.

Например, приложение может завершиться с ошибкой из-за переполненного Metaspace, нехватки Direct Memory или даже большого количества потоков, хотя Heap при этом будет заполнен лишь частично.
Поэтому при анализе проблем с памятью опытный Java-разработчик смотрит не только на Heap, а на всю картину целиком.

В следующих публикациях думаю подробно разобрать каждую область памяти JVM: что в ней хранится, почему она может переполниться и как такие проблемы диагностируются в реальных проектах.