ThreadPoolExecutor的核心参数是什么

“小镇线程池”的故事

3.ThreadPoolExecutor的核心参数是什么？
核心线程数（corePoolSize）：池中保持的最小线程数。
最大线程数（maximumPoolSize）：池中最大允许的线程数。
队列（BlockingQueue）：等待执行的任务队列。
线程空闲时间（keepAliveTime）：当线程数大于核心线程数时，多余的线程在空闲指定时间后被销毁。
拒绝策略（RejectedExecutionHandler）：当队列满并且线程数达到最大线程数时，用于处理新任务的策略。 编一个故事快速记住上面的核心参数
在一个小
镇里，有一个叫**“线程池”**的建筑公司，这家公司负责镇上所有的建筑任务。公司有几个核心角色，分别对应着公司运行的关键参数。

---

1. 核心工人队（corePoolSize）

线程池公司有一支固定的建筑队伍，叫做核心工人队。无论任务多忙少，这些核心工人都一直在工作。这就是公司最基础的工人队伍，人数固定，对应的是核心线程数（corePoolSize）。

2. 临时工人队（maximumPoolSize）

当建筑任务非常繁忙时，核心工人队人手不够，公司就会从外面雇佣一些临时工来帮忙。这些临时工人只能在任务多的时候加入，最多只能雇佣到一个上限值（不能超过这个数目）。这个上限值就是公司的最大工人数（maximumPoolSize），对应最大线程数。

3. 待建工地（BlockingQueue）

小镇上的建筑任务如果来得太快，而公司手头工人都在忙，就只能把这些任务暂时放在待建工地里排队。一旦有工人空闲下来，就会从待建工地里取出任务，立即开工。这块待建工地就是公司的任务队列（BlockingQueue）。

4. 等待时限（keepAliveTime）

对于那些临时工，公司有一个规定：如果有一段时间没有新的任务分配给他们，而他们又不是核心工人，那么他们就会被遣散回家。这个等待的时间就是等待时限（keepAliveTime），对应的是线程空闲时间。

5. 拒单策略（RejectedExecutionHandler）

有一天，任务实在是太多，工人们和待建工地都被任务塞满了，再也容不下新的任务。这时候，公司就要决定怎么处理这些额外的任务。有时候，公司会直接拒绝这些任务，有时候会把任务交给其它地方的工人去做。这种应对方式就是公司的拒单策略（RejectedExecutionHandler），对应的是拒绝策略。

---

通过这个“小镇线程池”的故事，可以轻松记住ThreadPoolExecutor的核心参数：

• 核心工人队 → 核心线程数（corePoolSize）
• 临时工人队 → 最大线程数（maximumPoolSize）
• 待建工地 → 任务队列（BlockingQueue）
• 等待时限 → 线程空闲时间（keepAliveTime）
• 拒单策略 → 拒绝策略（RejectedExecutionHandler）

记住这个故事，线程池的参数你就能牢牢掌握了！

“线程城堡”的故事

在一个叫线程城堡的小镇上，镇民们通过一个精密的机制来完成各种各样的任务。这个机制就是线程城堡里的任务管理系统，它有一套清晰的工作原理，让所有的任务都能顺利完成。

---

1. 城堡的守卫（核心线程）

线程城堡里有一队最忠诚的守卫，他们一直在保护城堡。这些守卫数量有限，但他们非常勤奋。每当有任务进城，如果城堡里的守卫人数还没有达到规定的最低数量（核心线程数），新的守卫就会立即上岗来处理任务。这就是第一层防御——守卫总是优先处理任务。

2. 城堡的任务广场（任务队列）

当镇上的任务多到需要额外帮助，而所有的守卫都已经忙得不可开交时，这些任务就会被集中在城堡的任务广场上排队等待。任务广场相当于任务队列，所有到达的任务都会按顺序排列，等待有空闲的守卫来处理。

3. 临时守卫的召唤（最大线程）

然而，有时候任务来得太快，任务广场上排满了任务，守卫们处理不过来。如果守卫人数还没达到最高限额（最大线程数），城堡会召唤更多的临时守卫来帮忙处理这些排队的任务。这些临时守卫一旦上岗，就会快速投入工作。

4. 任务洪水（队列已满）

但是，任务量有时候超乎想象。任务广场挤满了排队的任务，甚至连城堡里的所有守卫都用尽了，这时候再也无法添加新的守卫。面对这种情况，城堡必须采取最后的措施——根据镇长（拒绝策略）的命令，决定如何处理这些无法接纳的新任务。镇长可能会拒绝任务、推迟任务，或者让其他城镇来帮忙。

---

快速记忆“线程城堡”的工作原理

1. 守卫不足时，招募新守卫（线程数少于核心线程数 → 创建新线程执行任务）。
2. 守卫满员时，任务排队等待（线程数达到核心线程数 → 任务放入队列）。
3. 任务排不下时，召唤更多临时守卫（队列已满，线程数未达最大 → 创建新线程执行任务）。
4. 一切都满员时，镇长决定任务命运（队列满，线程数达最大 → 根据拒绝策略处理任务）。

通过这个故事，可以形象地理解线程池的工作原理，把复杂的概念变得生动易记。

5.线程池的拒绝策略有哪些？
AbortPolicy（默认）：抛出RejectedExecutionException异常，表示拒绝执行任务。
CallerRunsPolicy：由调用线程执行被拒绝的任务。
DiscardPolicy：静默丢弃被拒绝的任务。
DiscardOldestPolicy：丢弃队列中等待时间最长的任务，然后重新尝试执行新任务。编一个故事快速记住上面的拒绝策略

“任务之王”的抉择

在一个繁忙的任务王国里，任务多如牛毛，城堡的线程守卫们忙得不可开交。当任务实在是太多，王国的拒绝策略必须出马，来决定如何处理那些超出负荷的任务。拒绝策略有四位，他们各自有不同的处理方式。

---

1. 暴躁的“阿博特王”（AbortPolicy）

“阿博特王”是任务王国中最严厉的王。每当有任务超出了王国的承受范围，他就大发雷霆，直接把任务赶出去，甚至抛出一块重重的“异常石”，表示这个任务被彻底拒绝了。这种做法对应的是AbortPolicy，它会抛出RejectedExecutionException异常，告诉你这个任务没法执行。

2. 勤劳的“卡勒尔王”（CallerRunsPolicy）

“卡勒尔王”是王国中最勤奋的王。他看到有任务无法处理，就会亲自卷起袖子，自己去做那些被拒绝的任务。这种做法对应的是CallerRunsPolicy，即由调用线程来执行被拒绝的任务。

3. 冷漠的“迪斯卡王”（DiscardPolicy）

“迪斯卡王”是个冷漠的王，他对多余的任务毫不在意。当有任务无法处理时，他就会默默地将任务扔掉，仿佛什么也没发生过。这种策略对应的是DiscardPolicy，直接丢弃被拒绝的任务，没有任何通知。

4. 智慧的“迪斯卡德·奥尔德王”（DiscardOldestPolicy）

“迪斯卡德·奥尔德王”是个聪明的王，他不忍心让所有任务都白费。当队列已经满了，他会回顾队列中的任务，找到那个等待最久的任务，将它优雅地请出去，然后再试着让新任务进来。这种做法对应的是DiscardOldestPolicy，它会丢弃队列中等待时间最长的任务，然后重新尝试执行新任务。

---

快速记忆“任务之王”的拒绝策略

1. 阿博特王：怒斥任务 → AbortPolicy（抛异常，拒绝执行）。
2. 卡勒尔王：亲自上阵 → CallerRunsPolicy（调用线程执行任务）。
3. 迪斯卡王：冷漠扔掉 → DiscardPolicy（静默丢弃任务）。
4. 迪斯卡德·奥尔德王：替换老臣 → DiscardOldestPolicy（丢弃最老的任务）。

通过这个“任务之王”的故事，可以轻松记住线程池的四种拒绝策略及其对应的处理方式。