企业官网建设流程全解析

1. 从一次线上事故说起：程序内存体系为什么值得你花半小时搞懂

先讲一个我真实经历过的故障。几年前接手过一个订单系统的优化任务，现象很典型：服务运行几天后接口响应越来越慢，最后整个节点直接卡死，连健康检查都过不去。当时团队里几个同事第一反应是“数据库慢查询”“锁竞争”，排查了半天没结果。最后我顺手打了一个线程堆栈，看到满屏都是java.lang.OutOfMemoryError: unable to create new native thread，再一看监控，堆内存明明还有几个G空闲，但操作系统层面的线程数已经逼近上限了。

这个故障的根子，不在堆内存，而在栈内存——准确说是线程栈。每个线程一创建就会从操作系统申请一块栈空间，线程数量涨上去之后，即便堆里还有空间，系统也扛不住。那一次事故让我彻底意识到，很多开发者的内存知识是“偏科”的：一说内存就只想到堆，栈要么只知道“局部变量放栈上”，要么干脆混为一谈。可实际上，堆内存与栈内存是整个程序内存体系的核心双支柱，两者的分配机制、生命周期、性能特征、故障表现完全不同，谁出了问题都能让线上服务翻车。

这篇文章我打算把这两根支柱彻底拆开讲清楚。不光是概念层面，还包括JVM、Linux进程内存布局、常见溢出场景的排查手段，以及我踩过的那些坑。无论你是刚入门的学生、写了两三年业务代码的工程师，还是开始接触性能调优的运维开发，这篇文章都值得耐心读完。读完你至少能回答三个问题：对象到底存在哪？为什么栈溢出往往比堆溢出更隐蔽？线上内存飙升时，怎样快速判断是该调堆还是该看栈？

2. 先建立整体认知：堆与栈在程序内存体系中是如何分工的

2.1 一次函数调用背后，内存都发生了什么

要理解堆和栈，最好的切入点是看一次普通函数调用。假设你写了这样一段伪代码：

public void processOrder() { Order order = new Order(); int total = calculateTotal(order); save(order, total); }

这段代码运行时，内存里发生的事情大概是这样的：

• 线程执行processOrder时，会创建一个栈帧（Stack Frame），里面存放局部变量order的引用、total的值、返回地址、操作数栈等信息。
• order这个变量本身只是一个引用（在64位系统上通常占8字节），它指向的对象new Order()实际分配在堆内存中。
• 调用calculateTotal时，再往栈上压入一个新的栈帧。这个栈帧里保存的是calculateTotal自己的局部变量和参数。
• 方法返回时，栈帧被弹出，total和order这两个变量的“生命周期”随之结束。但注意，order指向的Order对象并不会立刻被销毁——它还在堆上，要等垃圾回收器（GC）来处理。

这里就体现了堆和栈最本质的分工：栈负责管理方法的调用与执行上下文，堆负责管理对象的存储与共享生命周期。你可以把栈想象成一位服务员手里的一叠点菜单，每来一桌客人就添一张，客人走了就撕掉；堆则是后厨的食材仓库，食材不会因为某桌客人离开就立刻扔掉，要等过了保质期（不可达）才被统一清理。

2.2 为什么叫“堆”和“栈”：名字背后的设计逻辑

“栈”这个名字来源于后进先出（LIFO）的数据结构。函数调用天然就是嵌套的：外层方法还没结束，内层方法就开始执行；内层方法结束后，又回到外层继续执行。这种嵌套关系用栈来承载完全匹配。每个线程都拥有一个独立的栈，栈的大小在创建线程时基本固定（可用-Xss调整），所以栈空间是线程私有的，不需要考虑多线程并发访问的同步问题。

“堆”这个名字则强调的是“杂乱堆放、没有固定秩序”。对象在堆上的分配地址不需要连续，分配顺序也不要求有序，只要能从空闲内存中找到一块足够大的区域就行。堆是所有线程共享的，因此涉及并发时需要考虑线程安全问题（比如分配对象时的指针碰撞需要CAS操作）。堆的大小通常远大于栈，可以动态扩展直到物理内存上限。

很多人问我：为什么JVM不把所有东西都放在栈上？那样不是更高效吗？答案是，栈的存储模型决定了它只适合“生命周期与方法调用严格同步”的数据。但你没法保证一个对象只会被当前方法使用，它可能被返回给调用方、被存入全局缓存、被多个线程同时引用。这种情况下，对象必须活到方法返回之后，甚至活到程序结束。只有把这类长生命周期对象放在一个独立管理的区域——也就是堆里——才能做到。

2.3 一张图看懂JVM运行时数据区里的“双支柱”

如果你接触过JVM规范，会看到运行时数据区被分成程序计数器、虚拟机栈、本地方法栈、堆、方法区（元空间）这几块。但如果我们把视角聚焦到“内存分配”这个主题，真正的主角就是堆和栈：

有人可能会问：方法区里的类信息和静态变量算什么？严格来说，方法区在HotSpot虚拟机中对应元空间（Metaspace），它也是一块独立的内存区域，既不归堆管也不归栈管。但静态变量本身指向的对象实例仍然在堆上。所以做内存分析时，不能只看堆和栈，元空间也可能成为内存泄漏的源头。这里先不展开，后面排查部分我会提到。

3. 栈内存深度拆解：线程私有的“执行脉络图”

3.1 栈帧里到底装了什么：局部变量表、操作数栈、动态链接、返回地址

很多教科书把栈帧描述得很抽象，我用一个实际的方法调用来说明。假设有这样一个方法：

public int add(int a, int b) { int result = a + b; return result; }

当线程执行到add方法时，会为它创建栈帧，栈帧从上到下包含四部分核心内容：

• 局部变量表：存放方法参数和内部定义的局部变量。这里的最小单位是槽（Slot），32位类型占1个槽，long和double占2个槽。上面例子中a、b、result会占3个槽（准确说this占第0个槽，如果方法是实例方法）。
• 操作数栈：临时存放计算过程中的中间结果。执行a + b时，会先把a和b压入操作数栈，执行加法指令后弹出两个数，再压入结果。操作数栈的深度在编译期就能确定。
• 动态链接：栈帧中保存一个指向运行时常量池中该方法的引用，以便在运行时解析符号引用为直接引用。这就是Java多态能够动态分派的基础。
• 返回地址：方法正常返回时，恢复调用者的程序计数器；若发生异常，则通过异常处理表找到对应的异常处理器。

栈帧的生命周期非常清晰：方法调用开始入栈，方法结束出栈。这里有个细节很多人忽略——栈溢出不一定是因为方法调用层级太深，栈帧本身太大也会溢出。比如一个方法定义了超大的局部数组：

public void badMethod() { byte[] buffer = new byte[10 * 1024 * 1024]; // 10MB }

这个数组对象本身在堆上，但数组引用和一部分编译期信息在栈帧里不会占多少空间。假如你在局部变量表里同时声明了几百个变量（虽然编码规范不允许），栈帧占用就会变大，同样深度更容易溢出。

3.2 栈内存溢出：递归是直接导火索，但并非唯一原因

StackOverflowError是栈内存溢出的典型异常，最常见的触发场景就是无限递归：

public long factorial(int n) { // 没有终止条件 return n * factorial(n - 1); }

这种代码一执行，就会不断创建栈帧，直到栈深度达到上限。JVM默认栈深度在几百到几千层不等（取决于栈大小和局部变量数量），具体值可以用-Xss调节。不过我要提醒一句：默认栈大小别轻易调大。调大-Xss确实能容纳更多栈帧，但每开一个线程都会按这个值预留栈空间。如果你把栈开到8MB，系统创建1000个线程，仅栈空间就吃掉8GB虚拟内存。上面说的“unable to create native thread”错误，很多时候就是因为栈空间预留过大导致无法为新线程分配内存。

递归之外的栈溢出场景更隐蔽。比如线程数过多时，每个线程的栈都会占用一块内存，累积起来就可能触及操作系统对进程虚拟内存的限制（比如32位系统进程地址空间只有4GB）。还有一种情况是栈帧特别大，我在一些老系统里见过在方法里声明了超大型局部数组（虽然数组实体在堆，但在栈上会有一个指向数组的引用，这并不占太多空间）——更典型的其实是操作数栈深度过大，比如在方法里写了一个超长的算术表达式，编译器生成的字节码会不断压栈，导致栈帧超大。这种情况不常见，但遇到的时候会比较懵。

3.3 为什么说栈是“高效但受限”的存储区域

栈的分配和释放只需要移动栈顶指针，几乎没有任何额外开销。这一点在性能敏感的场景里至关重要。比如你写一个循环调用方法，每次调用分配一个临时变量，栈操作的成本可能只有几纳秒；相比之下，在堆上new一个小对象，虽然JVM做了优化（比如TLAB，线程本地分配缓冲），但仍然有可能触发GC。

但栈的高效是有代价的：空间有限、生命周期必须嵌套、数据不能跨线程共享。正因如此，JVM才需要堆来承接那些生命周期不确定、可能被多个线程访问的对象。这也引出一个非常重要的编程建议：能用局部变量就别用全局变量，能用值类型就别创建对象。一个方法内部临时计算用的数据，放在栈上最合适；而需要跨方法传递、可能长期存活的数据，才应该放到堆上。

4. 堆内存深度拆解：对象的大本营与GC的“责任田”

4.1 对象是如何被分配在堆上的：指针碰撞与空闲列表

堆内存的分配不像人想象的那么随意。JVM内部会把堆划分为年轻代（Young Generation）和老年代（Old Generation），年轻代里又分为Eden区和两个Survivor区。绝大多数对象优先在Eden区分配。

分配对象需要解决一个关键问题：如何找到一块合适的空闲内存？主流实现有两种方式：

• 指针碰撞（Bump-the-Pointer）：适用于堆内存规整的场景（比如使用标记-整理算法的Serial、ParNew收集器）。空闲内存是一整块，只需要把一个指针（称为分配指针）向后移动对象大小即可。
• 空闲列表（Free List）：适用于堆内存不规整的场景（比如使用标记-清除算法的CMS收集器）。JVM需要维护一个空闲列表记录哪些内存块可用，分配时从列表中找到一块足够大的区域划分出来。

为了保证线程安全，JVM还引入了**TLAB（Thread Local Allocation Buffer）**机制：每个线程在Eden区预先分配一段私有的缓冲区，线程分配对象时优先在TLAB中进行，不需要锁或CAS，只有在TLAB空间不足时才去堆上竞争分配。这就是为什么你看到的对象分配速度可以非常快——多数情况下它走的是TLAB的本地快速路径。

4.2 Minor GC、Major GC与Full GC：堆内存的分代回收逻辑

堆内存的回收逻辑与对象的年龄密切相关。JVM假设“绝大多数对象朝生夕灭”，所以把堆分为年轻代和老年代。

• 年轻代存放刚创建的对象，空间通常不大，占用堆的1/3左右。Eden区满了之后，会触发Minor GC，把存活对象复制到Survivor区。
• Survivor区分为S0和S1，作用是让对象在一次GC中存活下来并增加年龄。默认对象年龄达到15（可配置）后晋升到老年代。
• 老年代存放长生命周期对象。老年代空间不足时触发Major GC或Full GC，这是一个代价很高的操作，往往伴随较长的“Stop The World”停顿。

很多线上故障的根因就是对象生命周期估算失误。比如你从数据库查出一批数据，放到一个static Map里做缓存，但忘了设计过期策略，这些对象就会从年轻代一路晋升到老年代，永远不释放，最终堆被填满，触发频繁Full GC。这时候堆内存的使用率会呈锯齿状上升，而GC线程占用的CPU会越来越高，接口延迟飙升。

4.3 堆内存设置不当的典型表现：Xmx调太大会怎样，调太小又会怎样

堆内存参数调整是运维中最常见的操作，也是最容易出错的地方之一。我见过不少人把-Xmx调到物理内存的90%，觉得“内存不浪费就是好事”。结果呢？GC频繁到无法接受，因为留个操作系统的内存太少，触发GC的频率反而更高。

堆内存设置有几个原则供参考：

• -Xms和-Xmx建议设为相同值，避免运行时动态伸缩堆带来的性能抖动。
• 堆大小需要给操作系统和元空间预留空间。一台4GB内存的机器，堆最大建议给2GB~2.5GB，剩下的要留给JVM自身代码、线程栈、元空间以及操作系统文件缓存。
• 大堆不一定更好。堆越大，Full GC的时间越长。以G1收集器为例，一次Full GC如果堆是8GB，可能停顿几秒甚至更久。所以内存充裕时，优先考虑调整GC算法，而不是无限堆大堆。
• 注意堆外内存。NIO（Netty、Kafka等）会使用堆外内存（Direct Memory），这部分不归-Xmx管，但有独立的-XX:MaxDirectMemorySize限制。如果堆外内存无限增长，同样会导致进程OOM，而且Java堆监控还看不到问题。

4.4 从热词“堆外内存”说开去：Direct Memory与堆的关系

近期“堆外内存”这个关键词热度不低。简单解释一下：堆外内存是JVM进程堆之外、由操作系统直接分配的内存，典型代表是java.nio.ByteBuffer的allocateDirect()方法。为什么需要堆外内存？主要原因是避免数据在Java堆和操作系统之间复制。比如网络传输时，如果数据在堆内，JVM需要先把数据复制到DirectBuffer，再交给操作系统发送；如果直接用DirectBuffer，则省去一次复制。

堆外内存也有自己的问题：它不受GC直接管理，必须手动释放（或依赖Cleaner机制间接回收）。很多同学使用Netty时发现“堆内存正常，但进程RSS（常驻内存）持续上涨”，十有八九是堆外内存泄漏。排查时不能只看堆，需要借助Native Memory Tracking（NMT）工具，开启-XX:NativeMemoryTracking=summary，然后在JVM里执行jcmd <pid> VM.native_memory summary查看详细分布。这是官方推荐的做法，比单纯用top看内存瞎猜要靠谱得多。

5. 堆与栈的协作机制：引用、逃逸分析与栈上分配

5.1 对象在堆上，引用在栈上：这层关系你必须理清

很多刚入门的同学容易被“对象引用”这个概念绕晕。我用最简单的话总结：局部变量存的是“地址”，地址指向堆上的对象。栈上不保存对象本体，只保存对象的入口地址。举个例子：

public void doSomething() { List<String> list = new ArrayList<>(); // ... }

list变量在栈上，它保存的是一个指向ArrayList对象的内存地址。ArrayList对象本身在堆上。当方法结束时，栈上的list变量被弹出，相当于这张“地址卡片”被撕掉了。但ArrayList对象依然躺在堆上，只是没有任何引用指向它了，它就变成了“不可达对象”，等待GC回收。

理解这一点后，内存泄漏的原理就清楚了：栈变量虽然消失，但如果堆上的对象还被某个静态变量、缓存或全局集合引用，它就永远不会被回收。所以排查内存泄漏时，我们追踪的不只是对象的创建位置，更是引用链——从GC Roots出发，看这条链上哪个节点堵住了回收的去路。

5.2 逃逸分析：栈上分配不是传说，但有严格条件

JVM有一种高深的优化技术叫“逃逸分析”（Escape Analysis）。它的核心是：如果一个对象不会被当前方法之外的任何代码访问，那么这个对象就不一定非要分配在堆上，可以尝试在栈上分配。栈上分配最大的好处是：方法结束时栈帧弹出，对象内存自动释放，完全不需要GC介入。

但这个优化有严格前提。对象必须满足“未逃逸”——不能作为方法返回值、不能作为参数传给其他方法、不能被全局变量引用、不能被其他线程访问。实际编码中，大量对象都会逃逸，所以真正能被标量替换优化的场景并不多。JVM默认是开启逃逸分析的（JDK 8以后默认-XX:+DoEscapeAnalysis），它还会做同步消除、标量替换等配套优化。

举个典型例子：

public long calcSum(int[] nums) { long sum = 0; for (int n : nums) { Point p = new Point(n, 1); sum += p.x * p.y; } return sum; }

如果Point对象在循环体内创建，且没有逃逸出calcSum，JVM可能把它拆散成两个局部变量（标量替换），根本不在堆上创建对象。这就是为什么有些人写代码时new很多小对象，性能依然不错的原因——JVM替你擦了一部分屁股。但这不代表可以无所顾忌地创建对象，逃逸分析是“尽力而为”，不是保证。

5.3 大对象直接进入老年代：避免反复copy的优化策略

JVM还有一个与堆栈协作相关的参数：-XX:PretenureSizeThreshold。大于这个阈值的对象，会直接分配到老年代，不经过Eden区和Survivor区。为什么？因为大对象在年轻代GC时，从一个Survivor区复制到另一个Survivor区的代价太高，而且如果它存活期很短，复制完就会被回收，白白浪费IO和CPU。

示例配置：

java -Xms4g -Xmx4g -XX:PretenureSizeThreshold=1048576 -jar app.jar

上面配置表示大于1MB的对象直接进老年代。但注意：这个参数在G1收集器下可能不生效，G1有自己的巨型对象处理逻辑。我没法覆盖所有收集器的细节，但请你记住一个调优原则：参数调整要以GC日志和性能监控为依据，不能凭感觉。我见过有人把PretenureSizeThreshold调到1KB，结果老年代疯长，Full GC更频繁了。

6. 堆内存与栈内存的实用排查与调优指南

6.1 分清症状：StackOverflowError和OutOfMemoryError的初步判定方法

一句话困境：线上崩了，你怎么知道是堆的问题还是栈的问题？最直接的办法是看日志里的异常类型：

• 看异常类名

  • 关键字StackOverflowError：栈的问题，排查递归、方法调用深度、线程栈大小。
  • 关键字OutOfMemoryError: Java heap space：堆空间不足，排查对象占用，很可能内存泄漏。
  • 关键字OutOfMemoryError: unable to create new native thread：创建线程失败，通常与栈大小和线程数量有关。
  • 关键字OutOfMemoryError: Metaspace：元空间不足，与加载的类数量相关。

• 看日志中是否有“native memory exhausted”等C层错误，这往往指向堆外内存。

除了异常类型，还需要结合监控工具辅助定位。常见命令包括：

# 查看JVM堆使用情况 jmap -heap <pid> # 打印堆内存中的对象统计（触发Full GC前使用） jmap -histo:live <pid> # 生成堆转储文件，供MAT分析 jmap -dump:format=b,file=heap.hprof <pid> # 查看线程栈信息 jstack <pid>

这里有个关键技巧：生成堆转储前最好确认GC不是频繁Full GC状态。如果线上服务已经因为频繁GC导致CPU飙高，执行jmap -histo:live会先触发一次Full GC，很可能让服务直接雪上加霜。安全做法是先保留现场，或者在低峰期操作。

6.2 堆溢出排查：从堆转储文件里找出“元凶对象”

排查堆溢出的标准路径是：

1. 使用jmap或-XX:+HeapDumpOnOutOfMemoryError（强烈建议生产环境开启）生成堆转储文件。
2. 用MAT（Memory Analyzer Tool）或VisualVM打开文件。
3. 重点看“Leak Suspects”报告，MAT会列出最可能的泄漏点。
4. 查看“Dominator Tree”找出占用内存最大的对象。
5. 沿着对象引用链，回溯到GC Roots，看为什么这个对象没有被回收。

我处理过的一个典型案例：一个定时任务每天从第三方接口拉取大量数据，代码中用一个static Map做缓存。代码逻辑是“如果key不存在则添加到Map”，但数据源中key会周期性变化，旧key永远不会被删除。结果半年后Map里积累了上千万条记录，占了几GB堆内存。用MAT一分析，Dominator Tree里最大的就是那个Map，引用链一拉，直接暴露了业务代码的漏洞。

6.3 栈溢出排查：死循环递归与“线程过多”的区分处理

栈溢出并不总是递归导致的。有一次线上出现StackOverflowError，调用栈显示是在JSON序列化时爆的。查下来发现两个对象互相引用，形成了一个无限循环的序列化过程：A对象里有B，B对象里有A，序列化器没有配置循环引用处理，导致栈帧一层层套下去，最终栈溢出。这个案例的排查方法很简单：拿到异常堆栈，看到at com.alibaba.fastjson.serializer...和at com.yourcompany.model.Order.getUser...交替出现，立刻就能判断是循环引用。

另一种栈相关故障是“线程数量过多”。这种问题异常信息往往不是StackOverflowError，而是无法创建线程。排查方法是：

# 查看当前进程的线程数 jstack <pid> | grep "java.lang.Thread.State" | wc -l # 或直接看进程下的线程数 ls /proc/<pid>/task | wc -l

如果线程数超过几千，就需要注意了。可能的原因包括：连接池配置过大、显式创建线程没有回收、HTTP客户端连接泄漏等。此时需要抓线程堆栈，观察线程都在干什么。我曾经遇到一个系统，线程全部阻塞在一个Notifier上，原来是某个阻塞队列没人消费，生产者端一直在等队列有空位，导致线程池不断申请新线程。

6.4 调整参数的正确姿势：-Xss、-Xms、-Xmx、-XX:MaxDirectMemorySize怎么配合

这里给出一份合理的参数配置参考，实际请按机器配置和应用场景调整：

# 4核8G机器，Java应用，服务型进程 java -Xms2g -Xmx2g \ -Xss512k \ -XX:MaxDirectMemorySize=512m \ -XX:+HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath=/data/logs/heap_dump.hprof \ -XX:+UseG1GC \ -jar app.jar

说明：

• -Xms和-Xmx设为2g，给进程其他部分留出足够空间。
• -Xss设为512k，比默认值（常见1MB）略小，适合线程数较多的云服务场景，但要确认业务没有深递归调用。
• -XX:MaxDirectMemorySize=512m，限制堆外内存上限，防止DirectBuffer泄漏拖垮进程。
• 开启HeapDumpOnOutOfMemoryError，把堆转储落盘，这是排查OOM最重要的现场资料。
• 使用G1收集器，适合堆大小2GB以上、对停顿时间有要求的场景。

很多人问：-Xss是不是设置成1MB以上更安全？我的建议是：先用默认值跑，压测时观察线程栈深度。如果没遇到StackOverflowError，就没必要调大。相反，如果你服务会创建大量线程，适当调小-Xss反而能提升系统容量。我见过一个接入层网关，把-Xss从1MB降到512KB后，同样内存下线程数从2000提升到了3500，吞吐量明显改善。当然，下调前必须做充分的回归测试，防止个别业务路径递归过深导致栈溢出。

6.5 RedisTemplate的opsForZset().add与栈内存溢出：一个容易被忽略的调用链

热搜词里提到redistemplate.opsforzset().add栈内存溢出，看到这个组合我第一反应是：有人在用RedisTemplate操作有序集合时遇到了StackOverflowError。为什么一个看似普通的API调用会栈溢出？这里有几个可能性：

• 序列化器问题：RedisTemplate默认使用JdkSerializationRedisSerializer。如果存储对象内部存在循环引用，序列化时会无限递归。这和前面Fastjson循环引用导致StackOverflowError的原理一样。解决办法是改用Jackson或Fastjson序列化器，并在序列化配置中明确循环引用策略。
• RedisTemplate实例并发问题：RedisTemplate是线程安全的，但在某些错误封装中，开发人员把它放到ThreadLocal里，然后重复设置valueSerializer，可能导致内部状态异常。不过这更多是逻辑错误，而不是栈溢出。
• 方法调用链深层嵌套：如果你自定义了一个HashSet集合，其hashCode或toString方法又调用了RedisTemplate操作，可能会导致无限互相调用。这种代码设计问题比前两者更隐蔽。

处理这类问题，第一步不是调-Xss，而是看堆栈。我总结的排查思路是：

1. 复制异常堆栈，找到第一次重复出现的at ...行，那就是循环调用的起点。
2. 定位到自己的业务代码行，检查是否存在A方法调用B方法，B方法内部又回调A方法的情况。
3. 如果堆栈只显示RedisTemplate内部类调用，优先检查序列化器配置。
4. 最后确认是否有大对象写入ZSet，虽然大对象不至于栈溢出，但会引发堆内存问题。

7. 经验沉淀：我在实际项目中踩过的内存“坑”和最终心得

说实话，堆和栈的概念从大学就开始背，但真正“懂”它们，还是靠一次次线上故障喂出来的。我分享几个印象最深的体会：

第一个体会：别把所有内存问题都甩给堆。有一年左右的时间，我们组排查内存问题只看堆，导致好几次误判。最典型的就是一个基于NIO的网关服务，堆内存一直稳定在500MB左右，但RSS内存一路涨到3GB，最终OOM。后来我们用NMT检查，发现是DirectByteBuffer没释放，堆外内存泄漏。从那以后，我做的任何服务监控面板上都会加上堆外内存和进程RSS的曲线。

第二个体会：调参要有数据支撑，不能拍脑袋。曾经有个同事以为把-Xmx调大就能解决Full GC频繁问题，结果从4G调到8G后，单次Full GC停顿时间从300ms涨到1.2s，业务直接超时。正确的做法是先通过GC日志分析：Full GC频繁是因为老年代空间不足，还是晋升阈值设置不合理？如果是大量短命对象晋升，可能更合适的是调大年轻代，而不是整体扩大堆。

第三个体会：编码习惯对内存体系的影响，远大于参数调优。再好的JVM参数也救不了代码里无休止的new对象、无限增长缓存、深递归调用。我后来定了几条团队编码规范，都和堆栈相关：

• 禁止在循环体内创建不必要的大对象，优先复用。
• 所有缓存必须有上限或过期策略，禁止使用无界Map做Cache。
• 递归调用必须估算最大深度，超过100层要明确使用迭代方式改写。
• 禁止在多线程环境下使用ThreadLocal存储过大的对象，容易造成堆内存泄漏（ThreadLocalMap的Entry是弱引用，但value是强引用）。
• 使用RedisTemplate等客户端时，优先配置JSON序列化器，避免JDK默认序列化带来的递归风险和空间浪费。

这些规范执行一年后，线上内存类故障下降了八成以上。所以你看，了解堆与栈，不只是为了应付面试，更是为了在系统出问题时，你能比其他人更快一步找到真相。如果你在实践中有自己的心得或踩过不同的坑，欢迎继续探索——内存体系这块内容越深挖，越觉得里面藏着整个运算体系的设计哲学。