Java接口回调本质是对象引用传递，核心为接口定义、触发者与实现者三方协作；需关注引用持有关系、触发时机及线程安全，避免NPE与UI线程误用。
Java接口回调本质是对象引用传递
回调不是语法糖，也不是框架黑盒——它就是把一个实现了特定接口的对象，当作参数传给另一个对象，等某个时机到了，再调用这个接口里的方法。关键在于：谁持有谁的引用、何时触发、线程是否安全。
常见错误现象：NullPointerException 频发，尤其在异步场景下回调对象已被 GC 或提前置为 null；或者回调执行了，但主线程没感知，误以为“没生效”。
- 必须确保回调对象生命周期 ≥ 被回调方的生命周期，比如 Activity 里传匿名内部类给后台线程，Activity 销毁后回调仍可能触发 → 建议用弱引用包装或显式解注册
- 接口方法不应声明为
static或default（除非明确不依赖实例状态），否则容易掩盖“谁在响应”的逻辑 - 不要在回调方法里直接更新 UI，Android 上需切回主线程；JavaFX 用
Platform.runLater()；Swing 用SwingUtilities.invokeLater()
写一个最小可运行的回调接口示例
别一上来就套 RxJava 或 CompletableFuture，先看清骨架。核心就三样：接口定义、被调用方（触发者）、调用方（实现者）。
假设一个文件下载器需要通知进度：
立即学习“Java免费学习笔记（深入）”；
public interface DownloadCallback {
void onProgress(int percent);
void onComplete(String filePath);
void onError(Exception e);
}
使用时：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
Downloader downloader = new Downloader();
downloader.setCallback(new DownloadCallback() {
@Override
public void onProgress(int percent) {
System.out.println("下载中：" + percent + "%");
}
@Override
public void onComplete(String filePath) {
System.out.println("完成：" + filePath);
}
@Override
public void onError(Exception e) {
System.err.println("失败：" + e.getMessage());
}
});
- 接口方法名要动词开头，语义明确，避免
handle()、call()这类泛化命名 - 如果回调只有一种结果（如成功/失败二选一），优先用
Consumer<T>或BiConsumer<T, Exception>等函数式接口，减少样板代码 - 不要让回调接口继承
Serializable，除非真要跨 JVM 传输（比如 RMI），否则徒增负担
异步回调里最容易漏掉的线程切换
Java 没有“自动线程绑定”，ExecutorService 提交的任务默认在工作线程执行，回调也一样。UI 更新、日志记录、数据库写入这些操作对线程有要求，不处理就会崩或静默失败。
典型错误：Swing 中在 ScheduledThreadPoolExecutor 里调用 label.setText() → 抛 IllegalStateException: not dispatch thread。
- Android 使用
Handler(Looper.getMainLooper())或runOnUiThread() - Swing 用
SwingUtilities.invokeLater()，别用invokeAndWait()（易死锁） - 纯 Java 后端服务，如果回调要写 DB，确认数据源连接是否支持多线程（如 HikariCP 可以，但单例
Connection不行） - CompletableFuture 的
thenAcceptAsync()默认用 ForkJoinPool，如需指定线程池，第二个参数传executor
用 CompletableFuture 替代手写回调的取舍
不是所有场景都该升级。CompletableFuture 解决的是“回调地狱”和组合逻辑，但引入了额外抽象层，调试难度上升，堆栈更难读。
适用场景：多个异步任务需串行、并行、任一完成即响应、失败重试等；不适用：简单通知（如“保存完了”）、低延迟敏感模块（如高频交易中间件）。
-
supplyAsync(() -> doWork(), executor)才真正启用自定义线程池，光写supplyAsync(() -> doWork())会挤占ForkJoinPool.commonPool() - 链式调用中，
thenApply()在前一个阶段完成线程上执行，thenApplyAsync()才换线程 —— 很多人混淆这点导致线程阻塞 - 不要在
whenComplete()或handle()里抛异常，它不会中断链路，要用exceptionally()或handle()显式返回
复杂点不在语法，而在谁负责清理资源、谁控制超时、回调失败后要不要重试——这些从来不会由接口或 CompletableFuture 自动帮你决定。
