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事件响应。此时必须把“后续动作”封装成接口传入，避免阻塞或循环依赖。
立即学习“Java免费学习笔记（深入）”；
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的场景）
