结论：runnable 和 callable 在纯任务调度执行层面无性能差异；区别在于语义——runnable 无返回、不抛受检异常，callable 有泛型返回值且可抛 exception；性能瓶颈主要来自 future.get() 阻塞等待，而非接口本身。
直接说结论：在纯任务调度和执行层面，Runnable 和 Callable 本身没有性能差异。它们的开销几乎可以忽略不计，真正影响性能的是后续使用方式（比如是否用 Future.get() 阻塞等待、是否启用线程池、是否频繁创建 FutureTask 等）。
核心区别不在性能，而在语义和使用路径
Runnable.run() 是 void 方法，无返回、不抛受检异常；Callable.call() 有泛型返回值、可抛 Exception。这个设计差异决定了它们的使用场景，而不是运行快慢。
- Runnable 可直接传给 Thread 构造器或线程池 execute()
- Callable 不能直接交给 Thread，必须包装成 FutureTask，或提交给线程池的 submit() 方法
- submit(Callable) 内部仍会把 Callable 封装为 FutureTask，再调度——这一步多一次对象创建，但成本极低（纳秒级）
真实瓶颈通常出现在结果获取环节
如果你写代码时频繁调用 Future.get()，尤其是未设超时、且任务尚未完成就立即 get，主线程就会阻塞。这种“等待”带来的延迟远大于接口本身的开销。
- Runnable 任务：无返回，启动即“甩手”，无同步等待成本
- Callable 任务：若调用 get() 获取结果，会触发同步等待 —— 这是性能落差的主因，不是 call() 方法慢，而是你在等它
- 优化建议：用 isDone() 轮询、get(100, TimeUnit.MILLISECONDS) 设超时、或用 CompletableFuture 异步编排，避免阻塞
线程池场景下，差异进一步收窄
现代应用基本都用 ExecutorService。在 fixedThreadPool 中：
- execute(Runnable) 和 submit(Runnable) 底层调度逻辑一致，仅任务封装略有不同
- submit(Callable) 会额外创建一个 FutureTask 实例，但该对象轻量（无锁、无复杂状态），实测 10 万次创建耗时约 0.5ms
- 真正影响吞吐的是任务体逻辑（比如 IO、计算）、线程竞争、队列长度，而非 Runnable/Callable 的选择
微基准测试的关键控制点
如果真要做微观对比（例如 JMH 测试），必须隔离变量：
- 确保两个任务体逻辑完全一致（比如都只做 100 次空循环 + System.nanoTime() 记录）
- 禁用 Future.get()，否则测的是“等待时间”而非“执行时间”
- 复用线程池，避免反复创建销毁开销
- 预热足够轮次（如 10_000 次），排除 JIT 编译干扰
实测典型结果：单任务平均执行时间差异在 ±2ns 范围内，属于测量噪声级别。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
