Runnable接口的run()方法无返回值且无参数，仅定义任务执行动作，不承担结果传递职责；其设计旨在保持接口极简、语义统一，并与Thread启动机制兼容，需返回值时应使用Callable。
因为Runnable接口的设计目标是封装“可执行的任务”，而不是“可计算的函数”。它关注的是动作的发起与执行，不承担结果传递的职责。
定位清晰：任务执行 ≠ 结果返回
Runnable最早出现在JDK 1.0，当时线程模型非常基础。它的核心语义是“让这个对象能被线程调用一次”，重点在触发行为，比如启动日志写入、刷新UI、发送心跳包——这些操作本身不需要向调用方反馈值。若强制要求返回值，反而会让简单场景变得冗余。
- 接口极简：仅一个
void run()，降低实现门槛 - 语义一致：和Thread类的run()方法签名对齐，保持统一抽象
- 避免误用：防止开发者误以为“调用run()就能拿到结果”，而实际上run()只是同步执行，不等同于start()
技术约束：与线程启动机制深度绑定
Thread构造器只接受Runnable，且start()内部调用的是无参无返回的run()。如果run()有返回值，就必须修改Thread类的底层调用逻辑——这会破坏所有已有代码的兼容性，也违背Java“稳定优先”的演进原则。
- Thread对象无法接收或传递返回值，没有上下文存储位置
- run()是被JVM在线程栈中直接调用的，没有调用方栈帧来承接返回值
- 若支持返回值，还需配套定义“谁来取”“何时取”“超时怎么处理”，远超接口本意
替代方案早已就位：需要结果就换Callable
Java 5引入Callable正是为弥补这一空白。它和Runnable分工明确：Runnable负责“做”，Callable负责“算”。当你需要返回值或抛出检查异常，直接用Callable + ExecutorService + Future，这套组合已成标准实践。
立即学习“Java免费学习笔记（深入）”；
- Callable.call()返回泛型结果，异常可向上抛出
- Future.get()同步获取结果或异常（包装为ExecutionException）
- 不破坏原有设计：Runnable继续轻量可靠，Callable专注增强能力
不是不能，而是不必。把责任分清，才让多线程编程既灵活又可控。
