Java访问修饰符是编译期检查的语法约束，字节码仅以access_flags标记（如ACC_PUBLIC/ACC_PRIVATE），运行时由JVM在链接阶段解析符号引用时依据规范校验访问合法性，非法访问抛IllegalAccessError。
Java 的访问修饰符（public、protected、default、private）在编译期就由 javac 强制检查，**字节码本身不包含运行时访问控制逻辑**，也不会在 ClassLoader 或 Interpreter 阶段动态执行“修饰符校验”。真正的访问检查发生在类加载的**验证阶段（Verification）** 和 **链接阶段（Linking）中的准备/解析环节**，由 JVM 在加载类时根据字节码中的修饰符标志（access_flags）和调用上下文静态判定是否合法。
字节码中如何体现访问修饰符
每个类、字段、方法在字节码中都有一个 access_flags 字段（2 字节），它用位掩码表示修饰符。例如：
-
ACC_PUBLIC（0x0001）→public -
ACC_PRIVATE（0x0002）→private -
ACC_PROTECTED（0x0004）→protected -
ACC_STATIC（0x0008）、ACC_FINAL（0x0010）等也共存于此
使用 javap -v 可直观查看：
public class A {
private int x;
protected void m() {}
}
反编译后字段 x 的 Access flags: 显示 private，方法 m 显示 protected —— 这些只是元数据标记，不生成任何指令。
立即学习“Java免费学习笔记（深入）”；
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
JVM 何时真正检查访问权限
访问控制不是靠字节码指令执行的，而是在以下两个关键时机由 JVM 内部逻辑拦截并拒绝非法访问：
-
类加载解析阶段（Resolution）：当解析一个符号引用（如
invokestatic、getfield）时，JVM 检查目标类/字段/方法的access_flags，结合当前类（发起调用者）与目标类的包关系、继承关系，按 Java 语言规范判断是否可访问。若失败，抛出IllegalAccessError（链接错误，非运行时异常） -
反射调用时（
AccessibleObject.setAccessible(true)除外）：反射 API（如Method.invoke()）会在执行前显式检查access_flags，不满足则抛IllegalAccessException
注意：private 方法被子类重写？不会——JVM 不允许解析到父类 private 方法，子类同名方法是全新声明，无继承关系。
为什么不能从字节码“绕过”访问控制
因为访问检查是 JVM 规范强制要求的语义保障，不是可选优化：
- 即使手动修改字节码（如用 ASM 把
private改成public），只要类能通过验证器（Verifier），运行时就能访问；但若违反规则（如跨包调用原private成员），JVM 在解析时直接报错，不给执行机会 - HotSpot 中相关逻辑位于
LinkResolver::check_access等 C++ 函数，属于 native 层硬性约束 -
ACC_SYNTHETIC或ACC_BRIDGE等标志也受同样检查机制约束，说明该机制覆盖所有成员级别修饰
动手验证的小技巧
想亲眼看到访问检查触发时机，可以：
- 写两个类，让一个类非法访问另一个类的
private字段，编译会失败 → 说明javac做了第一道检查 - 用
javap -v查看access_flags十六进制值，对照 JVMS §4.1 理解位含义 - 用字节码工具（如 Byte Buddy）动态生成一个“试图调用
private方法”的类，加载时大概率抛IllegalAccessError - 在反射调用前不设
setAccessible(true)，观察IllegalAccessException抛出位置
