稳定性专题 | StackOverFlowError 常见缘由及解决方法

导读

『StabilityGuide』是阿里多位阿里技术工程师共同发起的稳定性领域的知识库开源项目，涵盖性能压测、故障演练、JVM、应用容器、服务框架、流量调度、监控、诊断等多个技术领域，以更结构化的方式来打造稳定性领域的知识库，欢迎您的加入。

@GitHub :https://github.com/StabilityMan/StabilityGuide

每个 JVM 线程都拥有一个私有的 JVM 线程栈，用于存放当前线程的 JVM 栈帧（包括被调用函数的参数、局部变量和返回地址等）。若是某个线程的线程栈空间被耗尽，没有足够资源分配给新建立的栈帧，就会抛出 java.lang.StackOverflowError 错误。

线程栈是如何运行的？

首先给出一个简单的程序调用代码示例，以下所示：

public class SimpleExample {
      public static void main(String args[]) {
            a();
      }
      public static void a() {
            int x = 0;
            b();
      }
      public static void b() {
            Car y = new Car();
            c();
      }
      public static void c() {
            float z = 0f;
      }
}

当 main() 方法被调用后，执行线程按照代码执行顺序，将它正在执行的方法、基本数据类型、对象指针和返回值包装在栈帧中，逐一压入其私有的调用栈，总体执行过程以下图所示：

首先，程序启动后，main() 方法入栈。

而后，a() 方法入栈，变量 x 被声明为 int 类型，初始化赋值为 0。注意，不管是 x 仍是 0 都被包含在栈帧中。

接着，b() 方法入栈，建立了一个 Car 对象，并被赋给变量 y。请注意，实际的 Car 对象是在 Java 堆内存中建立的，而不是线程栈中，只有 Car 对象的引用以及变量 y 被包含在栈帧里。

最后，c() 方法入栈，变量 z 被声明为 float 类型，初始化赋值为 0f。同理，z 仍是 0f 都被包含在栈帧里。

当方法执行完成后，全部的线程栈帧将按照后进先出的顺序逐一出栈，直至栈空为止。

StackOverFlowError 是如何产生的？

如上所述，JVM 线程栈存储了方法的执行过程、基本数据类型、局部变量、对象指针和返回值等信息，这些都须要消耗内存。一旦线程栈的大小增加超过了容许的内存限制，就会抛出 java.lang.StackOverflowError 错误。

下面这段代码经过无限递归调用最终引起了 java.lang.StackOverflowError 错误。

public class StackOverflowErrorExample {
      public static void main(String args[]) {
            a();
      }
      public static void a() {
            a();
      }
}

在这种状况下，a() 方法将无限入栈，直至栈溢出，耗尽线程栈空间，以下图所示。

Exception in thread "main" java.lang.StackOverflowError
    at StackOverflowErrorExample.a(StackOverflowErrorExample.java:10)
    at StackOverflowErrorExample.a(StackOverflowErrorExample.java:10)
    at StackOverflowErrorExample.a(StackOverflowErrorExample.java:10)
    at StackOverflowErrorExample.a(StackOverflowErrorExample.java:10)
    at StackOverflowErrorExample.a(StackOverflowErrorExample.java:10)
    at StackOverflowErrorExample.a(StackOverflowErrorExample.java:10)
    at StackOverflowErrorExample.a(StackOverflowErrorExample.java:10)
    at StackOverflowErrorExample.a(StackOverflowErrorExample.java:10)
    at StackOverflowErrorExample.a(StackOverflowErrorExample.java:10)

如何解决 StackOverFlowError？

引起 StackOverFlowError 的常见缘由有如下几种：

• 无限递归循环调用（最多见）。
• 执行了大量方法，致使线程栈空间耗尽。
• 方法内声明了海量的局部变量。
• native 代码有栈上分配的逻辑，而且要求的内存还不小，好比 java.net.SocketInputStream.read0 会在栈上要求分配一个 64KB 的缓存（64位 Linux）。

除了程序抛出 StackOverflowError 错误之外，还有两种定位栈溢出的方法：

• 进程忽然消失，可是留下了 crash 日志，能够检查 crash 日志里当前线程的 stack 范围，以及 RSP 寄存器的值。若是 RSP 寄存器的值超出这个 stack 范围，那就说明是栈溢出了。
• 若是没有 crash 日志，那只能经过 coredump 进行分析。在进程运行前，先执行 ulimit -c unlimited，当进程挂掉以后，会产生一个 core.[pid] 的文件，而后再经过 jstack $JAVA_HOME/bin/java core.[pid] 来看输出的栈。若是正常输出了，那就能够看是否存在很长的调用栈的线程，固然还有可能没有正常输出的，由于 jstack 的这条从 core 文件抓栈的命令实际上是基于 Serviceability Agent 实现的，而 SA 在某些版本里有 Bug。

常见的解决方法包括如下几种：

• 修复引起无限递归调用的异常代码， 经过程序抛出的异常堆栈，找出不断重复的代码行，按图索骥，修复无限递归 Bug。
• 排查是否存在类之间的循环依赖。
• 排查是否存在在一个类中对当前类进行实例化，并做为该类的实例变量。
• 经过 JVM 启动参数 -Xss 增长线程栈内存空间， 某些正常使用场景须要执行大量方法或包含大量局部变量，这时能够适当地提升线程栈空间限制，例如经过配置 -Xss2m 将线程栈空间调整为 2 mb。

线程栈的默认大小依赖于操做系统、JVM 版本和供应商，常见的默认配置以下表所示：

JVM 版本	线程栈默认大小
Sparc 32-bit JVM	512 kb
Sparc 64-bit JVM	1024 kb
x86 Solaris/Linux 32-bit JVM	320 kb
x86 Solaris/Linux 64-bit JVM	1024 kb
Windows 32-bit JVM	320 kb
Windows 64-bit JVM	1024 kb

提示： 实际生产系统中，能够对程序日志中的 StackOverFlowError 配置关键字告警，一经发现，当即处理。

推荐工具&产品

ARMS —— 阿里云 APM 产品，支持 StackOverFlowError 异常关键字告警

参考文章

• StackOverFlow Error: Causes and Solutions
• The Structure of the Java Virtual Machine
• The StackOverflowError in Java
• JVM源码分析之栈溢出彻底解读

做者信息：夏明，GitHub ID @StabilityMan，花名涯海，阿里云 ARMS & EagleEye 技术专家，2016 年加入阿里巴巴，一直从事链路追踪和 APM 监控诊断领域的相关工做。

 

原文连接

本文为云栖社区原创内容，未经容许不得转载。