Java反射机制与类加载的实际应用

反射访问私有字段需调用field.setAccessible(true)绕过安全检查，Class.forName()会初始化类而loadClass()不会，不同ClassLoader加载的同名类相互隔离，反射调用方法时JVM自动类型转换易掩盖参数错误。

反射获取私有字段值时为什么抛出 IllegalAccessException

Java 反射访问 private 字段默认被安全检查拦截，即使已用 getDeclaredField() 获取到字段对象。这不是权限配置问题，而是 JVM 运行时的默认行为。

• 必须显式调用 field.setAccessible(true) 绕过访问控制检查（JDK 9+ 在模块化环境下可能需额外加 --add-opens 参数）
• setAccessible(true) 不会改变字段本身的修饰符，只影响当前反射调用链
• 在安全管理器（SecurityManager）启用的生产环境中，该调用可能被拒绝，需提前评估策略

Class.forName() 和 ClassLoader.loadClass() 的加载时机差异

两者都可按名称加载类，但触发类初始化的时机不同，直接影响静态块执行和常量赋值。

• Class.forName("com.example.Service")：默认会初始化类（执行 static 块），等价于 Class.forName(name, tru

  

  e, currentClassLoader)
• ClassLoader.loadClass("com.example.Service")：默认不初始化类（resolve = false），仅加载并返回 Class 对象
• 若依赖类的静态初始化逻辑（如注册、缓存预热），误用 loadClass() 会导致空指针或状态未就绪

自定义 ClassLoader 加载相同全限定名类时的隔离性

不同 ClassLoader 实例加载的同名类，在 JVM 中视为完全不同的类型，不能互相赋值或强制转型，哪怕字节码一模一样。

• 常见于插件系统、热部署场景；instanceof 判断会失败，getClass().equals() 返回 false
• 跨类加载器通信应通过接口（由启动类加载器或共同父加载器提供）而非具体实现类
• 避免在自定义加载器中重复委托给父加载器后又自己加载——易引发 LinkageError

public class PluginClassLoader extends ClassLoader {
    private final Map classBytes = new HashMap<>();

    public PluginClassLoader(ClassLoader parent) {
        super(parent);
    }

    @Override
    protected Class findClass(String name) throws ClassNotFoundException {
        byte[] bytes = classBytes.get(name);
        if (bytes == null) throw new ClassNotFoundException(name);
        // 关键：不调用 super.findClass()，避免双亲委派干扰
        return defineClass(name, bytes, 0, bytes.length);
    }
}

反射调用方法时参数类型不匹配却没报错？

使用 Method.invoke(obj, args...) 时，JVM 会尝试自动装箱/拆箱、基本类型与包装类互转、向上转型，导致“看似成功”但结果异常。

• 例如目标方法为 void process(int x)，传入 Integer.valueOf(5) 能运行，但传入 null 会抛 IllegalArgumentException
• 推荐先用 method.getParameterTypes() 校验参数类型，再手动转换，尤其在泛型擦除后无法靠反射还原真实泛型参数时
• JDK 8+ 可配合 MethodHandles.Lookup 构建强类型句柄，提前暴露类型错误

反射和类加载的边界很薄：一个 setAccessible(true)、一次错位的 forName、一个没处理好的类加载器隔离，都可能让逻辑在测试环境正常、上线后静默失败。这些不是边缘情况，而是实际支撑框架（如 Spring、MyBatis）运转的底层契约。