一个激进创建线程的弹性线程池更符合我们的需求，你能给出相关的实现吗？实现后再测试一下，是否所有的任务都可以正常处理完成呢？

  • 既然选择先扩容线程池再加入队列，那为什么不干脆把核心线程数设置大一些，然后核心线程数可回收这种策略呢？
    其实我们希望尽量确保有足够多线程能处理任务，但又不闲置过多线程，或临时创建过多线程，换句话说让线程的创建和回收不要太频繁。选择哪个策略要根据任务的性质和压力的流量形态来决定。

  • 复用线程池，任务很慢，主线程get结果的时候不会导致主线程卡死的状态吗？不是也提倡不同的任务用不同的线程池，那复用与不复用的边界在哪里呢？是要根据业务需求自己评估吗？
    复用线程池是指不每次都创建线程池，线程池必须复用而不是按需创建，但不推荐一味混用一个线程池。对于选择是否混用线程池，至少对于频+快的任务和少+慢的任务应该分开，还是要根据实际任务的性质来选择

如果我们不小心每次都创建了这样一个自定义的线程池（10核心线程，50最大线程，2秒回收），反复执行测试接口线程，最终可以被回收吗？会出现OOM吗？

ThreadPoolExecutor回收不了，可以看看其源码，工作线程Worker是内部类，只要它活着，换句话说线程在跑，就会阻止ThreadPoolExecutor回收，所以其实ThreadPoolExecutor是无法回收的，并不能认为ThreadPoolExecutor没有引用就能回收

我觉得不会被回收且很快就会OOM了，因为每次请求都新建线程池，每个线程池的核心数都是10, 虽然自定义线程池设置2秒回收，但是没超过线程池核心数10是不会被回收的, 不间断的请求过来导致创建大量线程，最终OOM。
Exception in thread “main” java.lang.OutOfMemoryError: unable to create new native thread

  • https://stackoverflow.com/questions/19528304/how-to-get-the-threadpoolexecutor-to-increase-threads-to-max-before-queueing