程序计数器（PC）在线程切换时本质是每个线程的“执行书签”，精确记录下一条字节码指令地址，确保暂停后能精准续跑；它线程私有、不共享、无需同步，保存于上下文，恢复时直接跳转执行，并区分Java与native方法状态，支撑jstack定位卡顿根源。
程序计数器（PC）在线程切换时，本质是每个线程的“执行书签”——它精确记录下一条要执行的字节码指令地址，让线程暂停后再恢复时，不用重头开始，也不会跳错位置。
它是线程私有的唯一执行定位依据
每个线程创建时就分配独立的程序计数器，不与其他线程共享。这意味着：
- 两个线程调用同一个方法，它们的 PC 值分别指向各自当前执行到的字节码偏移量（比如一个停在第8行，另一个在第23行）
- JVM 不需要同步或加锁来维护 PC，天然线程安全
- 线程被操作系统挂起时，PC 值会随寄存器、栈指针等一起保存进线程上下文
线程切回来靠它精准续跑
没有程序计数器，JVM 就无法知道该从哪条指令继续执行。实际恢复过程是：
- CPU 调度器把控制权交还给该线程时，JVM 从保存的上下文中取出 PC 值
- 字节码解释器或 JIT 编译器直接跳转到该地址，取出并执行下一条指令
- 哪怕刚执行完 if 分支跳转、正处在 for 循环中间、或刚进入 catch 块，PC 都能准确定位下一条
它还能反映线程当前运行状态
PC 的值不只是地址，还携带关键语义信息：
立即学习“Java免费学习笔记（深入）”；
- 执行 Java 方法时，PC 存的是方法区中字节码的准确偏移（如 0x000001a8）
- 一进入 native 方法（如 Object.wait()、Unsafe.park()），PC 立即被设为 undefined
- JVM 由此判断：控制权已移交本地库，不再对该线程做 GC 安全点检查，也不参与 Java 栈帧管理
它是排查卡顿和阻塞的第一线索
像 jstack 这类工具能打印出线程正在执行的源码行号，底层依赖的就是 PC 值反查字节码行号表（LineNumberTable）。当看到某个线程长时间停留在某一行：
- 如果 PC 指向普通 Java 字节码，说明可能在计算、循环或等待锁
- 如果 PC 是 undefined，基本可断定线程卡在 native 层（比如系统 I/O、JNI 调用、park 等待）
不复杂但容易忽略——它小到不会 OOM，却撑起了整个 Java 多线程调度的确定性。
