绝大多数场景下，用 Runnable 更常用；因其解耦任务逻辑与线程生命周期，利于复用、测试和资源管理，且适配线程池和 lambda，而 new Thread 易导致重复启动异常、误调 run() 同步执行等问题。
new Thread() 和实现 Runnable 哪个更常用？
绝大多数场景下，用 Runnable 更合理。直接 new Thread 本质是把任务逻辑和线程生命周期耦合在一起，不利于复用、测试和资源管理。
常见错误现象：Thread 对象重复 start 报 IllegalThreadStateException；或者误以为多次调用 run() 就等于多线程——其实只是在当前线程同步执行。
- 使用场景：需要提交任务给线程池（比如
ExecutorService.submit()）时，只能传Runnable或Callable，不能传Thread - 参数差异：
Thread构造器能接收Runnable，但反过来不行；Runnable是函数式接口，适合 lambda 表达式 - 性能影响：new
Thread每次都新建线程，开销大；而Runnable实例轻量，可复用
为什么 Callable 比 Runnable 多一个返回值，却不能直接 new Thread(Callable)
因为 Thread 的构造器只接受 Runnable，不接受 Callable。这是设计层面的隔离：Thread 只负责执行，不负责结果获取；而 Callable 的核心价值在于配合 Future 异步取结果。
常见错误现象：写 new Thread(() -> { return "done"; }) 编译失败——lambda 无法匹配 Runnable 的 void run()，也不能自动适配 Callable。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 使用场景：需要线程执行后返回计算结果，且可能抛出受检异常（
Runnable.run()不能 throws 任何 checked exception） - 正确做法：用
ExecutorService.submit()提交Callable，返回Future；再调用future.get()获取结果 - 兼容性影响：JDK 5 引入
Callable，老项目若未升级并发工具类，可能没用过它
Runnable 和 Callable 的 run() / call() 方法，能 throw Exception 吗？
Runnable.run() 不能声明抛出任何受检异常（checked exception），只能吞掉或包装成运行时异常；Callable.call() 可以直接 throws Exception，包括 IOException、SQLException 等。
常见错误现象：在 Runnable 里写 FileReader fr = new FileReader("x.txt"); 编译报错，提示“unreported exception”，不得不加 try-catch 包一层。
- 使用场景：IO、数据库操作等天然带 checked exception 的逻辑，用
Callable更自然 - 性能影响：无实质差异；但
Callable配合Future.get()会阻塞，需注意超时设置（future.get(3, TimeUnit.SECONDS)） - 容易踩的坑：忽略
Future.get()的中断响应——如果线程被 interrupt，get()会抛InterruptedException，不处理会导致上层逻辑静默失败
Thread、Runnable、Callable 在线程池里的实际地位
线程池（ExecutorService）只认 Runnable 和 Callable；Thread 在这里完全是个“局外人”。你传进去的 Thread 实例，会被当作普通 Runnable 执行它的 run() 方法——也就是启动它自己，造成嵌套线程，极难调试。
常见错误现象：向 executor.submit(new Thread(() -> {...})) 提交任务，日志里看到线程名类似 pool-1-thread-1 再起一个 Thread-2，资源失控。
- 正确姿势：
executor.execute(runnable)或executor.submit(callable) - 参数差异：submit 返回
Future，execute 不返回；若不需要结果，用 execute 更轻量 - 容易被忽略的点：即使你只用
Runnable，只要交给线程池，就已脱离 “手动管理线程” 的范畴——此时Thread类本身基本只用于定制线程工厂（ThreadFactory）或诊断线程状态
