callable 接口通过返回值和异常传播能力，结合 future 实现端到端耗时统计（含排队+执行），支持分段计时、线程池复用及任务类型差异化监控。
Callable 接口本身不直接“优化”耗时统计，但它提供了返回值和异常传播能力，配合 Future 机制，让耗时统计更准确、更可控——尤其适合统计异步任务的端到端耗时（含排队+执行）和各子任务独立耗时。
用 Callable + Future 获取单个任务端到端耗时
主线程调用 submit() 后立刻记录开始时间，get() 返回时记录结束时间，差值即为该任务从提交到完成的总耗时（含线程池排队等待时间）。
- 比在子线程内部测“纯执行时间”更能反映真实用户体验
- 无需手动同步或共享变量，天然线程安全
- 适用于接口响应级监控，比如统计某次批量查询整体耗时
封装 ScopedCallable 实现子任务分段计时
通过包装 Callable，自动记录 submitTime（提交时刻）、startTime（真正开始执行时刻）、endTime（执行结束时刻），可拆解出“排队时长”和“执行时长”：
- 排队时长 = startTime − submitTime
- 执行时长 = endTime − startTime
- 总耗时 = endTime − submitTime
- 适合排查线程池过载、任务积压问题
结合线程池统一管理，避免裸线程开销
不用 new Thread() 手动启线程，而是用 ExecutorService 提交 Callable 任务：
- 复用线程，减少创建/销毁开销
- 便于控制并发数，防止资源耗尽
- Future 列表可批量 get()，自然阻塞并捕获各任务完成时间
- 配合 CountDownLatch 或 CompletableFuture 可实现更灵活的等待策略
按任务类型配置线程池，让耗时统计更有意义
耗时数字本身没价值，关键看它背后反映的问题。统计前先判断任务性质：
- CPU 密集型（如解析、计算）：线程数 ≈ CPU 核数，耗时高往往意味着算法瓶颈
- IO 密集型（如查库、调接口）：线程数可适当放大，耗时高大概率是外部依赖慢
- 混合型：建议拆成两阶段（如 CompletableFuture 异步拉数据 + 小线程池做计算），再分别统计
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
