17370845950

Java对象间通信本质是方法调用，即通过引用直接调用public或包内可见方法；可控方式仅三种：直接调用、回调接口、事件总线；底层依赖JVM动态绑定机制，常见陷阱包括null引用、重载误判与重写失效。

Java对象间通信的本质是方法调用，不是“发消息”

Java没有内置的“对象通信”抽象层（比如Actor模型或Objective-C的runtime消息转发），所谓通信，就是持有引用后直接调用对方的public或包内可见的方法。关键不在于“怎么通”，而在于“谁持有谁的引用”以及“调用时机是否合理”。

• 常见错误：试图用static方法或单例强行解耦，结果导致测试困难、状态污染
• 真正可控的通信方式只有三种：直接调用（A持有B的实例）、回调接口（B执行完通知A）、事件总线/观察者（松耦合，但需自行管理生命周期）
• 不要混淆“通信”和“数据传递”——传参是值拷贝（基本类型）或引用拷贝（对象），不会自动同步状态

方法调用的底层机制：从字节码到JVM栈帧

每次obj.doSomething()执行，JVM实际做的是：压入当前栈帧 → 查obj的实际运行时类型 → 在该类的MethodTable中定位doSomething的字节码地址 → 跳转执行。这就是动态绑定（virtual call）的核心。

• invokestatic：只用于static方法，编译期就确定目标，无多态
• invokevirtual：普通实例方法，默认行为，支持重写（override）
• invokeinterface：调用接口方法，JVM需在运行时搜索实现类的具体方法
• invokedynamic：Java 7+引入，用于Lambda、方法句柄等动态场景，首次调用有开销

容易被忽略的调用陷阱：null、重载与重写冲突

表面是通信问题，根源常是调用逻辑没理清。最典型的三类坑：

• NullPointerException：调用方持有的引用为null，尤其在异步或依赖注入未完成时（如Spring中@Autowired字段在constructor外被访问）
• 重载（overload）误判：编译器按**参数声明类型**选方法，不是运行时类型。例如print(Object o)和print(String s)，传new Object() {}会进前者，哪怕子类重写了toString()
• 重写（override）失效：父类方法是private或final，子类同名方法只是新定义，调用父类引用时不会触发子类逻辑

何时该用回调而不是直接调用？

当调用方无法/不应等待被调用方执行结束时，比如I/O、定时任务、GUI事件响应。此时必须把“后续动作”封装成接口传入，避免阻塞或循环依赖。

public interface DataCallback {
    void onSuccess(String data);
    void onError(Exception e);
}

public class DataLoader {
    public void loadAsync(DataCallback callback) {
        // 模拟异步
        new Thread(() -> {
            try {
                String result = fetchFromNetwork();
                callback.onSuccess(result); // 主动“通知”调用方
            } catch (Exception e) {
                callback.onError(e);
            }
        }).start();
    }
}

• 回调对象必须能被安全持有——避免传入this导致内存泄漏（Android中常见）
• 如果回调逻辑复杂，优先考虑CompletableFuture或Reactive Streams，而非手写回调链
• 不要在回调里再反向调用原对象的同步方法，极易死锁（尤其是加了synchronized的场景）

JVM的方法调用机制本身很稳定，出问题几乎都源于设计时没想清楚“谁该对谁负责”。引用怎么建、生命周期怎么管、错误怎么透出——这些才是通信能否落地的关键。