Java MethodHandles.Lookup 如何控制私有成员访问：privateLookupIn、调用点与模块边界

线上组件把反射改成 MethodHandle 后，最容易遇到的不是方法签名写错，而是 Lookup 的权限来源不对：同一个私有方法，在类路径测试里能调用，放进模块后却在 privateLookupIn 处失败。排查这类问题要把“谁发起查找、查找哪个类、模块是否允许深度访问”分开验证。

privateLookupIn 能把查找位置切到目标类并保留私有访问能力，但它不会凭空授予模块权限；目标模块必须对调用方可读，并对目标包开放深度访问。

反射能看到，MethodHandle 却拿不到：先复现调用链

假设 SecretBox 位于 demo.target 模块的 internal 包中，类里有一个实例方法 reveal。调用方不要直接把 publicLookup() 传给 privateLookupIn；它缺少做深度访问所需的原始能力。

MethodHandles.Lookup caller = MethodHandles.lookup();
MethodHandles.Lookup target = MethodHandles.privateLookupIn(SecretBox.class, caller);
MethodType type = MethodType.methodType(String.class);
MethodHandle reveal = target.findVirtual(SecretBox.class, "reveal", type);
String value = (String) reveal.invoke(new SecretBox());

这段代码的控制流只有四个关键点：MethodHandles.lookup 产生调用方视角，privateLookupIn 把查找类切到 SecretBox，findVirtual 返回实例方法句柄，最后 invoke 接收一个 SecretBox 实例。任何一步的类型或权限不匹配，异常位置都不同。

把失败点定位到 Lookup 的权限快照

Lookup 不是一个只记录类名的句柄，它还携带访问模式。用 lookupModes() 打印快照，可以判断问题发生在目标类切换前，还是发生在模块检查阶段。

static void printModes(String name, MethodHandles.Lookup lookup) {
    System.out.printf("%s: class=%s, modes=0x%x%n",
            name, lookup.lookupClass().getName(), lookup.lookupModes());
}

MethodHandles.Lookup caller = MethodHandles.lookup();
printModes("caller", caller);
MethodHandles.Lookup target = MethodHandles.privateLookupIn(SecretBox.class, caller);
printModes("target", target);

官方 API 将访问能力表示为位掩码，包含 PUBLIC、PRIVATE、PROTECTED、PACKAGE、MODULE 等模式。通过 privateLookupIn 得到的新 Lookup 会拥有目标类上的私有访问，但不再拥有调用方模块的 MODULE 能力；这不是异常，而是跨模块“传送”后的权限收缩。

模块边界为什么会让同一段代码失效

在命名模块中，调用方模块必须读取目标模块，目标包还必须对调用方开放 opens。exports 解决的是编译期和普通公共访问；私有成员的深度访问检查关注的是 opens。因此只添加 exports demo.target.internal;，并不能替代面向调用方的开放声明。

module demo.caller {
    requires demo.target;
}

module demo.target {
    opens demo.target.internal to demo.caller;
}

如果目标包没有开放，privateLookupIn 通常会抛出 IllegalAccessException。如果调用方连目标模块都不可读，结果同样不会因为方法是私有还是公开而自动变好。运行时先确认实际模块描述符，再确认 SecretBox.class.getModule() 和调用方模块是否符合预期。

修复后怎样验收调用点

回归测试建议同时检查权限和结果：先断言目标 Lookup 的 lookupClass() 是 SecretBox，再查找 reveal，最后用真实实例调用。不要只测类路径，因为类路径没有命名模块的读取与开放边界。

MethodHandles.Lookup target = MethodHandles.privateLookupIn(SecretBox.class,
        MethodHandles.lookup());
MethodHandle handle = target.findVirtual(
        SecretBox.class, "reveal", MethodType.methodType(String.class));
Object result = handle.invoke(new SecretBox());
if (!"ok".equals(result)) {
    throw new AssertionError("unexpected reveal result: " + result);
}

这里的成功状态是：查找阶段没有 NoSuchMethodException 或 IllegalAccessException，调用阶段返回预期字符串，且测试运行时使用了和生产一致的模块启动参数。若只把失败改成吞异常，后续调用点仍会在运行时暴露问题。

常见问题

privateLookupIn 是不是等同于关闭 Java 权限检查？

不是。它仍受模块可读性、目标包开放状态和 Lookup 既有能力约束，只是在满足条件时提供比普通访问更深的查找能力。

为什么 findVirtual 找到了方法，invoke 还会失败？

findVirtual 只验证名字、返回类型和参数类型，并返回一个实例方法句柄；调用时还必须传入正确的接收对象，且动态参数类型要匹配。

能不能用 dropLookupMode 之后再恢复权限？

不能。访问模式一旦从 Lookup 中丢弃，就不能从这个降级后的对象恢复；需要新的原始 Lookup 时，应回到可信调用点重新建立查找链。

收尾检查清单

• 记录 Lookup 的调用方类和目标类。
• 分别检查 requires 与 opens，不要把两者混为 exports。
• 用 lookupModes() 观察权限收缩，再验证 findVirtual 和实例调用。
• 在命名模块运行一次回归测试，确认测试环境没有掩盖生产边界。