企业官网建设流程全解析

1. 为什么“堆存对象、栈存变量”这种说法一说就错？

刚入行那会儿，我也是这么记的——面试官问“堆和栈分别存什么”，我脱口而出：“堆存对象，栈存基本类型和引用！”结果对方微微一笑：“那String str = new String("hello")；这行代码里，'hello'这个字面量存在哪儿？str这个引用本身存在哪儿？new出来的String对象又在哪儿？三个东西，三个位置，你再捋一遍。”

我当时就卡住了。不是记不住，是根本没真正理解JVM内存区域的职责边界和数据生命周期。后来带新人时发现，90%的人对“堆、栈、方法区”的认知都停留在教科书式的标签化记忆上：堆=对象仓库，栈=方法调用记录，方法区=类模板存放地。但真实世界里，一个Java程序跑起来，内存里流动的数据远比这三块区域的静态划分要复杂得多。

比如，你写List<String> list = new ArrayList<>(10);，ArrayList实例在堆上，没错；list这个局部变量名在栈帧里，也没错；但那个容量为10的内部数组（Object[] elementData），它是在堆上分配的，还是在栈上“跟着”ArrayList一起存？再比如，Lambda表达式编译后生成的类信息存在方法区，可它捕获的外部变量值，是复制进去了，还是通过某种间接引用机制访问？还有，G1 GC里提到的“Remembered Set”，它本身的数据结构存在哪儿？这些都不是“堆/栈/方法区”三个词能直接回答的。

真正决定某块数据落哪儿的，从来不是“它是什么类型”，而是它的作用域、生命周期、共享范围和访问方式。堆之所以存对象，是因为对象需要跨方法、跨线程长期存在，且可能被多个栈帧同时引用；栈之所以存局部变量，是因为方法调用有明确的进入退出顺序，变量随方法调用而生、随方法返回而灭；方法区之所以存类元数据，是因为类定义是全局唯一的、只加载一次、供所有线程共享的“蓝图”。

所以，这篇文章不打算再重复一遍“堆是线程共享的运行时数据区，用于存放对象实例……”这种百科式定义。我们要做的是：把每一行Java代码，像拆解电路板一样，一层层剥开，看它在JVM内存里到底触发了哪些区域的写入、读取、关联与释放。你会看到，一个看似简单的int a = 5;背后，栈帧里不仅有a的值，还有它的操作数栈快照、局部变量表索引、甚至可能触发常量池的符号解析；而一个new Object()，除了在堆上分配空间，还会在方法区里检查类是否已加载，在栈上记录构造器调用链，在本地方法栈里处理可能的JNI调用。

这才是JVM内存模型的真相——它不是一张静态分区图，而是一套动态协作的内存协议。接下来，我们就从最基础、也最容易被误解的“栈”开始，亲手画出它的内部结构。

2. 栈：不只是“存变量”，它是方法执行的实时快照

很多人以为栈就是个“变量盒子”，方法一进来，变量往里一塞；方法一出去，盒子清空。这种理解漏掉了栈最核心的价值：它是一份精确到字节码指令级别的、方法执行过程的完整状态快照。栈帧（Stack Frame）不是容器，而是“现场”。

2.1 栈帧的四大构件：局部变量表、操作数栈、动态链接、方法出口

当你调用一个方法，JVM就在当前线程的Java虚拟机栈中压入一个新栈帧。这个栈帧绝非空壳，它由四个关键部分构成，每个部分都承担着不可替代的职责：

• 局部变量表（Local Variable Table）：这是大家最熟悉的“存变量”的地方。但它存的远不止是int a = 5;里的a。它按槽（Slot）编号，每个槽32位宽，能存一个int、float、reference（引用），或半个long/double（64位类型占两个连续槽）。重点来了：this引用永远占据第0号槽。哪怕你写的是静态方法，编译器也会在局部变量表里预留这个位置（只是不使用）。另外，方法参数从第1号槽开始依次排列。所以，public void test(String s, int i)这个方法，s在槽1，i在槽2（假设i是int）。而s.length()调用时，length()方法的栈帧里，this指向的就是s所引用的那个String对象——这个引用关系，正是通过局部变量表的槽位传递的。

• 操作数栈（Operand Stack）：这是JVM执行引擎的“计算器”。字节码指令如iload_1（把局部变量表第1槽的int值压入操作数栈）、iadd（弹出栈顶两个int相加，结果再压入）都是在操作数栈上完成的。它不像局部变量表有固定槽位，而是个动态伸缩的栈。你可以把它想象成Excel里一个临时的、只保留当前计算中间结果的单元格。比如int c = a + b;，编译后大概是：iload_1（a入栈）→iload_2（b入栈）→iadd（弹出a、b，算和，c入栈）→istore_3（c出栈，存入局部变量表第3槽）。整个加法运算，全程在操作数栈上发生，局部变量表只负责“进出库”。

• 动态链接（Dynamic Linking）：这是实现多态和反射的关键。每个栈帧都包含一个指向运行时常量池中该方法的引用。当执行invokespecial（调用父类方法）、invokestatic（调用静态方法）时，JVM直接根据这个引用找到目标方法；而执行invokevirtual（调用虚方法）时，JVM会先查这个引用指向的类的方法表（vtable），再根据实际对象类型决定调用哪个具体实现。没有这个动态链接，Animal a = new Dog(); a.speak();就无法在运行时正确调用Dog的speak方法。

• 方法出口（Method Exit）：记录方法正常返回（return）或异常退出（throw）后，应该跳转回哪里继续执行。它保存着调用者的下一条字节码指令地址。这也是为什么你能用IDE的“Drop Frame”功能，把当前方法栈帧“弹掉”，让程序回到上一层方法继续执行——JVM就是靠这个出口地址精准定位的。

提示：栈帧的大小在类加载的解析阶段就完全确定了（由Code属性中的max_stack和max_locals决定），不会在运行时改变。这也是为什么递归过深会直接抛StackOverflowError——不是栈“满了”，而是新压入的栈帧所需空间超出了JVM为该线程预设的栈大小（-Xss参数）。

2.2 一个真实案例：String s = "abc";在栈上发生了什么？

我们来逐行拆解这行看似简单的代码：

public class StackDemo { public static void main(String[] args) { String s = "abc"; System.out.println(s); } }

编译后，main方法的字节码如下（简化版）：

0: ldc #2 // 加载常量池#2（即"abc"字符串） 2: astore_1 // 将栈顶的引用存入局部变量表第1槽（s） 3: getstatic #3 // 获取System.out 6: aload_1 // 将局部变量表第1槽的引用（s）压入操作数栈 7: invokevirtual #4 // 调用println方法 10: return

执行过程：

• 指令0ldc #2：JVM去运行时常量池查找#2，发现是CONSTANT_String_info，它指向另一个CONSTANT_Utf8_info（"abc"）。如果这是第一次使用，JVM会检查字符串常量池（StringTable，位于堆中，但逻辑上属于方法区管理范畴），若无则创建并放入；若有，则直接返回其引用。这个引用被压入当前栈帧的操作数栈。
• 指令2astore_1：将操作数栈顶的引用（"abc"的地址）弹出，存入当前栈帧的局部变量表第1槽。此时，s这个“变量名”才正式有了归属。
• 指令6aload_1：又把局部变量表第1槽的引用重新压入操作数栈，为后续println调用做准备。

看到了吗？同一个字符串引用，在短短几条指令间，就在操作数栈和局部变量表之间来回搬运了两次。而“abc”这个字符串对象本身，存在于堆上的字符串常量池（JDK 7+之后），它的类元数据（String.class）则在方法区。一个简单的赋值，横跨了三个内存区域。

2.3 实操验证：用jclasslib和jstack亲眼看看栈帧

光说不练假把式。你可以用两个工具亲手验证上面的结论：

1. jclasslib Bytecode Viewer：打开编译好的.class文件，切换到Code属性页，就能看到上面那段字节码，以及max_stack=2, max_locals=2（args在槽0，s在槽1）。这印证了栈帧大小的静态性。

2. jstack：写一个无限递归的方法，如public static void loop() { loop(); }，然后用jstack <pid>抓取线程快照。你会看到类似这样的输出：

   "main" #1 prio=5 os_prio=0 tid=0x00007f8b8c00a000 nid=0x2a0e waiting for monitor entry [0x00007f8b902f9000] java.lang.Thread.State: RUNNABLE at StackDemo.loop(StackDemo.java:5) at StackDemo.loop(StackDemo.java:5) at StackDemo.loop(StackDemo.java:5) ...

   这里[0x00007f8b902f9000]就是当前线程栈的起始地址，后面一长串loop就是层层叠叠的栈帧。每个at代表一个栈帧的入口点。你可以清晰地看到，栈帧是按调用顺序从下往上（地址从高到低）压入的。

注意：-Xss参数设置的是每个线程栈的总大小，不是单个栈帧的大小。一个栈帧可能只占几百字节，但几千个栈帧叠在一起，就轻松耗尽-Xss设定的1MB或2MB空间。这也是为什么-Xss不能设得过大——线程一多，内存就爆了。

3. 堆：对象的“户籍所在地”，但户口本在方法区

如果说栈是方法执行的“快照”，那么堆就是所有对象的“户籍所在地”。但这里有个巨大的认知陷阱：堆只管对象实例的“身体”，不管它的“身份”。一个对象是谁、能干什么、有哪些字段和方法，这些“身份信息”，全在方法区里。

3.1 对象在堆中的完整生命旅程：从分配到消亡

一个对象的诞生，远比new SomeClass()这一行代码复杂。它要经历五个严格有序的阶段：

1. 类加载检查（Loading Check）：JVM遇到new指令，首先去方法区的常量池中检查是否有SomeClass的符号引用。如果没有，说明类还没加载，触发类加载过程（加载、验证、准备、解析、初始化）。

2. 内存分配（Memory Allocation）：类已加载，JVM在堆上为对象分配内存。分配方式有两种：

   • 指针碰撞（Bump the Pointer）：适用于内存规整的场景（如Serial、ParNew收集器）。堆内存被分为“已使用”和“未使用”两块，用一个指针作为分界点。分配内存就是把指针向“未使用”方向挪动一段距离。快如闪电。
   • 空闲列表（Free List）：适用于内存不规整的场景（如CMS收集器）。JVM维护一个列表，记录堆中哪些内存块是可用的。分配时，从列表中找到一块足够大的空间，更新列表。稍慢，但更灵活。

   关键细节：分配内存不是原子操作！多线程下，两个线程可能同时修改指针或列表。JVM的解决方案是：CAS（Compare and Swap）+ 失败重试，或者给每个线程在Eden区划出一块独立的“本地线程分配缓冲区（TLAB）”。绝大多数对象都在TLAB里分配，几乎不涉及同步。

3. 初始化零值（Zero Initialization）：内存分配完，JVM会将分配到的内存空间（除对象头外）都初始化为零值（0、0L、null、false等）。这保证了Java对象的字段即使不显式赋值，也能得到一个安全的默认值。注意，这一步不执行任何Java代码，int a;此时就是0，不是你代码里写的int a = 5;。

4. 设置对象头（Setting Object Header）：JVM为对象设置对象头（Object Header），它包含两部分：

   • Mark Word：存储哈希码、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等。这部分内容会随着对象状态变化而动态变化。
   • Klass Pointer：这是一个指向方法区中该对象所属类元数据的指针。这才是连接堆和方法区的关键纽带！没有它，JVM就不知道这个堆上的对象到底是个String还是个ArrayList。

5. 执行<init>方法（Executing<init>Method）：最后，JVM才会调用你写的构造函数（即<init>方法），执行你代码里写的int a = 5;、this.name = name;等逻辑。这才是真正的“初始化”。

提示：new指令只完成了前四步。第五步<init>是invokespecial指令触发的。所以，如果你在构造器里启动了一个新线程，并把this传给它，那个新线程看到的，是一个已经分配好内存、对象头已设置、但构造器代码尚未执行完毕的对象！这就是著名的“构造器逃逸”问题，可能导致其他线程看到未初始化完成的对象状态。

3.2 堆的内部结构：新生代、老年代、永久代/元空间

现代JVM（HotSpot）的堆，绝非一块大平板，而是被精细地划分为几个子区域，每个区域服务于不同的GC策略：

这里必须澄清一个高频误区：“永久代（PermGen）”在JDK 8中已被彻底移除，由“元空间（Metaspace）”取代。永久代是堆的一部分，受-XX:MaxPermSize限制；而元空间使用的是本地内存（Native Memory），默认情况下只受物理内存限制（可通过-XX:MaxMetaspaceSize手动限制）。这意味着，以前常见的java.lang.OutOfMemoryError: PermGen space错误，在JDK 8+中变成了java.lang.OutOfMemoryError: Metaspace。

为什么这样改？因为永久代的大小很难预估。Web应用（如Tomcat）热部署时，每次部署都会加载大量新类，旧类又未必能及时卸载，导致永久代迅速撑爆。元空间用本地内存，理论上可以无限扩展（直到物理内存耗尽），大大降低了这类OOM的风险。

3.3 一个深度案例：String.intern()如何在堆与方法区间“腾挪”

String.intern()是检验你是否真懂堆与方法区关系的试金石。我们来看JDK 7+的行为（JDK 6及以前行为不同，此处不讨论）：

public class InternDemo { public static void main(String[] args) { String s1 = new String("hello"); // 在堆上创建新对象 String s2 = "hello"; // 字符串字面量，在字符串常量池（堆中）创建 String s3 = s1.intern(); // 将s1的值"hello"加入字符串常量池，并返回池中对象的引用 System.out.println(s1 == s2); // false (堆对象 vs 常量池对象) System.out.println(s2 == s3); // true (都是常量池中同一个对象) System.out.println(s1 == s3); // false (同上) } }

关键点解析：

• new String("hello")：在堆上创建了一个全新的String对象。它的value字段（char[]）也指向堆上的一块新内存。
• "hello"：编译期确定的字面量，JVM在类加载时就将其放入字符串常量池。JDK 7+后，这个池被移到了堆中（准确说是堆的某个特定区域，由JVM管理），不再是方法区的一部分。
• s1.intern()：JVM检查字符串常量池中是否已有值为"hello"的String对象。有，则直接返回池中对象的引用；没有，则将s1的value（char[]）复制一份，创建一个新的String对象放入池中，再返回其引用。

注意：intern()操作本身并不改变s1的指向，它只是返回一个新引用。所以s1 == s3是false。而s2和s3都指向常量池中同一个对象，所以s2 == s3是true。

这个例子完美展示了堆的“双重身份”：它既是普通对象的家，也是字符串常量池的家。而方法区（元空间）里，只存着String.class这个类的元数据，以及它所有静态方法（如intern()）的字节码。intern()方法的执行逻辑，是由JVM用C++实现的本地方法，它负责协调堆（常量池）和方法区（类定义）之间的数据流转。

4. 方法区：类的“中央档案馆”，但档案管理员在本地方法栈

方法区（Method Area）是JVM规范中定义的概念，在HotSpot虚拟机中，它的具体实现就是元空间（Metaspace）。如果说堆是对象的“户籍所在地”，那么方法区就是所有类的“中央档案馆”。它存储着每一个被JVM加载的类的全部元数据。

4.1 方法区里到底存了什么？一份完整的“类档案”清单

一个类被加载进方法区，其档案内容远比你想象的丰富。它主要包括以下几大类信息：

• 类的全限定名（Fully Qualified Name）：如java/lang/String。这是类在JVM内的唯一身份标识。
• 直接超类的全限定名：如String的超类是Object，记录为java/lang/Object。
• 该类是类还是接口的标志：一个布尔值。
• 该类的访问修饰符（public, final, abstract等）：以位掩码形式存储。
• 常量池（Constant Pool）：这是方法区里最庞大、也最核心的部分。它不是一个简单的字符串列表，而是一个符号表（Symbol Table），里面存储着：
  • 字面量（Literal）：如字符串"hello"、整数123、浮点数3.14。
  • 符号引用（Symbolic Reference）：如类名java/lang/Object、字段名value、方法名toString及其描述符()Ljava/lang/String;。这些引用在类加载的“解析”阶段，才会被替换成直接引用（Direct Reference，即内存地址）。
• 字段信息（Fields）：包括字段名、字段描述符（如I表示int，Ljava/lang/String;表示String引用）、字段的访问标志（public, static, final等）。
• 方法信息（Methods）：包括方法名、方法描述符（参数和返回值类型）、方法的访问标志（public, static, final, synchronized等）、方法的字节码（Code属性）、异常表（Exceptions属性）、行号表（LineNumberTable属性，用于调试）、局部变量表（LocalVariableTable属性，用于调试）。
• 类变量（Static Variables）：即static字段。它们的值被存储在方法区中，而不是堆上。例如，public static int COUNT = 0;，这个COUNT变量本身（不是它的值0）就存于方法区。
• 指向类加载器（ClassLoader）和指向Class类的引用：这是实现类隔离和反射的基础。每个类都有一个java.lang.Class对象，它本身也是一个Java对象，存于堆上，但它内部有一个指向方法区中自己元数据的指针。

提示：Class对象是JVM在类加载过程中自动创建的，它就像一个“活的类档案索引”。你通过String.class或obj.getClass()拿到的，就是这个堆上的Class对象。它之所以能“反射”出类的所有信息，正是因为它的内部指针，牢牢地锚定在方法区的那份原始档案上。

4.2 本地方法栈：方法区的“后勤保障部”

方法区里存的是“档案”，但谁来“查阅”和“使用”这些档案？答案是：本地方法栈（Native Method Stack）。

本地方法栈与Java虚拟机栈的作用非常相似，区别在于：Java虚拟机栈为JVM执行Java方法（字节码）服务，而本地方法栈则为JVM调用的本地方法（Native Method）服务。这里的“本地方法”，通常指用C/C++等语言编写、通过JNI（Java Native Interface）注册到JVM中的方法。

为什么需要它？因为方法区里的类元数据（如字节码、常量池）是JVM内部格式，Java代码无法直接操作。当你要做些底层操作，比如：

• Object.clone()：需要直接复制内存块，这必须由本地方法实现。
• System.currentTimeMillis()：需要调用操作系统的gettimeofday()系统调用。
• String.getBytes()：需要调用C库的字符编码转换函数。

这些操作，JVM都封装成了本地方法。当Java代码调用clone()时，JVM会：

1. 在本地方法栈中为clone()方法创建一个新的栈帧。
2. 执行该栈帧中的本地代码（C函数）。
3. 这个C函数会去方法区里查询Object类的元数据，确认clone()方法的签名和权限。
4. 然后，它会直接操作堆上的对象内存，进行位拷贝。

所以，本地方法栈，就是连接Java世界（方法区、堆、Java栈）与本地世界（操作系统、C库）的桥梁。它不存储业务数据，但它决定了方法区里的“档案”能否被高效、安全地利用。

4.3 实战排错：java.lang.OutOfMemoryError: Metaspace的根因分析

这是JDK 8+最常见的OOM之一。很多同学一看到就慌了，赶紧加-XX:MaxMetaspaceSize=512m。但治标不治本。我们必须追根溯源。

典型场景与排查链路：

1. 场景：Spring Boot应用反复热部署（如DevTools）

   • 现象：每次修改代码，IDE自动重启应用，运行几次后，应用启动失败，报Metaspace OOM。
   • 根因：每次重启，Spring Boot会创建一个新的ClassLoader来加载所有类。旧的ClassLoader及其加载的所有类元数据（在Metaspace中）本应被GC回收。但如果某些静态集合（如static Map<ClassLoader, Object> cache）持有了对旧ClassLoader的强引用，就会导致这些类元数据无法被卸载，Metaspace持续增长。
   • 验证：用jstat -gc <pid>观察MU（Metaspace Usage）指标，会发现它只增不减。用jmap -clstats <pid>查看类加载器统计，会发现alive数量越来越多。

2. 场景：使用CGLIB或Javassist动态生成大量代理类

   • 现象：RPC框架（如Dubbo）或AOP框架（如Spring AOP）在运行时，为每个被代理的类生成一个xxx$$EnhancerByCGLIB子类。如果代理的类非常多，或代理逻辑有bug导致重复生成，Metaspace就会被撑爆。
   • 根因：动态生成的类，其字节码被JVM当作普通类加载，元数据同样进入Metaspace。而这些类通常没有对应的ClassLoader可以被轻易卸载。
   • 验证：用jmap -histo:live <pid> | head -20，会看到大量com.sun.proxy.$Proxy或net.sf.cglib.proxy.$EnhancerByCGLIB开头的类。

3. 场景：自定义类加载器泄漏

   • 现象：应用中实现了复杂的插件系统，每个插件有自己的ClassLoader。插件卸载后，其ClassLoader对象仍被持有。
   • 根因：ClassLoader是类元数据的“主人”。只要ClassLoader对象还活着，它加载的所有类的元数据就无法被Metaspace GC清理。
   • 验证：用jmap -dump:format=b,file=heap.hprof <pid>导出堆转储，用Eclipse MAT分析，按ClassLoader分组，看哪些ClassLoader实例数量异常多，且其loadedClasses字段不为空。

解决方案从来不是盲目加大-XX:MaxMetaspaceSize。正确的做法是：

1. 用jstat -gc <pid>监控Metaspace使用趋势；
2. 用jmap -clstats <pid>确认类加载器数量是否失控；
3. 用jmap -histo或MAT分析，定位是哪些类在疯狂增长；
4. 最终，修复代码中的类加载器泄漏或动态类生成逻辑。

5. 四大区域的协同作战：一个HTTP请求的完整内存足迹

理论讲得再多，不如看一个真实世界的完整案例。我们以一个典型的Spring MVC Web应用处理一个HTTP GET请求为例，追踪整个请求生命周期中，JVM四大内存区域（堆、栈、方法区、本地方法栈）是如何协同工作的。

5.1 请求入口：Tomcat线程池与Java栈的初次交锋

当一个HTTP请求到达Tomcat，它会被分配给线程池中的一个工作线程（如http-nio-8080-exec-5）。这个线程早已在JVM启动时就创建好了，它拥有自己独立的Java虚拟机栈。

• Tomcat的AbstractEndpoint$Worker线程开始执行，其栈帧里包含了run()方法的局部变量（如SocketWrapperBase）。
• 接着调用Http11Processor.process()，新的栈帧被压入，局部变量表里存着SocketWrapper、InputBuffer、OutputBuffer等引用。
• 再调用Adapter.service()，栈帧再次压入，此时request和response对象被创建并存入局部变量表。

注意：request和response对象本身是普通的Java对象，它们被分配在堆上。但它们的“身份”——即它们是org.apache.catalina.connector.Request和org.apache.catalina.connector.Response类的实例——这个信息，就存储在方法区的Request.class和Response.class元数据中。

5.2 Spring MVC调度：方法区的“指挥中心”与堆的“执行部队”

Tomcat将request和response交给Spring的DispatcherServlet。此时，真正的MVC调度开始了：

• DispatcherServlet.doDispatch()被调用，新的栈帧压入。它从HandlerMapping中查找能处理该URL的HandlerExecutionChain。
• HandlerExecutionChain是一个对象，存于堆上。但它内部的handler字段，是一个HandlerMethod对象，而HandlerMethod里又包含一个Method对象（反射API）。
• Method对象本身在堆上，但它所代表的“这个方法到底长什么样”，其全部信息（方法名、参数类型、注解@RequestMapping的值）都来自方法区中对应Controller类的元数据。

当DispatcherServlet最终调用handlerMethod.invoke()时，奇迹发生了：

• JVM去方法区中查找该Method对象所指向的字节码。
• 创建一个新的栈帧，压入当前线程的Java虚拟机栈。
• 在这个新栈帧的操作数栈上，执行iload_0（加载this）、aload_1（加载request）等指令。
• this引用指向堆上的Controller实例，request引用指向堆上的Request实例。

整个过程，方法区提供“剧本”（元数据），Java栈提供“舞台”（执行上下文），堆提供“演员”（对象实例）。

5.3 数据库交互：本地方法栈的“临门一脚”

Controller方法里，通常会有userRepository.findById(id)这样的调用。这背后是JDBC驱动在工作：

• DriverManager.getConnection()最终会调用MySQLConnection的本地方法nativeConnect()。
• JVM为此在本地方法栈中创建栈帧。
• 该本地方法会调用操作系统的socket()、connect()等系统调用，建立TCP连接。
• 连接建立后，JDBC驱动会将SQL语句（如SELECT * FROM user WHERE id = ?）序列化为MySQL协议的二进制包，通过socket发送。
• MySQL服务器返回结果集后，JDBC驱动的本地方法再将二进制数据解析为ResultSet对象，这个对象被创建在堆上。

这里，本地方法栈是整个IO链条的“最后一公里”。它不存储业务数据，但它让JVM能够突破Java语言的边界，与操作系统和网络设备直接对话。

5.4 响应返回：四大区域的“谢幕”与“清场”

请求处理完毕，DispatcherServlet将ModelAndView对象交给ViewResolver，最终渲染HTML，写入response.getOutputStream()。

• 渲染过程会产生大量临时字符串、StringBuilder对象，它们在堆上分配、使用、然后被GC回收。
• response.getOutputStream()返回的ServletOutputStream对象，其内部可能调用了FileDescriptor的本地方法，这又会用到本地方法栈。
• 当整个请求处理结束，http-nio-8080-exec-5线程的Java虚拟机栈上，所有为本次请求压入的栈帧，会按照后进先出（LIFO）的顺序，逐个弹出、销毁。局部变量表、操作数栈占用的内存被立即释放。
• 堆上为本次请求创建的User、Order、StringBuilder等对象，如果不再被任何栈帧或静态变量引用，就会在下一次GC时被回收。
• 方法区和本地方法栈，由于它们存储的是全局、长期的元数据和本地代码，基本不受单次请求影响，保持稳定。

这就是一个HTTP请求在JVM内存世界里的完整“一生”。它不是孤立地待在某一个区域，而是像一支训练有素的军队，在堆（兵员）、栈（指挥链）、方法区（作战地图）、本地方法栈（特种装备）四大区域的精密协同下，完成了一次完美的任务。

6. 面试高频题深度拆解：为什么String str = new String("abc")创建了几个对象？

这个问题几乎是JVM内存区域考察的“必答题”。但绝大多数面试者只能答出“2个”，却说不清“为什么是2个”、“第2个在哪”、“常量池在哪”。我们来一次彻底的、带证据的拆解。

6.1 JDK 7+的权威答案：最多2个对象，但“2”的含义完全不同

结论先行：在JDK 7及以后，String str = new String("abc");这行代码，最多创建2个对象。但这2个对象，一个在堆上，一个在字符串常量池（也在堆上），不存在“方法区里有一个”的情况。

让我们用javap -v反编译来验证：

public class StringTest { public static void main(String[] args) { String str = new String("abc"); } }

编译后，main方法的字节码和常量池如下（关键部分）：

Constant pool: #2 = String #18 // "abc" #18 = Utf8 "abc" Code: 0: new #2 // class java/lang/String 3: dup 4: ldc #2 // String "abc" 6: invokespecial #3 // Method java/lang/String."<init>":(Ljava/lang/String;)V 9: astore_1

执行步骤详解：

• 指令0new #2：JVM去常量池#2查找，发现它是一个String类型的符号引用