都叫内存不足，扩大堆却未必有效。排查 JVM 问题要先读异常类型和对应区域。
本文使用JDK 7，示例为方法体或类定义片段。源码学习需要区分语言规则、公共接口约定与某个版本的实现。本文把讨论范围固定在 Java 7，不把后续版本的集合结构或语法写进来。
1. 从现象推到机制
Java 7 的对象主要分配在堆，线程调用使用各自的虚拟机栈，类元数据涉及方法区及 HotSpot 的永久代实现。递归过深通常表现为栈溢出，持续增加类定义则可能触及永久代边界。
图中的四个节点分别表示异常类型、内存区域、运行证据、原因验证。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
先收集启动参数、进程线程数和完整异常。用独立演示分别制造大对象保留与深递归，禁止在共享服务中进行破坏性实验。
1
2
3
java -Xms64m -Xmx64m Demo
jstat -gc <pid> 1000 5
jstack <pid>
将片段放入独立的小工程，补齐 imports（导入声明）和调用入口。观察返回值、异常类型及对象状态；并发实验需要重复交错，单次没有出错不能证明线程安全。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 持续保留大量对象 | 堆使用量可能不断升高 |
| 递归无法终止 | 可能先出现栈溢出 |
| 创建大量线程 | 还可能耗尽本机线程资源 |
对照 1：持续保留大量对象
堆使用量可能不断升高。观察时记录垃圾回收后仍存活的对象。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：递归无法终止
可能先出现栈溢出。观察时记录重复的调用栈帧。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：创建大量线程
还可能耗尽本机线程资源。观察时记录线程总数与操作系统限制。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
内存区域是定位入口，不是看到异常就调大参数的理由。必须区分合理工作集增长、对象泄漏和资源释放失败，再选择处理方法。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“创建大量线程”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
