方法引用生成的getClass调用作用及AspectJ移除后的行为咨询

一、为什么Java 8对有效final的非空变量生成空检查指令？ #

Java 8编译器为方法引用插入dup; getClass(); pop指令（等效于letters.getClass()）的核心原因是遵循语言规范要求的错误时机：

• 根据Java语言规范，实例方法引用（如letters::contains）的目标对象如果为null，必须在方法引用创建时抛出NullPointerException，而非实际调用方法时。
• JVM的invokedynamic指令本身不会做这个空检查，因此编译器插入额外指令提前触发NPE。

至于你提到的“变量是有效final且由构造调用生成，理论上非空”，编译器不会做这种深度分析：

• 有效final仅保证变量不会被重新赋值，但Java 8的空值分析能力有限，不会追踪Arrays.asList()这类方法的契约（虽然我们知道它不会返回null），也不会考虑线程安全层面的初始化可见性细节。
• 编译器采取保守策略：对所有实例方法引用的目标对象统一插入空检查，避免因特殊场景漏检导致错误时机不符合规范。

Java 9+换成Objects.requireNonNull是更直接的实现方式，但本质都是为了提前触发NPE，符合语言规范。

二、AspectJ移除检查指令后，引用为null时的invokedynamic行为？ #

如果AspectJ移除了空检查指令，且目标变量被篡改为null，行为并非未定义，但会违反语言规范的错误时机预期：

• invokedynamic的引导方法会成功创建方法句柄，但当后续实际调用该方法句柄（比如filter操作执行时），实例方法调用需要非空的目标对象，此时会抛出NullPointerException。
• 这与规范要求的“在方法引用创建时抛出NPE”不符，但JVM层面的行为是确定的——不会出现崩溃或未定义操作，只是错误抛出的时机延后了。

不过需要注意：如果你的代码库中大量存在这种情况，虽然不会导致未定义行为，但可能增加调试难度（NPE出现在方法调用时而非初始化时），建议评估AspectJ的织入规则是否有调整空间，或者通过静态代码分析工具批量验证目标变量的非空性。

内容的提问来源于stack exchange，提问作者Michael