4. 栈与方法区调优：-Xss设置线程栈大小、栈溢出（StackOverflowError）避坑、元空间（Metaspace）调优

好，咱们进入第四章。这一章聊的是JVM内存模型里两个容易被忽视、但一出问题就让人头疼的区域——栈和方法区。

栈溢出（StackOverflowError）我估计不少人都见过，尤其是做递归或者深度调用的时候。元空间（Metaspace）则是Java 8之后替代永久代的新家伙，调不好也会出幺蛾子。今天咱们就把这两个地方彻底捋清楚。

4.1 线程栈：-Xss 到底设多大？

先说说线程栈。每个线程都有自己的栈空间，用来存放局部变量、方法调用链、操作数栈这些。这个大小由 -Xss 参数控制。

默认值是多少？

  • Linux x64：1MB
  • Windows：取决于系统，通常也是1MB
  • macOS：也是1MB左右

听起来1MB不小对吧？但你要想想，一个高并发的Web应用，线程池里可能同时有几百个线程。每个线程1MB，光栈空间就吃掉几百MB甚至上GB的内存。我见过一个项目，默认配置下线程数一上去，直接OOM，查了半天才发现是栈空间吃掉的。

核心原则：栈不是越大越好。够用就行，多了浪费内存。

4.1.1 怎么设置？

设置方式很简单，启动参数里加一行：

java -Xss256k -jar myapp.jar

或者用更明确的写法：

java -XX:ThreadStackSize=256 -jar myapp.jar

注意单位：-Xss 可以写 256k、1m；-XX:ThreadStackSize 的单位是KB，直接写数字就行。

4.1.2 设多大合适？

我个人习惯分场景来定：

场景 推荐栈大小 说明
普通Web应用（Spring Boot等） 256k ~ 512k 调用深度不大，256k基本够用
深度递归/复杂算法 1m ~ 2m 递归深度大，栈空间要留足
高并发网关/代理 128k ~ 256k 线程数多，栈越小越好，但要测试
大数据/流处理 512k ~ 1m 调用链可能较长，折中方案

我的经验：先设一个保守值（比如256k），然后压测。如果出现StackOverflowError，再逐步调大。别一上来就给1MB，浪费。

4.2 栈溢出（StackOverflowError）避坑指南

StackOverflowError 是JVM直接抛出的错误，不是异常。这意味着你catch不到——嗯，严格来说你能catch到java.lang.StackOverflowError，但通常catch了也没用，因为栈已经满了，啥也干不了。

4.2.1 常见触发场景

  1. 无限递归——最常见。递归没写终止条件，或者条件永远不满足。
  2. 深度递归——递归深度太大，比如处理树形结构、JSON解析、XML解析。
  3. 方法调用链过长——A调B，B调C，C调A……循环依赖。
  4. 线程栈太小——正常调用深度，但栈设得太小。

我曾经在一个项目中遇到过：一个同事写了个递归解析菜单树的代码，数据量不大时没问题，但有一次导入了一棵深度超过1000层的树，直接StackOverflowError。嗯，后来改成迭代+显式栈解决了。

4.2.2 避坑实战技巧

技巧一：递归转迭代

能不用递归就不用递归。大部分递归都可以用循环+显式栈（比如 Deque）改写。

// 递归写法（容易栈溢出）
public void traverse(TreeNode node) {
    if (node == null) return;
    System.out.println(node.val);
    traverse(node.left);
    traverse(node.right);
}

// 迭代写法（安全）
public void traverse(TreeNode root) {
    Deque<TreeNode> stack = new ArrayDeque<>();
    stack.push(root);
    while (!stack.isEmpty()) {
        TreeNode node = stack.pop();
        if (node == null) continue;
        System.out.println(node.val);
        stack.push(node.right);
        stack.push(node.left);
    }
}

技巧二：限制递归深度

如果必须用递归，加一个深度计数器，超过阈值就抛业务异常。

public void traverse(TreeNode node, int depth) {
    if (depth > 1000) {
        throw new RuntimeException("递归深度超限");
    }
    if (node == null) return;
    traverse(node.left, depth + 1);
    traverse(node.right, depth + 1);
}

技巧三：压测验证栈大小

上线前用压测工具模拟最大调用深度，确认栈大小够用。别等到线上出了再救火。

警告：StackOverflowError 出现时，JVM不会自动恢复。即使你catch住了，当前线程也基本废了。最好的策略是预防，而不是事后处理。

4.3 元空间（Metaspace）调优

Java 8 开始，永久代（PermGen）被元空间（Metaspace）取代。最大的变化是：元空间使用本地内存（Native Memory），不再占用堆内存。

说白了，元空间存的是类的元数据——类结构、方法信息、字段信息、常量池等。你加载的类越多，元空间占用越大。

4.3.1 关键参数

参数 作用 默认值
-XX:MetaspaceSize 元空间初始大小（触发GC的阈值） 约21MB（依赖平台）
-XX:MaxMetaspaceSize 元空间最大大小 无上限（受本地内存限制）
-XX:MinMetaspaceFreeRatio GC后元空间最小空闲比例 40%
-XX:MaxMetaspaceFreeRatio GC后元空间最大空闲比例 70%

注意： MetaspaceSize 不是初始分配大小，而是触发FGC的阈值。当元空间使用量达到这个值，JVM会触发Full GC来回收类卸载。

4.3.2 调优策略

场景一：类加载频繁，元空间不断增长

比如动态代理、CGLIB、Groovy脚本、热部署等场景。我见过一个项目用Groovy做规则引擎，每次执行都动态编译新类，元空间蹭蹭往上涨。

解决方案：

  • 设置 -XX:MaxMetaspaceSize 限制上限，防止内存泄漏撑爆本地内存。
  • 调大 -XX:MetaspaceSize，减少频繁FGC。
  • 确保类加载器可以卸载（避免类加载器泄漏）。
java -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -jar myapp.jar

场景二：元空间FGC频繁

如果监控发现FGC频繁，且每次FGC后元空间使用量下降不多，说明 MetaspaceSize 设得太低了。调大这个值，让JVM不那么容易触发FGC。

我个人习惯：对于普通Spring Boot应用，MetaspaceSize 设128m~256m，MaxMetaspaceSize 设256m~512m。对于Groovy、动态代理多的应用，可以再翻一倍。

避坑：不要不设 MaxMetaspaceSize！虽然默认无上限，但一旦有类加载泄漏，元空间会一直涨到吃掉所有本地内存，导致操作系统OOM Killer杀掉进程。设一个上限，至少能让你在监控里发现问题。

4.3.3 元空间内存泄漏排查

元空间泄漏通常表现为：元空间使用量持续上升，FGC无法回收，最终达到 MaxMetaspaceSize 抛出 OutOfMemoryError: Metaspace。

排查步骤：

  1. 加参数 -XX:+TraceClassLoading -XX:+TraceClassUnloading，看哪些类在加载/卸载。
  2. 用 jstat -gc <pid> 监控元空间使用量。
  3. 用 jmap -clstats <pid> 查看类加载器详情。
  4. 重点检查：自定义类加载器是否被GC Roots引用？动态代理类是否重复生成？

我曾经帮一个团队排查过：他们的热部署框架每次重新部署都会创建新的类加载器，但旧的类加载器被某个全局缓存引用着，导致无法卸载。元空间就这么一点点涨上去，直到OOM。解决方案很简单——清缓存或者用弱引用。

4.4 本章知识体系图

下面这张图帮你把栈和方法区的调优脉络串起来：

栈与方法区调优知识体系 线程栈（-Xss） 元空间（Metaspace） 默认值：Linux 1MB / Windows 1MB 设置方式：-Xss256k / -XX:ThreadStackSize=256 场景化推荐：Web 256k / 递归 1m StackOverflowError 避坑 递归转迭代 限制递归深度 压测验证 避免循环调用 替代永久代，使用本地内存 关键参数：MetaspaceSize / MaxMetaspaceSize 调优策略：设上限、调阈值 Metaspace OOM 排查 TraceClassLoading jstat -gc 监控 jmap -clstats 检查类加载器泄漏 核心原则：够用就好 + 设上限 + 压测验证

这张图把栈和元空间的核心知识点、参数设置、避坑策略、排查手段都串起来了。你可以把它当作调优时的检查清单——遇到栈溢出先看递归，遇到元空间OOM先查类加载器泄漏。

好，这一章就到这里。栈和方法区的调优，说白了就是两件事：栈要够用但别浪费，元空间要设上限但别太小。记住这两条，大部分问题都能提前规避。

← 上一章 📖 返回目录 下一章 →