setAccessible(true)的作用是绕过JVM访问权限检查，通过将AccessibleObject内部override标志置为true，使后续反射调用（如invoke、get）跳过安全管理器校验、修饰符解析及继承关系遍历等耗时流程。
setAccessible(true) 能加速反射调用，根本原因不是“跳过了某个耗时步骤”，而是它让 JVM 在后续每次 invoke() 或 get() 时，彻底绕过访问控制检查链——这个检查链在默认情况下会反复触发安全管理器（SecurityManager）策略校验、修饰符解析、继承关系遍历，甚至涉及 native 层的权限判定。
为什么默认反射调用要走完整访问检查
Java 的访问控制（private/protected/包级）不是编译期擦除的元数据，而是在运行时由 JVM 每次反射操作前强制验证的。例如调用 method.invoke(obj) 时：
- 即使该
Method是public，JVM 仍需确认调用方类是否在相同包、是否有继承关系、是否被模块系统（Java 9+）导出 - 若目标方法是
private，还会额外检查调用栈帧，确保发起调用的类是声明该方法的类本身（即“caller-sensitive”语义） - 如果启用了
SecurityManager（如旧版 Applet 或某些沙箱环境），每次都会调用checkPermission(new ReflectPermission("suppressAccessChecks"))
setAccessible(true) 实际做了什么
它不修改字节码，也不改变字段/方法的原始修饰符，只是把 AccessibleObject 内部一个叫 override 的布尔标志位设为 true。后续所有对该反射对象的操作，JVM 会直接跳过整个访问检查流程。
- 这个标志位是每个
Field/Method/Constructor实例独享的，不是全局开关 - 调用
setAccessible(true)本身有轻微开销（一次 native 调用 + 标志位写入），但换来的是后续成千上万次invoke()或get()的零检查成本 - 注意：
isAccessible()返回true并不表示“已通过检查”，只表示“已标记为跳过检查”——哪怕你对一个public方法调用它，isAccessible()也会变成true，但它原本就无需检查
性能差异在哪儿体现最明显
实测中，加速效果集中在高频、小粒度反射场景，比如 ORM 字段赋值、JSON 序列化、依赖注入容器属性填充。典型表现：
立即学习“Java免费学习笔记（深入）”；
- 对
private字段连续get()100 万次，开启setAccessible(true)后耗时可从 800ms 降至 200ms（JDK 17，HotSpot） - 对
public方法调用，加速不明显（因为本来检查就快），但仍有 5%~10% 提升——说明即使 public，检查链也非零成本 - Java 9 引入模块系统后，跨模块反射（如反射访问
jdk.internal.*）若未加--add-opens，setAccessible(true)会直接失败并抛InaccessibleObjectException，此时它不再“加速”，而是“失效”
容易忽略的兼容性断点
很多人以为 setAccessible(true) 是个“通用加速开关”，但它在现代 JDK 中越来越受限：
- JDK 12 开始，默认禁止对关键内部类（如
java.lang.Class的私有字段）使用setAccessible(true) - JDK 16+ 默认启用强封装（
--illegal-access=deny），反射访问未导出的模块内成员会直接抛异常，setAccessible(true)无法绕过 - 某些安全敏感环境（如 Android ART、GraalVM native image）可能完全禁用该能力，或要求提前注册白名单
真正影响性能的从来不是“能不能访问”，而是“每次访问要不要重跑一遍权限决策”。setAccessible(true) 的本质是把运行时决策，提前固化为一次性的状态标记——这个设计很朴素，但恰恰暴露了 Java 安全模型里“检查”与“执行”的分离边界。一旦越过这条线，后面每一步都得自己担责。
