Java MethodHandles.Lookup 访问私有成员的权限边界

用 MethodHandles.Lookup 调用私有成员时，先看“谁在创建句柄”，再看目标类所在的包和模块。MethodHandles.lookup() 带着调用位置的访问能力；publicLookup() 只适合公开成员；跨模块访问私有成员则必须满足目标包的 opens 条件。它不是一个可以绕过 Java 访问控制的总开关。

先把 Lookup 当成能力对象

我在排查方法句柄失败时，第一步不会改成反射，而是把 Lookup 的来源写出来。MethodHandles.lookup() 由当前调用位置产生，能否看到包私有或私有成员取决于这个位置；publicLookup() 则主动放弃这类能力。对外部类创建句柄时，调用者身份比目标方法的名字更重要。

同一 nest 中创建私有实例方法句柄

下面的 Vault 是示例类的嵌套成员。LookupDemo 与它属于同一 nest，因此当前 Lookup 可以查找私有实例方法。findVirtual 的方法类型只写参数和返回值，不把接收者对象重复放进 MethodType；接收者会成为句柄调用时的第一个参数。

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

final class LookupDemo {
    private static final class Vault {
        private String token() {
            return "local-token";
        }
    }

    static String readToken() throws Throwable {
        // 当前调用位置属于 Vault 的同一 nest，可检查到 private 方法。
        MethodHandles.Lookup lookup = MethodHandles.lookup();
        MethodHandle handle = lookup.findVirtual(
                Vault.class,
                "token",
                // 方法类型只描述 token 的参数和返回值。
                MethodType.methodType(String.class));
        // 非静态句柄的第一个参数是实例接收者。
        return (String) handle.invokeExact(new Vault());
    }
}

如果把同样的查找动作搬到没有访问权的类中，异常不是“方法不存在”，而是创建阶段的访问检查失败。排错时要同时打印调用类、目标包和模块关系，不能只盯着方法名。

跨模块访问要把 opens 写进设计

privateLookupIn(Target.class, lookup) 不是万能的深反射入口。它要求原始 Lookup 具备必要的模块访问能力，并且目标模块把目标包 opens 给调用方模块；否则仍会在创建新 Lookup 时失败。下面只展示能力转换的形状，实际模块名要替换成项目自己的名称。

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

static String readAcrossModule(Class> target) throws Throwable {
    // privateLookupIn 受模块 opens 关系约束，不是绕过访问控制。
    MethodHandles.Lookup privateLookup = MethodHandles.privateLookupIn(
            target,
            MethodHandles.lookup());
    MethodHandle handle = privateLookup.findVirtual(
            target,
            "token",
            // 目标方法无参数、返回 String；真实项目要按签名匹配。
            MethodType.methodType(String.class));
    // 调用者必须传入目标类实例，且句柄类型要与 invokeExact 对齐。
    return (String) handle.invokeExact(target.getDeclaredConstructor().newInstance());
}

这段示例故意把边界放在模块配置上：如果只是为了调用公开 API，不应增加 opens。模块开放会扩大运行时反射能力，应当按包、按调用方收窄。

用 publicLookup 验证失败，并收窄句柄能力

当代码明确只允许公开成员时，使用 publicLookup() 反而更容易审查。它找不到私有方法是预期行为；这能把“配置缺失”和“代码本来就不该访问私有成员”区分开。已经拿到的 Lookup 还可以用 dropLookupMode 主动削弱能力，避免把不必要的权限沿调用链传下去。

try {
    // publicLookup 只用于公开成员；查找 private 方法应当失败。
    MethodHandles.publicLookup().findVirtual(
            LookupDemo.Vault.class,
            "token",
            MethodType.methodType(String.class));
} catch (IllegalAccessException expected) {
    // 记录访问边界，别把它误判成 NoSuchMethodException。
    System.out.println("private member is outside public lookup");
}

方法句柄创建成功后，持有它的代码就拥有调用能力；官方文档也特别提醒，非公开成员句柄应谨慎保密。缓存句柄时可以把它放在只读的私有字段中，避免通过公共插件接口、脚本桥接或任意回调暴露出去。

常见误区与排查顺序

为什么方法明明存在却是 IllegalAccessException？

先核对 Lookup 的创建位置，再核对目标成员是否私有、是否同包、目标模块是否导出或开放目标包。方法签名错误更接近 NoSuchMethodException，不要用改签名的方式掩盖权限问题。

privateLookupIn 能否代替所有反射调用？

不能。它只在满足模块访问和 opens 的前提下扩展到目标类，而且会改变权限审查面。能调用公开方法时优先使用公开接口；只有确有框架适配需求时，才把私有句柄封装在受控边界内。

实际项目可以按“调用位置 → 目标成员 → 包关系 → 模块关系 → 句柄类型”的顺序排查。这样既能解释失败原因，也能避免为了让一次调用成功而无范围地打开模块。