JVM内存结构

JVM 内存结构概述

在 Java 开发领域，Java 虚拟机（JVM）扮演着举足轻重的角色，它是 Java 程序得以运行的基础环境。而 JVM 内存结构，则是 JVM 的核心组成部分，深入理解这一结构，对每一位 Java 开发者而言都至关重要。

JVM 内存结构定义了 Java 程序在运行时，内存的申请、分配以及管理策略，其合理与否直接关乎 Java 程序的性能表现、稳定性和可扩展性。当程序运行过程中，对象的创建、方法的调用、数据的存储与读取等操作，都与 JVM 内存结构紧密相连。如果开发者对 JVM 内存结构缺乏足够的认识，在面对复杂的应用场景时，就可能遭遇内存泄漏、内存溢出等棘手问题，导致程序运行异常，甚至崩溃。比如，在高并发的电商系统中，如果不能合理设置堆内存大小，当大量用户同时访问，创建大量对象时，就可能引发内存溢出错误，使系统无法正常响应请求，严重影响用户体验。

接下来，我们将深入剖析 JVM 内存结构的各个组成部分，包括程序计数器、虚拟机栈、本地方法栈、堆和方法区（Java 8 及之后为元空间），详细阐述它们的作用、特点以及相互之间的协作关系，让大家对 JVM 内存结构有更为全面和深入的理解。

线程私有区域

程序计数器（Program Counter Register）

程序计数器是一块较小的内存空间，它可以看作是当前线程所执行的字节码的行号指示器。在 JVM 的多线程环境下，每个线程都有自己独立的程序计数器，这是因为在任意时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一个线程中的指令。当线程被切换回来继续执行时，JVM 需要知道该线程上次执行到的位置，程序计数器就起到了这个作用，它记录了当前线程正在执行的字节码指令的地址，如果线程执行的是本地方法（Native Method），那么程序计数器的值则为 undefined。

程序计数器是 JVM 内存区域中唯一不会发生内存溢出（OutOfMemoryError）的区域。这是由于它的设计目的单纯且明确，仅用于记录线程执行的指令位置，所需的内存空间相对固定且较小，所以在正常情况下，不会因为内存不足而出现问题。

例如，当一个线程执行一段 Java 代码时，程序计数器会随着指令的执行而不断更新，指示下一条要执行的指令。如果遇到方法调用，程序计数器会记录调用指令的位置，以便方法返回后能继续执行后续指令。在多线程环境中，当线程 A 被暂停，线程 B 开始执行时，线程 A 的程序计数器会保存其当前执行状态，当线程 A 重新获得执行权时，就可以依据程序计数器的值从上次暂停的位置继续执行。

虚拟机栈（Java Virtual Machine Stack）

虚拟机栈是线程私有的，它描述的是 Java 方法执行的内存模型。每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法返回地址等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

栈帧（Stack Frame）

栈帧是虚拟机栈的基本组成单位，它包含以下几个重要部分：

局部变量表：用于存储方法参数和方法内部定义的局部变量。局部变量表以变量槽（Slot）为最小单位，32 位的数据类型占用一个 Slot，64 位的数据类型（如 long 和 double）则占用两个连续的 Slot 。当方法被调用时，方法参数会按照顺序存储在局部变量表中，对于实例方法，第一个 Slot 存储的是指向当前对象的引用（即 this）。局部变量表所需的容量大小在编译期就已经确定，并保存在方法的 Code 属性的 max_locals 数据项中，在方法运行期间不会改变。例如，在一个方法中定义了几个 int 类型的局部变量和一个对象引用，这些变量就会存储在局部变量表的相应 Slot 中。
操作数栈：是一个后进先出（LIFO）的栈结构，用于在方法执行过程中存储操作数和中间结果。当方法执行字节码指令时，会根据指令的要求对操作数栈进行入栈和出栈操作。比如执行算术运算时，会将参与运算的操作数压入操作数栈，然后执行运算指令，运算结果再压回操作数栈。例如，对于 “int a = 1 + 2;” 这条语句，在执行时会先将 1 和 2 压入操作数栈，然后执行加法指令，将结果 3 压回操作数栈，最后将 3 存储到局部变量表中。
动态链接：每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用，这个引用用于支持方法调用过程中的动态链接。在 Java 源文件被编译成字节码文件时，所有的变量和方法引用都作为符号引用保存在 class 文件的常量池中。在方法调用时，需要将这些符号引用转换为直接引用，这个过程就是动态链接。例如，当一个类中的方法调用另一个类中的方法时，在编译期只知道被调用方法的符号引用，在运行时通过动态链接，将符号引用解析为实际方法的直接引用，从而实现方法的正确调用。
方法返回地址：当方法执行完成后，需要返回到调用它的方法继续执行，方法返回地址就是用于记录这个返回位置的。如果方法正常退出，调用者的程序计数器的值作为方法返回地址，即调用该方法的指令的下一条指令的地址；如果方法是异常退出，返回地址要通过异常表来确定。例如，方法 A 调用方法 B，方法 B 执行完毕后，根据方法返回地址，程序将返回到方法 A 中调用方法 B 的下一条指令处继续执行。

栈的异常情况

Java 虚拟机栈可能出现两种异常情况：

StackOverflowError：当线程请求的栈深度大于虚拟机所允许的最大深度时，会抛出 StackOverflowError 异常。这种情况通常发生在方法递归调用没有正确的终止条件时，例如一个递归方法中没有出口，不断地调用自身，导致栈帧不断入栈，最终栈深度超过了虚拟机栈的最大容量。比如以下代码：

public class StackOverflowExample {

   public static void recursiveMethod() {
       recursiveMethod();
   }

   public static void main(String[] args) {
       recursiveMethod();
   }
}

运行上述代码，很快就会抛出 StackOverflowError 异常，因为recursiveMethod方法无限递归，栈帧不断增加，最终超出了栈的最大深度。

OutOfMemoryError：如果虚拟机栈可以动态扩展（当前大部分虚拟机都不支持动态扩展），并且在尝试扩展的时候无法申请到足够的内存，或者在创建新的线程时没有足够的内存去创建对应的虚拟机栈，就会抛出 OutOfMemoryError 异常。在实际应用中，虽然虚拟机栈通常设置为固定大小，但在高并发场景下，如果创建过多线程，每个线程都需要分配一定大小的虚拟机栈空间，可能会导致系统内存不足，从而抛出 OutOfMemoryError 异常。例如，在一个系统中，不合理地创建了大量线程，每个线程的栈空间占用较大，而系统内存有限，就可能出现这种异常。

本地方法栈（Native Method Stack）

本地方法栈与虚拟机栈所发挥的作用非常相似，它们的区别在于虚拟机栈为虚拟机执行 Java 方法（也就是字节码）服务，而本地方法栈则是为虚拟机使用到的本地（Native）方法服务。本地方法是使用 Java 语言以外的其他语言（如 C、C++ 等）编写的方法，通过 Java 本地接口（JNI，Java Native Interface）来实现 Java 代码与本地代码的交互。

当一个 Java 线程调用本地方法时，JVM 会为该本地方法在本地方法栈中创建一个栈帧，用于存储该方法的局部变量、参数、返回值等信息。与虚拟机栈一样，本地方法栈也是线程私有的，每个线程都有自己独立的本地方法栈。

在 HotSpot 虚拟机中，本地方法栈和虚拟机栈是合二为一的，它们使用相同的栈空间。本地方法栈也会出现与虚拟机栈类似的异常情况，即 StackOverflowError 和 OutOfMemoryError 异常，产生的原因与虚拟机栈相同。例如，当本地方法递归调用过深或者本地方法栈空间不足时，就可能抛出相应的异常。

线程共享区域

堆（Java Heap）

堆的作用和地位

堆是 Java 虚拟机所管理的内存中最大的一块区域，它是 Java 对象实例和数组的唯一存储区域，是 JVM 内存结构中的核心部分。在 Java 程序运行时，通过new关键字创建的对象都会在堆中分配内存空间，堆的生命周期与 Java 应用程序的生命周期相同，从应用程序启动开始，到应用程序结束才被销毁。

堆也是垃圾回收器（Garbage Collector，GC）管理的主要区域，因此也被称为 “GC 堆” 。由于堆中对象的创建和销毁非常频繁，垃圾回收器需要不断地对堆内存进行管理，回收不再被引用的对象所占用的内存空间，以避免内存泄漏和提高内存利用率。在一个长时间运行的 Java Web 应用中，会不断地创建各种对象，如用户请求处理过程中创建的业务对象、数据库查询结果映射的实体对象等，这些对象在使用完毕后，如果没有被及时回收，就会占用堆内存，随着时间的推移，可能导致堆内存耗尽，引发内存溢出错误。而垃圾回收器会定期扫描堆内存，标记并回收那些不再被任何引用指向的对象，从而释放内存空间，保证应用程序的正常运行。

堆的结构划分

从内存回收的角度来看，堆在逻辑上被划分为新生代（Young Generation）和老年代（Old Generation），新生代又进一步细分为 Eden 区、From Survivor 区和 To Survivor 区，它们在内存分配和垃圾回收机制中扮演着不同的角色。

新生代（Young Generation）：主要用于存储新创建的对象，大多数对象在新生代中诞生，并且生命周期较短，很多对象在创建后很快就不再被使用，成为垃圾对象。新生代采用复制算法（Copying Algorithm）进行垃圾回收，这种算法将内存分为大小相等的两块，每次只使用其中一块，当这一块内存用完时，将存活的对象复制到另一块上，然后清空当前使用的这块内存。新生代中默认 Eden 区与 Survivor 区的大小比例为 8:1:1，即 Eden 区占新生代空间的 8/10，From Survivor 区和 To Survivor 区各占 1/10 。新创建的对象首先会分配到 Eden 区，当 Eden 区空间不足时，会触发一次 Minor GC，对新生代进行垃圾回收。在 Minor GC 过程中，Eden 区和 From Survivor 区中存活的对象会被复制到 To Survivor 区，然后清空 Eden 区和 From Survivor 区。如果 To Survivor 区空间不足，无法容纳所有存活对象，这些对象将直接晋升到老年代。经过一次 Minor GC 后，存活的对象年龄加 1，当对象的年龄达到一定阈值（默认是 15，通过-XX:MaxTenuringThreshold参数可以调整）时，也会晋升到老年代。
老年代（Old Generation）：用于存储经过多次新生代垃圾回收后仍然存活的对象，这些对象生命周期较长，存活概率较高。老年代采用标记 - 清除（Mark-Sweep）算法或标记 - 整理（Mark-Compact）算法进行垃圾回收。标记 - 清除算法首先标记出所有需要回收的对象，然后统一回收所有被标记的对象，这种算法会产生大量的内存碎片；标记 - 整理算法在标记出需要回收的对象后，将存活的对象向一端移动，然后直接清理掉端边界以外的内存，避免了内存碎片的产生。当老年代空间不足时，会触发 Major GC 或 Full GC，对老年代进行垃圾回收，同时也可能会对新生代进行垃圾回收。Full GC 的成本较高，因为它需要扫描整个堆内存，所以应尽量减少 Full GC 的发生频率。

堆的结构划分和垃圾回收机制是为了提高内存回收效率，减少内存碎片，从而提升 Java 程序的整体性能。在实际的 Java 应用开发中，了解堆的结构和垃圾回收机制，有助于合理优化内存使用，避免出现内存相关的性能问题。例如，在开发高并发的在线交易系统时，根据业务特点，合理调整新生代和老年代的大小比例，以及对象晋升到老年代的年龄阈值，可以有效减少垃圾回收的次数和时间，提高系统的响应速度和吞吐量。

方法区（Method Area）

方法区的作用

方法区是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。可以将方法区看作是一个 Java 类的元数据仓库，当 Java 虚拟机加载一个类时，会将该类的相关信息存储在方法区中，包括类的全限定名、父类名、实现的接口列表、字段信息、方法信息、常量池等。这些信息对于 Java 程序的运行至关重要，它们为方法的调用、对象的创建和初始化等操作提供了必要的支持。

在一个 Java Web 应用中，当启动服务器加载各种 Servlet 类时，这些 Servlet 类的类信息就会被存储在方法区中。方法区中的常量池存储了编译期生成的各种字面量和符号引用，例如字符串常量、被声明为final的常量值等字面量，以及类和接口的全限定名、字段的名称和描述符、方法的名称和描述符等符号引用。在运行期间，这些符号引用会被解析为直接引用，以便程序能够正确地访问和调用相关的类、字段和方法。

静态变量也存储在方法区中，它们属于类级别，而不是对象级别，在类加载时就会被分配内存空间并初始化，并且在整个应用程序的生命周期内都存在。例如，一个工具类中的静态常量，在类加载后就会存储在方法区中，所有对该工具类的调用都可以访问到这个静态常量。

去永久代过程（JDK 8 的变化）

在 JDK 8 之前，HotSpot 虚拟机将方法区实现为永久代（PermGen Space）。永久代是一块位于 Java 堆内存中的区域，它与 Java 堆一起被分配和管理。然而，使用永久代来实现方法区存在一些问题：

内存大小难以确定：类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出（java.lang.OutOfMemoryError: PermGen space），太大则会占用 Java 堆的内存空间，容易导致老年代溢出。在一些大型的 Java 应用中，由于加载的类数量较多，可能会导致永久代空间不足，抛出永久代溢出异常。
垃圾回收效率低：永久代会为垃圾回收带来不必要的复杂度，并且回收效率偏低。因为永久代中的数据类型复杂，垃圾回收时需要扫描和处理的信息较多，导致垃圾回收的时间和成本增加。

为了解决这些问题，从 JDK 8 开始，HotSpot 虚拟机移除了永久代，取而代之的是元空间（Metaspace）。元空间并不在虚拟机内存中，而是使用本地内存（Native Memory）。这意味着元空间的大小不再受到 Java 堆大小的限制，只受本地内存大小的限制。默认情况下，元空间的大小仅受本地内存限制，但可以通过-XX:MetaspaceSize（初始空间大小，达到该值就会触发垃圾收集进行类型卸载，同时 GC 会对该值进行调整）和-XX:MaxMetaspaceSize（最大空间，默认是没有限制的）等参数来指定元空间的大小。

元空间的使用带来了以下优势：

减少 OOM 风险：由于元空间使用本地内存，避免了与 Java 堆争夺内存空间，减少了因永久代大小设置不当而导致的内存溢出风险。在一些动态生成大量类的应用场景中，如使用 CGLIB 动态代理、OSGi 等技术时，元空间可以更好地适应类的动态加载和卸载，减少内存溢出的发生。
提高垃圾回收效率：元空间的垃圾回收主要针对不再使用的类和类加载器，回收逻辑相对简单，提高了垃圾回收的效率。当一个类加载器不再存活时，其对应的元空间会被回收，减少了垃圾回收的复杂度和时间成本。

运行时常量池（Runtime Constant Pool）

运行时常量池是方法区的一部分，它在类加载后，用于存放编译期生成的各种字面量和符号引用，同时也会在运行期间将解析后的直接引用存储其中。

在 Java 类的编译过程中，编译器会将代码中的各种字面量（如文本字符串、被声明为final的常量值等）和符号引用（如类和接口的全限定名、字段的名称和描述符、方法的名称和描述符等）收集起来，存储在 class 文件的常量池中。当 Java 虚拟机加载该类时，会将 class 文件中的常量池加载到方法区的运行时常量池中。

运行时常量池具备动态性，Java 语言并不要求常量一定只能在编译期产生，运行期间也可能将新的常量放入池中。这一特性在开发中被广泛利用，例如String类的intern()方法。当调用intern()方法时，如果常量池已经包含一个等于此String对象的字符串（用equals(object)方法确定），则返回池中的字符串；否则，将此String对象添加到常量池中，并返回这个String对象的引用。通过这种方式，可以实现字符串常量的共享，减少内存的占用。

String s1 = new String("hello");
String s2 = s1.intern();
String s3 = "hello";
System.out.println(s2 == s3); // 输出true，因为s2和s3指向常量池中的同一个字符串对象

在上述代码中，s1是通过new关键字创建的字符串对象，存储在堆中；s2通过intern()方法将"hello"字符串添加到常量池中，并返回常量池中的引用；s3直接使用字符串字面量创建，指向常量池中的字符串对象。因此，s2和s3是相等的，它们指向常量池中的同一个字符串对象。

由于运行时常量池是方法区的一部分，所以会受到方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError异常。在实际应用中，如果加载的类过多，常量池中的数据量过大，可能会导致运行时常量池内存不足，从而抛出该异常。

直接内存（Direct Memory）

直接内存并不属于 JVM 运行时数据区的一部分，也不是《Java 虚拟机规范》中定义的内存区域。但由于 Java NIO 库的使用，它被频繁涉及。直接内存是在 Java 堆外的、直接向系统申请的内存空间，来源于 NIO，通过存在堆中的DirectByteBuffer操作 native 内存。

在一些对性能要求极高、读写频繁的场合，直接内存具有明显的优势。例如在大文件处理、网络通信、数据库连接等高并发 I/O 操作中，直接内存可以显著减少数据传输延迟，提升整体吞吐量。其原理在于，通过 Java 的 NIO 库，直接内存允许数据在操作系统级别直接与文件或网络接口交互，绕过了 JVM 堆的层次，减少了传统 Java 堆内存到操作系统内存之间的数据复制操作。在网络通信中，使用直接内存可以避免数据在 Java 堆和操作系统内存之间的多次拷贝，从而提高数据传输的效率。

同时，直接内存的分配和释放不由 Java 的垃圾回收器管理，这意味着直接内存的使用不会直接影响到垃圾回收周期，从而避免了因堆内内存分配和回收导致的性能波动。对于需要持续高性能处理大量数据流的应用而言，减少 GC 活动可以有效避免因垃圾回收导致的暂停时间，维持应用的响应速度和稳定性。

此外，直接内存的分配独立于 JVM 堆大小的限制，理论上可以利用系统可用的所有物理内存和部分虚拟内存（包括 RAM 和交换分区），只要操作系统允许。这对于需要处理大量数据的应用特别有利，它们可以在不增加 JVM 堆大小的情况下，使用更多的内存资源。然而，尽管直接内存不受 JVM 堆大小的直接约束，系统总内存依然是有限的，因此在配置时仍需考虑系统资源的整体平衡。

直接内存也并非完美无缺，它的分配回收成本较高，并且不受 JVM 内存回收管理。如果在应用中频繁地分配和释放直接内存，可能会导致系统性能下降。由于直接内存在 Java 堆外，它的大小不会直接受限于-Xmx指定的最大堆大小，但是系统内存是有限的，Java 堆和直接内存的总和依然受限于操作系统能给出的最大内存。当系统中可用内存不足，而程序又不断申请直接内存时，就可能导致OutOfMemoryError异常。以下是一个简单的示例代码，用于测试直接内存的 OOM 情况：

import java.nio.ByteBuffer;
import java.util.ArrayList;

public class BufferTest {

   private static final int BUFFER = 1024 * 1024 * 20; // 20MB

   public static void main(String[] args) {

       ArrayList<ByteBuffer> list = new ArrayList<>();

       int count = 0;
       try {
           while (true) {
               ByteBuffer buffer = ByteBuffer.allocateDirect(BUFFER);
               list.add(buffer);
               count++;
           }

       } catch (Exception e) {
           e.printStackTrace();
       } finally {
           System.out.println(count);
       }
   }
}

在上述代码中，不断地申请 20MB 的直接内存，当系统内存不足时，就会抛出OutOfMemoryError: Direct buffer memory异常。直接内存大小可以通过MaxDirectMemorySize设置，如果不指定，默认与堆的最大值-Xmx参数值一致。在实际应用中，需要根据具体的业务场景和系统资源情况，合理地使用直接内存，避免因内存管理不当而导致的性能问题和内存溢出错误。

代码示例分析数据内存分配

为了更直观地理解 JVM 内存结构中各个区域的数据分配情况，我们通过一段具体的 Java 代码来进行详细分析。

public class MemoryAllocationExample {

   private static final int CONSTANT_VALUE = 10;
   private static int staticVariable = 20;
   private int instanceVariable;

   public MemoryAllocationExample() {
       instanceVariable = 30;
   }

   public void method() {
       int localVariable = 40;
       MemoryAllocationExample anotherObject = new MemoryAllocationExample();
       String literalString = "Hello, JVM";
       String internedString = new String("Interned").intern();
       int[] array = new int[5];
       // 操作数据
       localVariable++;
       anotherObject.instanceVariable++;
       array[0] = 1;
       System.out.println(literalString);
       System.out.println(internedString);
   }

   public static void main(String[] args) {
       MemoryAllocationExample object = new MemoryAllocationExample();
       object.method();
   }
}

类加载阶段

在类加载阶段，MemoryAllocationExample类的相关信息被加载到方法区中。包括类的全限定名、父类名（在本例中为java.lang.Object）、实现的接口列表（本例中未实现任何接口）、字段信息（如CONSTANT_VALUE、staticVariable、instanceVariable）、方法信息（method方法和main方法）以及常量池。

常量池中存储了编译期生成的各种字面量和符号引用。其中，"Hello, JVM"和"Interned"等字符串字面量作为字面量存储在常量池中；MemoryAllocationExample类的符号引用，以及方法调用、字段访问等操作的符号引用也存储在常量池中。

线程私有区域内存分配

程序计数器：当main方法开始执行时，每个线程都有自己独立的程序计数器。在main线程执行MemoryAllocationExample类的main方法和method方法时，程序计数器记录着当前正在执行的字节码指令的地址。例如，在执行object.method()时，程序计数器会记录调用method方法的指令位置，以便在method方法执行完毕后能正确返回继续执行后续指令。
虚拟机栈：在main方法执行时，会在虚拟机栈中创建main方法的栈帧。栈帧中包含局部变量表、操作数栈、动态链接和方法返回地址等信息。当执行MemoryAllocationExample object = new MemoryAllocationExample();时，object作为局部变量，其引用存储在main方法栈帧的局部变量表中。当调用object.method()时，会在虚拟机栈中创建method方法的栈帧。在method方法栈帧的局部变量表中，存储了localVariable、anotherObject等局部变量。localVariable是基本数据类型int，其值直接存储在局部变量表中；anotherObject是对象引用，存储的是指向堆中MemoryAllocationExample对象实例的引用。在方法执行过程中，操作数栈用于存储操作数和中间结果。例如，执行localVariable++;时，会将localVariable的值压入操作数栈，执行自增操作后，再将结果压回操作数栈，最后存储回局部变量表。动态链接则用于在方法调用时将符号引用转换为直接引用。例如，在method方法中调用System.out.println方法时，通过动态链接将System.out.println的符号引用解析为实际方法的直接引用。当method方法执行完毕后，其栈帧从虚拟机栈中出栈，返回地址用于指示返回到main方法中调用method方法的下一条指令处继续执行。
本地方法栈：在这段代码中没有调用本地方法，因此本地方法栈中没有相关栈帧。但如果代码中使用了本地方法（例如通过 JNI 调用 C 或 C++ 编写的本地代码），则会在本地方法栈中为本地方法创建栈帧，用于存储本地方法的局部变量、参数、返回值等信息。

线程共享区域内存分配

堆：通过new关键字创建的对象都在堆中分配内存空间。在main方法中，执行MemoryAllocationExample object = new MemoryAllocationExample();时，会在堆中创建一个MemoryAllocationExample对象实例。该对象实例包含instanceVariable实例变量，其初始值为 30 。在method方法中，执行MemoryAllocationExample anotherObject = new MemoryAllocationExample();时，又会在堆中创建一个新的MemoryAllocationExample对象实例。执行int[] array = new int[5];时，会在堆中分配一个包含 5 个元素的int类型数组对象。堆中的对象在不再被引用时，会被垃圾回收器回收。例如，当method方法执行完毕后，anotherObject引用不再被使用，如果没有其他引用指向堆中的MemoryAllocationExample对象实例，该对象实例就会被垃圾回收器标记并回收。
方法区：CONSTANT_VALUE作为final修饰的常量，其值 10 存储在方法区中。staticVariable作为静态变量，其值 20 也存储在方法区中。在 JDK 8 之前，类的元数据信息存储在永久代（属于方法区）中；在 JDK 8 及之后，类的元数据信息存储在元空间（使用本地内存，逻辑上仍属于方法区）。例如，MemoryAllocationExample类的类信息，包括类的结构、字段和方法的定义等，都存储在方法区（元空间）中。
运行时常量池："Hello, JVM"和"Interned"等字符串字面量在类加载后存储在运行时常量池中。当执行String internedString = new String("Interned").intern();时，如果运行时常量池中已经存在"Interned"字符串，则internedString指向运行时常量池中的该字符串；否则，将"Interned"字符串添加到运行时常量池中，并让internedString指向它。运行时常量池中的常量在整个应用程序的生命周期内通常不会被回收，除非对应的类被卸载。但在某些情况下，如果常量不再被任何地方引用，并且满足垃圾回收的条件，也可能会被回收。

通过对这段代码的分析，可以清晰地看到 JVM 内存结构中各个区域在程序运行过程中的数据分配和使用情况。这有助于我们在实际开发中更好地理解 Java 程序的内存管理机制，从而优化程序性能，避免内存相关的问题。

总结

通过以上全面且深入的阐述，我们对 JVM 内存结构有了透彻的理解。JVM 内存结构主要包含线程私有区域和线程共享区域，各区域各司其职，共同保障 Java 程序的稳定运行。

线程私有区域中，程序计数器用于记录线程执行的字节码指令地址，确保多线程环境下线程执行的连续性和正确性；虚拟机栈为 Java 方法执行提供内存模型，通过栈帧存储方法执行过程中的各种信息；本地方法栈则服务于虚拟机调用的本地方法，与虚拟机栈类似，但针对的是本地代码。

线程共享区域里，堆是 Java 对象和数组的存储地，也是垃圾回收的主要区域，其合理的结构划分（新生代和老年代）和高效的垃圾回收机制，对提升程序性能至关重要；方法区存储类信息、常量、静态变量等，在 JDK 8 之后，元空间的引入优化了方法区的内存管理；运行时常量池作为方法区的一部分，存放编译期生成的字面量和符号引用，并且支持运行时动态添加常量。

直接内存虽不属于 JVM 运行时数据区，但在 Java NIO 库的应用中发挥着重要作用，能显著提升特定场景下的 I/O 性能。