该答案假设您的任务很短
这样的模式是否比在代码中创建新的线程更好？
更好，但仍远非理想。您 仍在为短期任务创建线程 。相反，您只需要创建其他类型的线程池-例如by
Executors.newScheduledThreadPool(int corePoolSize)。
行为上有什么区别？
- A
FixedThreadPool
将始终具有一组要使用的线程，并且如果所有线程都忙，则将新任务放入队列。 ScheduledThreadPool
由Executors
类创建的（默认）（即使空闲）具有 最小的 线程池。如果有新任务出现时所有线程都忙， 它将为它创建一个新线程 ，并在完成后60秒钟处理该线程，除非再次需要它。
第二个可以让您不要自己创建新线程。无需“预定”部分就可以实现此行为，但是您将不得不自己构造执行程序。构造函数是
public ThreadPoolExecutor(int corePoolSize, int maximumPoolSize, long keepAliveTime, TimeUnit unit, BlockingQueue<Runnable> workQueue)
各种选项使您可以微调行为。
如果有些任务很长…
我的意思是很长。与您的应用程序生命周期中的大部分时间一样（实时2路连接？服务器端口？多播侦听器？）。在这种情况下，将您
Runnable的遗嘱执行人置于不利地位–标准的遗嘱执行人
并非 旨在应对这种情况，它们的性能将下降。
考虑一下您的固定线程池-如果您有5个长时间运行的任务，那么任何新任务都会产生一个新线程，从而完全破坏该池的所有可能收益。如果您使用更灵活的执行程序-
一些线程将被共享，但并非总是如此。
经验法则是
- 如果 任务 很 短 ，请使用执行程序。
- 如果 任务很长，请 确保您的执行程序可以处理它（即，它没有最大的池大小，或者没有足够的最大线程来处理多一个线程一段时间）
- 如果这是一个需要始终与主线程一起运行的并行进程，请使用另一个线程。
