Java 9+ 中“暴力反射”受模块系统严格限制，需显式 opens 包或添加 --add-opens 参数，否则抛 InaccessibleObjectException；SecurityManager 可拦截 setAccessible 并抛 SecurityException；JDK 16+ 移除 --illegal-access，反射性能差且应优先用 MethodHandle 或 SPI 解耦。

Java 中所谓“暴力反射”，通常指绕过访问控制（如调用 setAccessible(true)）强行访问私有成员的行为。但自 JDK 9 模块系统引入后，这种“暴力”不再无条件奏效——JVM 启动参数直接决定反射能否成功执行，甚至影响是否抛出 InaccessibleObjectException 或 SecurityException。

模块边界是反射失败的第一道墙

JDK 9+ 默认启用强封装，即使调用 setAccessible(true)，若目标类所在模块未显式 opens 对应包给当前模块，反射操作仍会静默失效，随后 invoke() 或 get() 抛出 InaccessibleObjectException。

• 典型报错：Unable to make field private int java.util.ArrayList.size accessible
• 根本原因：java.base 模块未对你的模块开放 java.util 包的反射权限
• 临时解决（仅限调试）：--add-opens java.base/java.util=ALL-UNNAMED
• 生产环境替代方案：在 module-info.java 中声明 opens java.util to your.module;，或重构为通过公共 API 交互

安全管理器可拦截 setAccessible 调用

启用 SecurityManager 后，每次调用 setAccessible(true) 都会触发权限检查。若策略文件中未授予 ReflectPermission "suppressAccessChecks"，则直接抛出 SecurityException。

• 启动时启用严格安全模式：-Djava.security.manager=allow -Djava.security.policy==/path/to/policy.txt
• 策略文件关键行：permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; —— 若省略此行，所有 setAccessible(true) 均被拒绝
• JDK 17+ 注意：SecurityManager 已被标记为废弃，但仍在部分企业环境中使用；新项目应优先考虑模块化和 SPI 解耦

非法访问开关参数已逐步淘汰

JDK 9 初期提供 --illegal-access=permit / warn / debug / deny 控制旧版反射兼容性，但该参数在 JDK 16 中被移除。现在所有非法跨模块反射默认被拒，不再有“宽松过渡期”。

• JDK 16+ 行为：无论是否设置 --illegal-access，只要模块未 opens，就抛 InaccessibleObjectException
• 迁移建议：将依赖反射的框架升级至支持 JPMS 的版本（如 Spring 6+、Hibernate 6+），避免硬编码 --add-opens
• 验证方式：运行时调用 Module.isExported("package.name") 和 Module.isOpen("package.name", callingModule) 主动检测权限状态

性能与安全的双重代价不能忽视

即便参数允许反射通行，Method.invoke() 仍比直接调用慢 5–50 倍。这不是 JVM 故意拖慢，而是因每次调用都需执行访问检查、参数数组封装、类型擦除适配，且无法被 JIT 充分内联。

• 高频场景必须缓存：提前获取 Method 实例并复用，避免在循环中反复调用 getDeclaredMethod()
• 谨慎使用 setAccessible(true)：仅在可信类加载器加载的类上启用，避免暴露敏感字段或破坏不可变契约
• 更优替代：对性能敏感路径，改用 MethodHandle（invokeExact() 开销接近直接调用）或预编译字节码（如 ByteBuddy）