Java MethodHandles.Lookup 怎样处理模块边界下的访问权限

Java 的 MethodHandles.Lookup 不是“绕过模块系统”的万能钥匙，它更像一张带签发者和权限位的能力凭证：创建句柄时，JVM 会根据 Lookup 记录的查找类、模块关系和权限模式做访问检查。模块边界下最容易混淆的地方，是把 Lookup.in() 当成提权，把 privateLookupIn() 当成无条件反射。

官方 API 地址：https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html

实际选择可以先记成一句话：同一模块内先用 lookup() 或 in() 缩小查找范围；跨模块访问公开成员看可读性和导出关系；需要深度访问时，调用方必须具备相应权限，目标包还必须对调用方模块 opens，再使用 privateLookupIn()。

Lookup 对象到底保存了什么权限

调用 MethodHandles.lookup() 得到的对象会记录调用方类，也就是 lookup class。之后通过 findVirtual、findStatic、findGetter 或 findConstructor 创建句柄时，访问检查发生在“创建句柄”这一刻；句柄被调用时不会重新按普通反射方式检查每个调用者。

因此，下面的代码重点不是执行结果，而是把查找上下文保存在句柄工厂里：

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

final class HandleFactory {
    static MethodHandles.Lookup currentLookup() {
        // lookup() 把当前类作为查找类，权限来自当前模块和类的访问关系。
        return MethodHandles.lookup();
    }

    static MethodHandles.Lookup forType(Class> target) {
        // in() 只改变查找类，不会把原有权限升级到目标类。
        return currentLookup().in(target);
    }

    static MethodType noArgsReturning(Class> returnType) {
        // MethodType 必须与目标方法的返回类型和参数类型匹配。
        return MethodType.methodType(returnType);
    }
}

这里有三个容易忽略的边界：

• lookupClass() 说明“谁在查找”，不是目标类本身。
• lookupModes() 说明当前 Lookup 还保留哪些访问能力，权限只能减少，不能从一个降级对象恢复。
• MethodType 只描述句柄的参数和返回类型；类型匹配正确，也不等于模块访问一定通过。

Lookup.in() 为什么经常让权限变少

in(Target.class) 的作用是把查找类切换到目标类，但它不会替调用方获得目标类的私有权限。官方规则可以按边界来理解：换到不同模块会丢失 MODULE；换到不同包会丢失包级和受保护访问；换到不在同一 nest 的类会丢失私有访问；如果目标类对原 Lookup 不可访问，连公开成员也可能无法查找。

MethodHandles.Lookup caller = MethodHandles.lookup();
MethodHandles.Lookup narrowed = caller.in(Target.class);

// 读取模式用于定位问题；它不是把权限转换成可读的字符串。
int modes = narrowed.lookupModes();

// 句柄创建仍然要满足 Target 的可访问性和成员签名。
var handle = narrowed.findVirtual(
        Target.class,
        "name",
        MethodType.methodType(String.class));

把 in() 当成“换个视角看目标类”更准确，把它当成“进入目标模块”就会误判。尤其是跨到第三个模块时，官方定义的访问能力会继续下降，不能靠连续调用 in() 重新获得私有或模块权限。

跨模块访问为什么需要 privateLookupIn

如果目标是公开成员，通常只需要确认调用方模块能读取目标模块，并且目标包按模块规则可访问；如果目标是私有、包级或需要深度反射的成员，则要看 privateLookupIn(Target.class, caller) 的前置条件。

// module-info.java：调用方模块需要读取目标模块。
module app.core {
    requires target.core;
}

// module-info.java：目标模块把内部包开放给调用方模块。
module target.core {
    opens com.example.internal to app.core;
}

MethodHandles.Lookup caller = MethodHandles.lookup();
// privateLookupIn 不负责“绕过”模块系统；它要求 caller 本身有模块和私有访问能力。
MethodHandles.Lookup targetLookup =
        MethodHandles.privateLookupIn(Target.class, caller);

// 只有目标成员和目标 Lookup 的权限都满足时，句柄创建才会成功。
var handle = targetLookup.findVirtual(
        Target.class,
        "internalName",
        MethodType.methodType(String.class));

这里的 requires 和 opens 解决的是两件不同的事：前者让调用方模块读取目标模块，后者允许目标包进行深度反射访问。跨模块调用成功后，返回的 Lookup 会记录前一个查找类，并丢掉 MODULE 访问；它仍然可以按剩余权限查找成员，但不能继续把自己当成拥有完整模块权限的 Lookup。

四种选择怎么落地

如果框架只需要调用公开方法，不要为了省几行适配代码就开放内部包；把目标包改成 opens 会扩大深度访问面。若必须提供能力给框架，可以创建一个权限更窄的 Lookup，或用 dropLookupMode 主动去掉不需要的模式，再把它交给受信任的适配层。

遇到 IllegalAccessException 先查哪几项

1. 先看目标类所在模块：调用方模块是否真的声明了 requires。
2. 再看目标包：公开调用关注 exports，深度访问关注面向调用方的 opens。
3. 打印 lookupClass() 和 lookupModes()，确认 Lookup 没有在 in() 或跨模块跳转中丢掉所需模式。
4. 最后检查 findVirtual 或 findStatic 使用的 MethodType，避免把访问问题和签名不匹配混在一起。

相关问题

Lookup.in() 能否访问目标类的 private 方法？

不能把它当成保证。只有查找上下文仍满足 nest、包和模块访问条件时才可能成功；跨边界后权限通常会减少。需要明确的深度访问时，应评估 privateLookupIn() 及目标模块的 opens。

exports 和 opens 可以互相替代吗？

不可以。exports 面向普通 Java 访问和公开类型，opens 面向深度反射访问。代码只需要公开 API 时优先保持窄的导出面，不要用开放内部包来掩盖模块依赖设计。