考察点
内存结构是 JVM 部分的开门题，答不好后面 GC、调优都不用聊了。面试官想听的是你能否把「五大区域」和实际故障联系起来，而不是背定义——比如什么场景栈溢出、什么场景堆溢出、元空间 OOM 一般是什么引起的。大数据岗位会额外关注堆外内存，因为 Spark、Flink 大量使用 off-heap。追问常往 OOM 类型区分、直接内存、字符串常量池位置变化走。
参考答案
线程私有的三个区域
程序计数器是当前线程执行字节码的行号指示器，每个线程一份，互不干扰，这样线程切换后才能恢复到正确位置。它是唯一一个规范里没有 OutOfMemoryError 的区域。执行 native 方法时计数器值为空。
虚拟机栈描述 Java 方法调用的内存模型：每个方法调用创建一个栈帧，里面存局部变量表、操作数栈、动态链接、方法出口。局部变量表存基本类型和对象引用，编译期就确定大小。这个区域两种异常：栈深度超限抛 StackOverflowError（典型是无限递归）；栈动态扩展失败抛 OutOfMemoryError。
本地方法栈服务于 native 方法，HotSpot 把它和虚拟机栈合并了。大数据里调用 JNI 压缩库（比如 Snappy、LZ4 的 native 实现）就涉及这块。
线程共享的区域
堆是最大的一块，几乎所有对象实例和数组都分配在这里，也是 GC 的主战场。默认分新生代（Eden + 两个 Survivor，比例默认 8:1:1）和老年代，新生代默认占堆的 1/3。堆不够抛 OutOfMemoryError: Java heap space。大数据作业里这个错最常见，比如一个 map 算子里用 HashMap 做全量聚合，数据倾斜时单个 task 内存直接爆掉。
方法区存类元信息、常量、静态变量、JIT 编译后的代码。实现上有个重要变化：JDK 7 及以前是永久代（PermGen），大小固定容易 OOM；JDK 8 改成元空间（Metaspace），用的是本地内存，默认只受物理内存限制，用 -XX:MaxMetaspaceSize 设上限。元空间 OOM 常见于动态生成大量类的场景——CGLib 代理、Groovy 脚本、反射大量加载类，数据平台里跑用户自定义脚本时要特别小心。
运行时常量池在方法区里，JDK 7 起字符串常量池挪到了堆里（PermGen 移除过程的一部分），所以 String.intern() 在 JDK 7 之后行为变了：堆里已经有的话直接返回堆引用，不再拷贝。
直接内存
规范里没有，但实际非常关键。NIO 的 DirectByteBuffer 用的是堆外内存，通过 Unsafe.allocateMemory 分配，回收依赖 Cleaner 机制或显式释放，满了抛 OutOfMemoryError: Direct buffer memory。Spark 的网络传输、Flink 的网络缓冲、Netty 都大量使用堆外内存，大数据面试几乎必问。排查堆外 OOM 时看 -XX:MaxDirectMemorySize（默认和 -Xmx 一致）和 NMT（Native Memory Tracking）。
串起来的排查思路
内存问题先分清是哪个区域：heap space 就 dump 堆（-XX:+HeapDumpOnOutOfMemoryError）用 MAT 看大对象和引用链；Metaspace 就看加载了多少类、有没有类加载器泄漏；StackOverflow 看递归深度或直接调 -Xss；Direct buffer 就查 NIO 使用方。大数据场景下还要区分是 JVM 堆内的问题还是框架自己管理的堆外内存（比如 Spark 的 unified memory 里 execution 部分不够用），两者的调法完全不同。
可能的追问
- 对象一定在堆上分配吗？ 不一定。JIT 的逃逸分析能把未逃逸的对象做栈上分配甚至标量替换，方法结束就回收，不进堆。这是 JIT 优化的重要手段。
- 永久代为什么被元空间取代？ 永久代大小固定，类多了容易 OOM 且难以调优；元空间用本地内存按需扩展，还能顺带完成 JRockit 和 HotSpot 的合并。
- 堆为什么要分代？ 基于「绝大多数对象朝生夕死」的经验假设，分代后新生代用复制算法高频快收，老年代低频慢收，整体 GC 成本最低。
- 线上容器环境设 -Xmx 要注意什么？ 老版本 JVM 不感知 cgroup 限制，JDK 8u191+ 和 JDK 10+ 才支持容器感知；K8s 里要留足堆外和元空间的余量，Xmx 设满容器内存会被 OOMKilled。