线程饥饿源于线程池资源被长期占满而非频繁创建销毁，典型原因是嵌套提交+同步等待导致“自己等自己”；应隔离父子任务、禁用同步等待、选用有界队列、设超时与中断机制、必要时采用工作窃取池。
线程饥饿不是由“频繁创建销毁线程”直接引发的，而是因线程池资源被长期占满、任务无法获得执行机会所导致。所谓“频繁创建销毁”，其实是线程池配置失当（如 maximumPoolSize 过大 + 无界队列）或任务逻辑缺陷（如同步等待阻塞）的表象，其背后真正造成饥饿的是线程被无效占用、无法释放、新任务持续堆积。
避免线程被永久占用（尤其在嵌套提交场景）
最典型的饥饿根源是：一个任务在池中执行时，又向同一个线程池提交子任务，并同步等待（如 Future.get() 或 CompletableFuture.join()）。这会导致所有线程陷入“自己等自己”的死循环。
- 把父子任务拆到隔离的线程池：I/O 密集型子任务用专用池（如 8 核配 16–32 线程），CPU 密集型主任务用小核心池（如 4–8 线程）
- 禁用同步等待：用
thenApply、thenCompose等异步链式操作替代get()；若必须等待，改用CompletableFuture.anyOf或超时控制 - 示例错误写法（饥饿温床）：
pool.submit(() -> {<br> Future<?> f = pool.submit(() -> doIO());<br> f.get(); // 卡住当前线程，等待另一个池中线程 —— 但那个线程可能正卡在同样逻辑里<br>});
选对队列类型，防止任务无限堆积
使用 LinkedBlockingQueue（尤其无界）会让任务看似“不丢”，实则掩盖容量瓶颈——线程数卡在 corePoolSize，大量任务排队，低优先级或后提交的任务永远轮不到执行。
- 生产环境一律用有界队列，如
ArrayBlockingQueue(200)，配合明确拒绝策略 - 拒绝策略别用
AbortPolicy（抛异常难监控）或CallerRunsPolicy（可能拖垮 Web 容器主线程）；推荐DiscardOldestPolicy或自定义日志+告警策略 - 队列容量需结合平均任务耗时与吞吐目标估算：比如单任务平均 200ms，期望每秒处理 50 个，则队列至少预留 10 个槽位缓冲突发
控制单任务执行时间，防止单线程霸占
一个长任务（如死循环、未设超时的网络调用）会独占线程数天，让其他任务彻底“饿死”。
立即学习“Java免费学习笔记（深入）”；
- 所有外部调用必须设超时：
HttpClient配connectTimeout和readTimeout；数据库连接配queryTimeout - 计算密集型任务主动分片，加入
Thread.interrupted()检查点，支持中断退出 - 避免在池中线程里调用
Thread.sleep(Long.MAX_VALUE)或空 while 循环；真需延时，用ScheduledExecutorService
用工作窃取池处理短任务洪峰
当业务以大量轻量、独立、可分割任务为主（如消息解析、字段校验），传统固定池容易因负载不均导致部分线程忙、部分空闲，间接加剧某些任务延迟。
- 改用
Executors.newWorkStealingPool()，底层基于ForkJoinPool，空闲线程自动从其他队列“偷”任务 - 适合场景：批处理、流式数据清洗、树形结构遍历；不适合需强顺序或长阻塞操作的任务
- 注意：它不保证任务提交顺序，也不支持自定义拒绝策略，需评估业务容忍度
