PC寄存器在执行native方法时值为undefined，因其不涉及Java字节码指令，JVM无法提供有效地址，且规范明确要求此时PC失去语义意义，仅作逻辑标记，不反映物理CPU指令位置。
执行本地方法（native method）时，JVM 的程序计数器（PC 寄存器）**不存储有效地址值，而是被设置为 undefined（未定义）**。
为什么 native 方法下 PC 值是 undefined
本地方法由 JVM 外部实现，通常是用 C/C++ 编写并直接调用操作系统 API 或硬件资源。这类方法的指令不在 JVM 字节码体系内，也不经过字节码解释器或 JIT 编译器调度，因此：
- JVM 无法为其生成对应的字节码地址，PC 寄存器自然没有“下一条 JVM 指令”可指；
- 控制权已完全移交至本地库，当前线程的执行流程脱离 JVM 指令流，PC 失去语义意义；
- JVM 规范明确要求：当线程执行 native 方法时，PC 寄存器的值为 undefined，而非保持原值、清零或指向某个固定地址。
undefined 不等于空值或随机数
这里的 undefined 是一个规范层面的逻辑状态，并非内存中某个具体数值：
- 它不表示 PC 寄存器物理上被清零或置为 0x00000000；
- 也不意味着寄存器内容不可读——实际运行中可能残留进入 native 前的最后字节码地址，但 JVM 明确禁止依赖该值；
- 不同 JVM 实现（如 HotSpot）通常会在进入 native 方法前将 PC 标记为无效态，在返回 Java 方法时再重新加载有效地址。
与物理 CPU 中 PC 的区别
需注意：JVM 的 PC 寄存器是对物理程序计数器的抽象模拟，二者作用域不同：
- 物理 CPU 的 PC 始终指向当前正在取指/执行的机器指令地址（无论在执行 Java 字节码解释器、JIT 编译代码，还是 native 函数）；
- 而 JVM 的 PC 寄存器只对 Java 线程可见，且仅服务于字节码调度逻辑；一旦进入 native，它的职责即暂停，不再反映底层 CPU 的真实指令位置。
实际调试中的表现
在使用 jstack、JVMTI 或调试器观察线程状态时：
- 若线程正阻塞在
Object.wait()、Thread.sleep()或 JNI 函数（如System.currentTimeMillis()底层调用）中，其栈帧会显示 “in native code”，PC 值常显示为0x0或unknown； - 这不是 bug，而是 JVM 主动屏蔽了无意义的地址信息，避免误导开发者。
