移动开发中的 Stack Overflow — 它是什么，原因和预防方法

什么是 Stack Overflow

StackOverflowError — 是 Java 虚拟机 (JVM) 或 Android Runtime (ART) 的致命错误，当线程的调用栈达到最大允许深度时发生。与 OutOfMemoryError（堆不足）不同，StackOverflowError 与另一内存区域 — 栈 — 相关，其中存储方法调用帧和局部变量。

每个方法调用在栈中创建一个帧：返回地址、参数和局部变量。从方法返回时，帧被销毁。如果方法调用自身（递归）而没有基本条件，帧会累积直到栈满。JVM 无法分配新帧并抛出 StackOverflowError，消息为「null」（在 Java 中）或显示无限重复的栈字符串。

线程栈的大小在创建时固定，在执行期间不会改变。在 Android 中，主线程的典型栈大小为 32–48 KB，对于没有大量局部变量的方法，提供约 512–1024 帧的深度。对于后台线程，默认大小更小 — 16–24 KB。

调用栈如何工作

调用栈 (Call Stack) — 是一种 LIFO（后进先出）数据结构，管理方法的执行顺序。每当程序调用方法时，JVM 在栈中创建一个帧并将其放在顶部。方法完成时，帧被移除。

每个帧包含：operand stack（字节码指令的操作数栈）、array of local variables（包括 this）、reference to constant pool 和返回地址。方法拥有的局部变量越多，其帧的大小就越大，在栈满之前可以调用的方法就越少。具有 10 个参数和 20 个局部变量的方法比没有参数的方法占用大约 3 倍的空间。

在 Android 上，ART 使用自己的栈实现，与桌面 JVM 不同。ART 可以在一定限度内动态增加栈，但对于每个线程仍然存在硬性限制。主线程（UI 线程）拥有最大的栈，因为整个 Activity 生命周期和事件处理都在其上执行。

// 导致 StackOverflowError 的递归
fun recursiveCall(depth: Int): Int {
    return recursiveCall(depth + 1) // 没有基本条件
}

// 调用将在 ~1000 深度导致 StackOverflowError
recursiveCall(0)

栈溢出的主要原因

五种典型场景会导致移动应用中的 StackOverflowError。大多数与递归相关，但也有不那么明显的原因。

无基本条件的无限递归

最常见的原因。开发人员编写了没有停止条件或条件永远不会变为 true 的递归方法。每次调用添加一个帧，栈在 500–2000 次迭代后填满，具体取决于帧大小。典型示例：计算阶乘 n! 而没有检查 n == 0。

在每个递归方法的开头检查基本条件。在 Kotlin 中，使用 require() 或 check() 在开始时验证参数。对于深度递归（超过 100 层），考虑替换为迭代方法。

构造函数中的循环依赖

类 A 创建 B 的实例，类 B 创建 A 的实例 — 这是构造函数中的循环依赖。当尝试创建 A 时，调用 B 的构造函数，B 调用 A 的构造函数，如此直到 StackOverflowError。DI 框架（Dagger、Hilt）在编译阶段检测此类循环，但手动创建对象无法捕获它们。

使用依赖注入与依赖关系图：Dagger 或 Koin 在构建阶段检查循环。如果循环不可避免，将直接依赖替换为具有延迟初始化的接口或 Provider 工厂。

// 循环依赖 — StackOverflowError
class A(private val b: B)
class B(private val a: A)

// 惰性解决方案
class A(private val bProvider: Provider<B>)

遍历图时的深度递归

遍历视图树 (ViewGroup.getChildAt())、文件系统或 JSON 结构通过递归可能在深度超过 500–1000 个元素时超过栈限制。20 层嵌套的 Android ViewGroup 很少见，但包含 2000 个嵌套对象的 JSON 的递归解析是真实的场景。

将递归遍历替换为通过显式 Stack<T> 或 ArrayDeque 的迭代遍历。这完全消除了栈溢出的风险，因为堆中的对象不受栈限制的限制。通过队列的 BFS（广度优先搜索）也可以解决此问题。

onConfigurationChanged 的错误处理

Android 特定的原因：在错误处理配置时生命周期方法的循环调用。例如，在 onConfigurationChanged 中调用 recreate()，后者再次调用 onConfigurationChanged，如此直到 StackOverflowError。类似地：在 onLayout() 内部调用 setContentView()，导致重复测量和布局。

不要在与配置更改相关的方法内部调用recreate()。在主题更改时更新 UI，请使用 setTheme() 而不使用 recreate。对于动态方向更改 — 一次性 requestOrientation()，配置中不带标志。

具有循环引用的序列化

Gson、Moshi 或 Kotlin Serialization 在尝试序列化具有循环引用的对象（A 引用 B，B 引用 A）时进入无限递归并崩溃，出现 StackOverflowError。这是序列化具有双向关系的 Entity 时常见的问题（JPA、带有 ForeignKey 的 Room）。

为循环的一侧使用 @Transient、@JsonIgnore 或 @kotlinx.serialization.Transient。对于 Gson — 使用带有显式深度限制的 JsonSerializer。对于 Room — 永远不要直接序列化 Entity，使用 DTO 映射器。

如何诊断和修复 StackOverflowError

诊断 StackOverflowError 比其他内存错误更简单：stack trace 在大多数情况下显示重复的调用序列。这立即表明递归。

读取 stack trace

StackOverflowError 的 stack trace 是唯一的：在前 200–500 行之后，开始重复相同的调用模式。JVM 在末尾截断重复行并显示「... 1234 more」。在「...」之前的不重复行数显示了导致错误的递归深度。

阅读 stack trace 的第一行 — 它们显示重复从哪个方法开始。找到调用自身或创建返回到本身的调用链的方法。修正基本条件或将递归替换为循环。

增加栈大小（临时解决方案）

临时可以通过 JVM 标志 -Xss 增加栈大小来解决问题。在 Android 中，栈大小通过 AndroidManifest 设置：android:largeHeap 不影响栈。要在代码中增加线程栈：Thread(ThreadGroup, Runnable, name, stackSize)。stackSize — 以字节为单位的所需大小。

// 创建具有增大栈的线程
val thread = Thread(null, runnable, "big-stack-thread", 64 * 1024)
thread.start()

重要：增加栈并不能解决问题，只能延迟它。在 10,000 层递归时，64 KB 的栈将被 128 KB 的栈替换，这将提供 20,000 层 — 但错误仍然会发生，只是更晚。唯一正确的解决方案 — 迭代替换递归。

将递归替换为迭代

迭代算法不使用调用栈来存储中间状态 — 它们将其存储在堆中（Stack<T> 或 ArrayDeque）。二叉树遍历、阶乘计算、斐波那契 — 任何递归都可以通过显式栈转换为迭代。

// 迭代树遍历 — 无 StackOverflow 风险
fun traverseIterative(root: Node?) {
    val stack = ArrayDeque<Node>()
    stack.push(root)
    while (stack.isNotEmpty()) {
        val node = stack.pop() ?: continue
        process(node)
        node.right?.let { stack.push(it) }
        node.left?.let { stack.push(it) }
    }
}

如何预防 Stack Overflow

预防 StackOverflowError 是一组规则和工具，用于在潜在的递归循环进入生产环境之前发现它们。

Debug 版本中的递归深度限制

在 debug 版本中向递归方法添加保护性深度计数器。如果深度超过阈值（例如 1000），抛出一个带有清晰消息的异常。这将把带有不可读 trace 的 StackOverflowError 转换为可理解的业务异常。

fun safeRecursive(n: Int, depth: Int = 0): Int {
    if (depth > 1000) {
        throw IllegalStateException("递归超过了 1000 层")
    }
    return if (n <= 1) n
           else safeRecursive(n - 1, depth + 1)
}

静态代码分析

Detekt（Kotlin）和 Infer（Facebook）在静态分析级别找到潜在的无限递归。Detekt 具有 PotentiallyInfiniteRecursion 规则，该规则警告没有参数更改的 self-call。将其包含在 CI 规则集中并将严重性设置为 error。

专注于递归的 Code Review

在 code review 中注意：任何 self-call 方法、lambda 内的递归调用（Kotlin 内联函数）、不同类之间的循环调用、property delegates 中的递归。对于每个递归方法，检查：是否有基本条件、参数是否在每个步骤中更改、参数更改是否保证达到基本条件。

尾递归转换（有限）

Kotlin 支持 tailrec 修饰符：如果递归方法标注了 tailrec 且调用是尾调用（最后操作），编译器将其转换为迭代。但是 tailrec 仅适用于 self-call（方法直接调用自身），不适用于相互递归，并且在 1.5 之前的 Android 兼容 Kotlin 版本中不受支持。

tailrec fun factorial(n: Int, acc: Int = 1): Int {
    return if (n <= 1) acc
           else factorial(n - 1, acc * n) // 尾调用
}