使用场景（大量短小）

• 每次任务执行时间较短
• 数据量大

为什么要用

• 减少创建和摧毁线程时在时间和资源上的浪费
• 创建太多线程容易造成内存不足，以及过度切换
  大多数服务器应用程序都是面向处理大量的短期任务或子任务，因此往往希望具有一种能够以低开销有效地处理这些任务的机制以及一些资源管理和定时可预见性的措施。线程池提供了这些优点

可能会有啥问题

• 线程泄漏。
  • 当执行任务时抛出RuntimeException或error，而池类没有捕捉到他们，那么该线程就不能再用了。意味着该线程池的大小-1，如果频繁出现，线程池最终会为空，导致系统停止（因为没有线程可用）
  • 当比如一个线程是用来等待资源或监听用户输入，而资源可能一直不可用，又或者用户走了（并没有继续输入），那么这个线程就会一直被消耗着（也可能理解为被阻塞？）。解决方案：可以考虑创建属于自己的线程，或者设计超时时间（超过一定时间自动回收）。
• 请求过载
  • 因为线程池线程数量有限，所以大量的任务才是需要排队到队列去等待，这样也会消耗太多的系统资源。解决方案可能快速失败，就是筛选掉一部分先。

有哪几种

• newFixedThreadPool

  • 常用
  • 创建指定大小的线程池，有一个任务创建一个线程
  • 但线程数大于最大值时，则将新提交的任务放到池队列中（可以理解为阻塞）

• newCachedThreadPool

  • 可缓存线程池，灵活
  • 原则上可无限创建线程，如果某个线程长时间（默认60s）没用，就自动终止该线程
  • 所以长时间闲置，并不会耗费啥资源（会自动终止），背后是SynchronousQueue做工作队列

• newSingleThreadExecutor

  • 单线程
  • 只创建一条线程，保证顺序执行
  • 如果异常结束，就会创建一条新的

• newScheduleThreadPool

  • 定长、定时、周期性（类似Timer）

https://www.jianshu.com/p/18b39a5f1868
https://www.cnblogs.com/gujiande/p/9488462.html
https://www.cnblogs.com/aaron911/p/6213808.html