如程序执行结果中显示的一样，任务 4 或任务 5 仅在池中的线程变为空闲时才执行。在此之前，额外的任务将放在待执行的队列中。
线程池执行前三个任务，线程池内线程回收空出来之后再去处理执行任务 4 和 5
使用这种线程池方法的一个主要优点是，假如您希望一次处理10000个请求，但不希望创建10000个线程，从而避免造成系统资源的过量使用导致的宕机。您可以使用此方法创建一个包含500个线程的线程池，并且可以向该线程池提交500个请求。
ThreadPool此时将创建最多500个线程，一次处理500个请求。在任何一个线程的进程完成之后，ThreadPool将在内部将第501个请求分配给该线程，并将继续对所有剩余的请求执行相同的操作。在系统资源比较紧张的情况下，线程池是保证程序稳定运行的一个有效的解决方案。
死锁: 虽然死锁可能发生在任何多线程程序中，但线程池引入了另一个死锁案例，其中所有执行线程都在等待队列中某个阻塞线程的执行结果，导致线程无法继续执行。
线程泄漏 : 如果线程池中线程在任务完成时未正确返回，将发生线程泄漏问题。例如，某个线程引发异常并且池类没有捕获此异常，则线程将异常退出，从而线程池的大小将减小一个。如果这种情况重复多次，则线程池最终将变为空，没有线程可用于执行其他任务。
线程频繁轮换: 如果线程池大小非常大，则线程之间进行上下文切换会浪费很多时间。所以在系统资源允许的情况下，也不是线程池越大越好。
线程池大小优化： 线程池的最佳大小取决于可用的处理器数量和待处理任务的性质。对于CPU密集型任务，假设系统有N个逻辑处理核心，N 或 N+1 的最大线程池数量大小将实现最大效率。对于 I/O密集型任务，需要考虑请求的等待时间（W）和服务处理时间（S）的比例，线程池最大大小为 N*(1+ W/S)会实现最高效率。
不要教条的使用上面的总结，需要根据自己的应用任务处理类型进行灵活的设置与调优，其中少不了测试实验。
欢迎关注我的博客，里面有很多精品合集本文转载注明出处（必须带连接，不能只转文字）：字母哥博客。
觉得对您有帮助的话，帮我点赞、分享！您的支持是我不竭的创作动力！ 。另外，笔者最近一段时间输出了如下的精品内容，期待您的关注。
《手摸手教你学Spring Boot2.0》
《Spring Security-JWT-OAuth2一本通》
《实战前后端分离RBAC权限管理系统》
《实战SpringCloud微服务从青铜到王者》
《VUE深入浅出系列》