程序计数器（PC寄存器）不区分静态类与动态代理类，只记录当前线程正在执行的下一条JVM字节码指令地址；代理类字节码由ClassLoader加载、JIT编译后执行，PC仅跟踪方法区中已加载方法的字节码入口，其行为与普通方法完全一致。
程序计数器（Program Counter Register，简称 PC 寄存器）是 JVM 线程私有的小内存区域，它不存储类、字节码或代理类的结构信息，只保存当前线程正在执行的下一条 JVM 指令的地址（即字节码偏移量，pc 值）。因此：
运行时动态生成的代理类，并不会在程序计数器中产生特殊的“物理指令排布”。
这背后的关键点在于：PC 寄存器本身不参与类的生成、加载或结构组织，它只服务于已加载并正在执行的方法调用流程。
下面分三部分说清逻辑：
代理类的字节码不直接映射到 PC 的“排布”
- JDK 动态代理生成的代理类（如
$Proxy0.class）是运行时通过ProxyGenerator生成字节码、再由ClassLoader加载进方法区的。 - 这些字节码最终被 JIT 编译器（如 C2）进一步编译为本地机器指令（x86/ARM 汇编），才可能进入 CPU 指令流水线。
-
但 PC 寄存器只记录当前线程执行到哪条 JVM 字节码指令（如
invokevirtual、aload_0），而不是记录“代理类字节码在内存中怎么排列”。
它关心的是“接下来该取哪条指令”，不是“这些指令来自静态 class 还是动态生成”。
代理方法调用时，PC 的行为和普通方法完全一致
当调用代理对象的方法（例如 proxy.login("alice")）时：
- JVM 查找该代理对象的实际类（如
$Proxy0）； - 定位其
login方法对应的字节码起始地址（存于方法区的Code属性中）； - 将该地址写入当前线程的 PC 寄存器；
- 后续每执行一条字节码，PC 自动递增（或跳转）；
这个过程与调用 UserServiceImpl.login() 没有任何区别——PC 不区分方法来自静态编译还是动态生成，只认方法区里那个已加载的 Method 结构体所指向的字节码入口。
真正影响执行路径的是 invoke() 的分发逻辑，不是 PC 排布
代理类中每个接口方法的字节码，本质都是类似这样的模板：
public void login(String username) {
// 自动生成的代码，固定结构：
handler.invoke(this, method_login, new Object[]{username});
}-
method_login是Method对象（反射元数据）； -
handler是你传入的InvocationHandler实例； - 所有方法都统一跳转到
handler.invoke(...)，而invoke内部再通过反射调用目标对象。
所以，实际的“增强逻辑”（日志、鉴权）发生在 invoke 方法体内，它的字节码地址才是 PC 当前真正追踪的目标；代理类自身只是个轻量跳板，其字节码极简，没有复杂控制流或特殊排布需求。
简单说：PC 寄存器眼里没有“动态代理”这个概念，只有“正在执行哪个方法的哪条字节码”。动态性体现在类加载阶段和方法分发逻辑上，不在指令寻址层面。
