程序计数器（pc）是分支跳转的唯一执行引擎，所有跳转指令均通过直接或间接修改pc值实现；pc始终指向将要取指的指令地址，其更新贯穿顺序执行、条件/无条件跳转、函数调用与返回全过程。
程序计数器（PC）不是“辅助角色”，而是分支跳转的**唯一执行引擎**——所有跳转指令最终都通过直接或间接修改 PC 的值来生效。业务线程的 if、循环、函数调用等行为，在汇编层面，本质就是 CPU 在每个时钟周期里不断更新 PC，并依据当前指令类型决定下一条取哪条指令。
PC 是跳转的落点，不是跳转的起点
很多人误以为“跳转指令发出后，PC 才动”。实际上，PC 始终指向“将要取指”的那条指令地址。当 CPU 执行到 B label 或 jmp func 时，硬件在译码阶段就已解析出目标地址，并在取指流水线的下一拍把该地址写入 PC。也就是说：
- 顺序执行时：PC 自动加指令长度（ARM 每条固定 +4；x86 动态+1~15）
- 无条件跳转时：PC 被强制覆盖为目标地址（如 B 指令中的 24 位偏移量经符号扩展后与当前 PC+8 相加）
- 条件跳转时：PC 是否被改写，取决于标志位（ZF/CF/SF/OF 等）是否满足——不满足则 PC 继续按序递增，满足才加载新地址
业务线程里的分支 = PC 在多个地址间动态切换
一个 Java 线程执行 if (status == READY) { doWork(); }，JIT 编译后可能生成如下 x86-64 汇编片段：
jne .L_else
call doWork@PLT
.L_else:
...
此时 PC 的行为是：
- 执行 cmp 后，PC 指向 jne 指令地址
- 执行 jne 时，CPU 查 ZF：若为 0（即 status ≠ 1），PC 加 2（jne 指令长）→ 指向下一条指令（.L_else）
- 若 ZF=1，则 PC 被设为 .L_else 的绝对地址（或相对偏移）→ 跳过 call
线程调度不会打断这个过程；PC 的每一次变更，都是该线程私有上下文的原子动作。
函数调用与返回：PC 和 LR/RA 的协同控制
业务中常见的方法调用，在汇编里是 PC 与链接寄存器（ARM 的 LR / x86 的 RIP+pop）的配合：
- BL func：PC ← func 地址；同时 LR ← 当前 PC + 4（即 call 后那条指令）
- ret / BX LR：PC ← LR 值，线程回到原分支路径继续执行
- 多层嵌套时，LR 可能被压栈保存（如 BL → PUSH {LR} → BL → POP {PC}），确保 PC 总能准确回溯
这正是业务线程能维持调用栈、支持异常传播和调试断点的根本机制——没有 PC 的精准跳转与恢复，就没有“方法”这个概念。
现代 CPU 的优化没绕开 PC，只是提前猜它
分支预测、流水线冲刷、推测执行，所有这些技术都在围绕一个核心问题：**PC 下一步大概率是什么？**
- 遇到 jg 时，CPU 不等比较结果出来，就根据历史记录“猜”一次跳还是不跳，并提前把猜测地址送进取指单元
- 猜错 → 冲刷流水线 → PC 回滚到正确地址重新取指（性能代价）
- 但无论猜对猜错，最终生效的仍是 PC 寄存器的确定性赋值——硬件逻辑始终以 PC 为准绳
