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）
