线程饥饿（Thread Starvation） 是指某个或某些线程因为长期无法获得所需的资源（最常见的是 CPU 时间或锁），导致其任务迟迟不能执行或进展极其缓慢的现象。
你可以把它想象成：一群人排队吃饭，但总有“特权人士”不断插队，导致排在后面的人一直吃不上饭——这就叫“饥饿”。
一、线程饥饿的核心含义
不是死锁：死锁是多个线程互相等待，谁都动不了。不是阻塞：阻塞是暂时的，比如等 I/O、等锁。饥饿是“长期等不到”：线程一直“就绪”，但就是轮不到它运行。
二、导致线程饥饿的常见原因
1. 非公平锁的竞争
比如使用 ReentrantLock(false)（非公平锁）时：
多个线程竞争同一个锁。即使有线程已经在等待队列中，新来的线程也可能“插队”成功。如果新线程源源不断到来，老的等待线程可能永远抢不到锁，导致其任务无法执行。
✅ 示例：
线程 A、B、C 在排队等锁，D、E、F 不断新来并抢到锁 → A 可能一直等不到。
2. 高优先级线程抢占 CPU
在支持线程优先级的系统中（Java 的 setPriority()）：
高优先级线程总是优先获得 CPU 时间片。如果一直有高优先级线程在运行，低优先级线程就可能几乎得不到 CPU 时间。
⚠️ 注意：Java 的线程优先级依赖于操作系统，效果不保证。
3. 资源被长期占用
某个线程长时间持有锁（如执行耗时操作）。其他线程只能干等，尤其是当这个线程频繁重入或重复获取锁时。
4. 线程池配置不合理
线程池太小，任务太多。某些任务执行时间很长，导致其他任务排队太久。或者使用了无界队列，前面的任务迟迟不完成，后面的任务“饿着”。
三、线程饥饿的表现
某些任务响应极慢，甚至“卡住”。日志中发现某些线程长时间处于 RUNNABLE 或 BLOCKED 状态但无进展。系统吞吐量下降，部分功能不可用。监控发现某些线程的 CPU 时间占比极低。
四、如何缓解或避免线程饥饿？
问题原因解决方案非公平锁导致抢不到使用公平锁（ReentrantLock(true)），但注意性能下降高优先级线程霸占 CPU合理设置线程优先级，避免滥用锁持有时间过长缩短临界区，避免在锁内做耗时操作（如 I/O、sleep）线程池不合理合理配置线程池大小、队列类型（如有界队列）、拒绝策略任务不均衡拆分长任务，使用异步处理，避免一个线程独占资源
五、举个生活化的例子 🍜
想象一家只有一口锅的面馆：
顾客（线程）来了要煮面（获取锁）。如果允许“插队”（非公平），新来的顾客可能比等了很久的人先煮上。如果不断有新顾客插队，最早来的那个人可能一直吃不上面——这就是“线程饥饿”。
如果改成“先来先煮”（公平锁），虽然每个人都能吃上，但整体效率可能变低（锅空着也要等前面的人来）。
✅ 总结
线程饥饿 = 长期得不到资源 → 任务无法执行
常见于：非公平锁、高优先级线程、资源竞争激烈、线程池不合理。不像死锁那样“死掉”，而是“活不好”。解决思路：保证资源分配的公平性 + 合理设计并发模型。
💡 在实际开发中，要平衡“性能”和“公平”。大多数情况下，非公平锁 + 合理的任务设计，比完全公平更高效。
线程池在设计或使用不当时，确实可能引发线程饥饿（Thread Starvation），即某些任务长期得不到执行机会，一直处于等待状态。
下面我们来详细分析 线程池是如何引发线程饥饿的，包括原因、场景和解决方案。
一、什么是线程饥饿（回顾）
线程饥饿：指某些线程（或任务）因为长期无法获得所需的资源（如 CPU 时间、线程执行权），导致其任务迟迟不能执行。
在线程池的上下文中，"线程饥饿"通常表现为：某些提交到线程池的任务长时间得不到执行，甚至永远不被执行。
二、线程池引发线程饥饿的常见原因
1. 核心线程数设置过小 + 任务执行时间过长
场景：
线程池核心线程数 = 2提交了大量耗时任务（如 I/O、计算密集型）所有核心线程都被占满，且任务执行很慢
结果：
新任务只能排队，无法立即执行。如果任务持续提交，队列越来越长，后面的任务等待时间极长 → 饥饿
✅ 类比：只有 2 个服务员，但每桌客人吃饭要 1 小时，新客人只能排队，排在后面的等得“饿死了”。
2. 使用了无界队列（Unbounded Queue）
常见错误代码：
ExecutorService executor = new ThreadPoolExecutor(
2, 10,
60, TimeUnit.SECONDS,
new LinkedBlockingQueue<>() // 无界队列！
);
问题：
LinkedBlockingQueue 默认容量是 Integer.MAX_VALUE，几乎是无限的。任务不断提交，队列无限增长。前面的任务没执行完，后面的任务永远等不到机会 → 饥饿
⚠️ 这是 最常见 的线程饥饿原因，还可能引发 OOM（OutOfMemoryError）。
3. 线程池拒绝策略不当
当线程池满载（核心线程满 + 队列满 + 最大线程满），新任务会被拒绝。
默认拒绝策略是 AbortPolicy，直接抛出 RejectedExecutionException。
但如果使用了 CallerRunsPolicy：
new ThreadPoolExecutor.CallerRunsPolicy()
问题：
当线程池忙时，新任务由提交任务的线程（通常是主线程）直接执行。如果主线程也持续提交任务，它就会被“卡住”去执行任务，无法继续提交后续任务。导致系统响应变慢，间接造成其他任务“饥饿”。
4. 长任务阻塞线程池中的线程
场景：
线程池中混入了长时间运行的任务（如：死循环、大计算、慢 SQL）。这些任务占用了线程池中的线程，且迟迟不释放。
结果：
其他短任务无法获得线程执行，只能等待 → 短任务饥饿
✅ 类比：高速公路上一辆车抛锚了，后面的小车都被堵住。
5. 线程池配置不合理（核心线程数为 0）
new ThreadPoolExecutor(
0, 10, // 核心线程数为 0
60, TimeUnit.SECONDS,
new SynchronousQueue<>()
);
这种配置下，只有当有空闲线程时，任务才能执行。如果所有线程都在忙，新任务可能被拒绝或无法入队。特别是在高并发场景下，任务容易“丢失”或“饥饿”。
三、如何避免线程池引发的线程饥饿？
问题原因解决方案核心线程数太小合理设置核心线程数（如 CPU 密集型：N，I/O 密集型：2N~4N）使用无界队列改用有界队列（如 new LinkedBlockingQueue<>(100)）任务执行时间过长拆分长任务，使用异步、超时机制（Future.get(timeout)）拒绝策略不当使用合适的拒绝策略，如 AbortPolicy + 降级处理，或自定义策略混合任务类型使用多个线程池隔离不同类型任务（如：IO 任务 vs 计算任务）无监控增加线程池监控（如：队列长度、活跃线程数、任务耗时）
四、最佳实践建议
✅ 推荐的线程池配置示例：
ExecutorService executor = new ThreadPoolExecutor(
4, // 核心线程数
16, // 最大线程数
60, TimeUnit.SECONDS, // 空闲线程存活时间
new LinkedBlockingQueue<>(100), // 有界队列
new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略
);
✅ 使用多个线程池隔离任务：
// 专门处理 I/O 任务
ExecutorService ioPool = ...
// 专门处理计算任务
ExecutorService computePool = ...
// 避免互相影响
✅ 使用 CompletableFuture + 自定义线程池：
CompletableFuture.supplyAsync(() -> {
// 耗时操作
}, ioPool);
✅ 总结
线程池引发线程饥饿的主要原因：
原因后果解决方案核心线程太少任务排队太久合理设置线程数无界队列队列无限增长，OOM改用有界队列长任务占用线程短任务等不到执行任务拆分、超时控制拒绝策略不当主线程被阻塞使用合适的拒绝策略任务类型混杂相互影响多线程池隔离
💡 核心思想：
线程池不是“越大越好”或“队列越长越好”，而是要合理配置、有界控制、任务隔离，才能避免线程饥饿，保证系统稳定性和响应性。