Java接口回调本质是对象引用传递，核心在于引用持有关系与调用时机；需定义含方法的接口、非空校验、避免混淆Handler线程切换与回调解耦；Lambda和CompletableFuture可优化但需注意生命周期与线程安全。
Java接口回调本质是对象引用传递
回调不是魔法，就是把一个实现了特定接口的对象，传给另一个类，让它在合适时机调用你定义好的方法。关键不在“回调”这个词，而在谁持有谁的引用、何时触发方法调用。
常见错误现象：NullPointerException 频繁出现，往往是因为接收回调的变量没被正确赋值，或者传入的是 null 而没做判空；还有人误以为实现接口就必须继承某个类，其实 Java 接口纯契约，和继承无关。
- 回调接口必须定义至少一个方法，比如
onResult(String data)或onComplete() - 被调用方（如网络请求类）需声明一个该接口类型的字段，比如
private CallbackListener listener; - 调用方（业务代码）实现接口后，通过 setter 或构造器把实例传进去，不能只 new 个匿名类却不赋值给接收方
- 触发回调前务必检查
if (listener != null) { listener.onResult(...); }，否则必崩
Android中Handler.post(Runnable)不是接口回调的替代品
很多人混淆「线程切换」和「回调机制」。Handler.post 是把任务切到主线程执行，但它不解决“结果通知谁”的问题；真正的回调要靠接口+对象传递来建立逻辑归属。
使用场景：比如封装一个图片加载工具类，它内部用子线程下载，但下载完得告诉 UI 层更新 ImageView —— 这时必须定义 ImageLoadCallback 接口，而不是只靠 handler.post() 更新界面。
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
Runnable没有参数、无法携带结果数据，而回调接口方法可以有任意参数，比如onSuccess(Bitmap bitmap)和onFailure(Exception e) - Handler 只管线程调度，不负责解耦；接口回调才能让调用方和被调用方彼此不知道对方具体类型
- 若强行用 Handler + 全局变量传结果，会引发内存泄漏或状态错乱，尤其在 Activity 重建时
Lambda 表达式简化回调写法但要注意生命周期
Java 8+ 支持用 Lambda 写单方法接口，看起来简洁，但容易忽略引用捕获带来的隐式强引用问题。
常见错误现象：Activity 销毁后，后台任务仍持有其引用，导致无法回收，最终 OOM；或者 Lambda 中访问了已置为 null 的 View 引用，抛出 NullPointerException。
- 能用 Lambda 的前提是接口只有一个抽象方法（SAM），比如
Runnable、Consumer<string></string>，但自定义回调接口必须加@FunctionalInterface才保险 - 避免在 Lambda 中直接使用
this或非 final 的局部变量；改用弱引用包装上下文，或提前判断 Activity 是否 still alive - 如果回调逻辑复杂、涉及多个步骤，别硬塞进一行 Lambda，老老实实写匿名内部类或独立实现类更可控
异步回调里嵌套多层时优先用 CompletableFuture 而非手写接口链
当需要“请求 A → 成功后请求 B → 成功后再更新 UI”，手写三层回调（callback hell）会让代码迅速失控。Java 8 的 CompletableFuture 提供了声明式组合能力，本质仍是基于接口（Function、Consumer），但规避了手动传递和空判。
性能影响：相比原始回调，CompletableFuture 默认使用 ForkJoinPool.commonPool()，线程复用率高；但若未显式指定线程池，在 IO 密集场景下可能挤占并行度。
- 用
thenApply()处理上一阶段返回值，用thenAccept()做无返回消费，用exceptionally()统一捕获异常 - 不要在
thenRun()里直接操作 UI 控件，仍需切回主线程，比如 Android 中用new Handler(Looper.getMainLooper()).post(...) - 每个
thenXxx()都返回新的CompletableFuture实例，原对象不会被修改，这点和 Stream 类似
最易被忽略的一点：所有异步回调都默认不处理线程中断，如果你的后台任务支持 cancel，得在回调链里手动检查 Thread.interrupted() 或响应 CancellationException。不然用户点了取消，回调还在那儿默默跑着。
