callable任务与工作线程生命周期相互独立：任务经历待提交、队列等待、执行中、完成四阶段，由future封装结果；工作线程被线程池复用，可执行多个任务或超时回收；future实现调用方与执行细节解耦。
Callable任务的生命周期和线程池中工作线程的生命周期是彼此独立的，这种分离正是Executor框架设计的核心目标之一。
Callable任务自身的生命周期
一个Callable实例从创建到结果获取，经历的是纯逻辑状态流转，不绑定具体线程：
- 提交前：仅是一个普通对象，尚未被调度，处于“待提交”状态
-
提交后：调用
executor.submit(callable)，返回一个Future，此时任务进入线程池内部队列（如BlockingQueue），等待被取走执行 -
执行中：某个工作线程从队列取出该任务，调用其
call()方法——但任务本身并不“知道”是谁在执行它 -
完成时：
call()正常返回或抛出异常，Future内部状态变为isDone() == true，结果或异常被缓存，后续调用get()即可获取
工作线程的生命周期由线程池统一管理
ThreadPoolExecutor中的工作线程（Worker）是复用的，与任务一一对应关系被打破：
- 线程启动后会持续循环：从任务队列中
take()或poll()新任务，执行完再取下一个 - 一个线程可能先后执行多个Callable任务，也可能在空闲超时后被回收（取决于
allowCoreThreadTimeOut等配置） - 线程的创建、销毁、阻塞、唤醒完全由线程池控制，与某个Callable是否提交、是否完成无直接关联
解耦的关键机制：Future作为中间桥梁
Future接口屏蔽了执行细节，让调用方只关心“结果何时可用”，而不是“谁在跑、在哪跑”：
- 提交Callable后立即获得Future，主线程可继续做其他事，无需等待
- Future的
get()阻塞的是调用线程，不是工作线程；工作线程执行完就去拿下一个任务 - 即使工作线程因异常终止，只要任务已开始执行，其返回值或异常仍会写入Future，不会丢失
- 可对Future调用
cancel(true)尝试中断正在执行的任务，但中断是否生效取决于call()内部是否响应中断（如检查Thread.interrupted()）
典型场景说明
比如提交3个耗时不同的Callable任务到固定大小为2的线程池：
- 前两个任务立刻被两个工作线程取走并发执行
- 第三个任务在队列中等待，直到任一工作线程空闲
- 主线程在提交后立刻拿到3个Future，可按需调用
get()——哪个先完成就先返回，顺序不固定 - 整个过程里，任务的“存在”和线程的“存活”完全正交：任务早完成，线程还在；线程回收了，Future仍持有结果
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
