程序计数器只存当前线程正在执行的字节码指令地址（如0x000a），是线程私有、静态分配、无溢出风险的极小内存区域，不会触发outofmemoryerror。
程序计数器到底存什么
它只存当前线程正在执行的字节码指令地址——不是行号，不是方法名，就是 JVM 指令流里的一个偏移量（比如 0x000a）。如果是 native 方法，这个值固定为 undefined。
关键点在于：每个线程私有、生命周期与线程一致、空间极小（通常几个字节）、不涉及对象分配。
常见错误现象：OutOfMemoryError: Java heap space 从不发生在程序计数器上，有人误以为“没看到报错就说明它安全”，其实根本不是“安全”，而是它压根没机会触发 OOM。
为什么它不会 OOM
JVM 规范明确要求程序计数器内存区域是“线程私有且无溢出风险”的。它的大小由 JVM 在启动时静态分配，不随代码逻辑增长，也不参与 GC。
立即学习“Java免费学习笔记（深入）”；
对比其他区域：
-
Java 堆：对象实例分配地，可动态扩容，OOM 最常发生处 -
方法区（或元空间）：类元信息存放处，加载大量动态类可能 OOM -
虚拟机栈：每个方法调用压栈，深度过大（如递归失控）会抛StackOverflowError；线程过多则可能耗尽 OS 内存，但那是系统级失败，不是 JVM 的 OOM
而程序计数器连“溢出”这个概念都不成立——它没有“容量”可言，只有“是否被正确写入”。
它和多线程、协程的关系
线程切换时，JVM 必须保存当前线程的 pc 值，并恢复目标线程的 pc 值，这是保证并发执行正确性的底层基础。
使用场景包括：
- 线程被挂起后恢复执行（如
Thread.sleep()返回） - 同步块进出时的上下文保持
- 协程（如 Loom 的虚拟线程）仍依赖每个虚拟线程独立的程序计数器，只是调度粒度更细
注意：如果你在 JVMTI Agent 或字节码增强中手动修改 pc 值（比如跳过某条指令），极易导致栈帧错位或验证失败，这类操作几乎总是危险的。
调试时怎么观察它
标准 JVM 工具不直接暴露程序计数器值，但可通过以下方式间接确认其行为：
- 用
jstack -l <pid></pid>查看线程栈，其中java.lang.Thread.State: RUNNABLE后面的行号，本质就是当前pc映射到源码的位置（需有调试信息） - 在
javap -v输出的字节码里，每行开头的数字就是指令索引，对应运行时pc的可能取值 - 断点命中时，IDE 调试器显示的“当前执行行”背后就是
pc值查表的结果
容易踩的坑：混淆 pc 和源码行号——编译优化（如内联、重排序）可能导致多个源码行映射到同一指令，或某行不生成指令（如纯注释）。
真正复杂的地方在于：它太轻量，轻量到没人去动它；也正因如此，一旦出问题（比如 JIT 编译器 bug 导致 pc 错位），表现往往是随机崩溃或静默跳过逻辑，极难复现和定位。
