ExecutorService是Java中管理异步任务的核心工具，相比直接创建Thread，它通过线程池机制实现线程复用、控制并发数、管理任务队列和统一关闭，提升系统稳定性和资源利用率。
Java中的
ExecutorService
是管理和执行异步任务的核心工具，它提供了一种比直接创建和管理线程更高级、更健壮的方式来处理并发。简单来说，它就是一个线程池，帮你打理线程的创建、复用和销毁，让你能更专注于任务本身，而不是线程的生命周期管理。
使用
ExecutorService
，我们主要关注三个环节：创建线程池、提交任务、以及适时关闭线程池。
创建线程池Java的
Executors
工具类提供了一些工厂方法来快速创建不同类型的
ExecutorService
：
Executors.newFixedThreadPool(int nThreads)
: 创建一个固定大小的线程池。当提交的任务多于线程数时，多余的任务会排队等待。这很适合处理CPU密集型任务，或者当你知道系统能承受的最大并发量时。
Executors.newCachedThreadPool()
: 创建一个可缓存的线程池。如果池中有空闲线程，就复用；如果没有，就创建新线程。空闲时间超过60秒的线程会被回收。这个适用于执行大量短期异步任务的场景，比如I/O密集型任务。
Executors.newSingleThreadExecutor()
: 创建一个单线程的
ExecutorService
。它能保证所有任务按照提交的顺序串行执行。如果你需要确保任务的执行顺序，且不希望手动同步，这是一个很好的选择。
Executors.newScheduledThreadPool(int corePoolSize)
: 创建一个支持定时及周期性任务执行的线程池。
除了这些工厂方法，我们也可以直接通过
ThreadPoolExecutor
构造函数来创建自定义的线程池，这提供了最细粒度的控制，可以调整核心线程数、最大线程数、线程空闲时间、工作队列以及拒绝策略等。
提交任务
ExecutorService
主要有两种提交任务的方式：
立即学习“Java免费学习笔记（深入）”；
execute(Runnable command)
: 提交一个不需要返回结果的任务。
submit(Callable task)
/
submit(Runnable task)
: 提交一个可能需要返回结果（通过
Future
对象获取）的任务。
Callable
接口允许任务抛出异常并返回一个泛型结果，而
Runnable
的
submit
版本则返回一个代表任务完成的
Future
对象。
关闭线程池当
ExecutorService
不再需要时，必须将其关闭以释放资源。
shutdown()
: 启动有序关闭，不再接受新任务，但会完成已提交的任务。
shutdownNow()
: 尝试立即停止所有正在执行的任务，并停止处理等待任务，返回未执行的任务列表。
import java.util.concurrent.*;public class ExecutorServiceExample { public static void main(String[] args) throws InterruptedException, ExecutionException { // 1. 创建一个固定大小的线程池 ExecutorService executor = Executors.newFixedThreadPool(2); // 2. 提交Runnable任务 executor.execute(() -> { System.out.println("Runnable Task 1 running on thread: " + Thread.currentThread().getName()); try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.println("Runnable Task 1 finished."); }); // 3. 提交Callable任务并获取Future Future future = executor.submit(() -> { System.out.println("Callable Task 2 running on thread: " + Thread.currentThread().getName()); try { TimeUnit.SECONDS.sleep(2); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return "Task 2 interrupted!"; } System.out.println("Callable Task 2 finished."); return "Task 2 Result"; }); // 4. 获取Callable任务的结果 System.out.println("Future result: " + future.get()); // get()会阻塞直到任务完成 // 5. 提交更多任务，看它们如何排队 executor.execute(() -> { System.out.println("Runnable Task 3 running on thread: " + Thread.currentThread().getName()); try { TimeUnit.SECONDS.sleep(1); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } System.out.println("Runnable Task 3 finished."); }); // 6. 关闭线程池 executor.shutdown(); // 不再接受新任务，但会等待已提交任务完成 System.out.println("ExecutorService shutdown initiated."); // 等待所有任务完成，最多等待5秒 if (!executor.awaitTermination(5, TimeUnit.SECONDS)) { System.err.println("ExecutorService did not terminate in the specified time."); executor.shutdownNow(); // 尝试立即停止 } System.out.println("All tasks completed or forcefully stopped."); }}
为什么在现代Java应用中，我们更倾向于使用ExecutorService而不是直接创建Thread？
这几乎是一个共识了，直接
new Thread()
在很多场景下都是个“反模式”。我个人觉得，这不仅仅是代码规范的问题，更是对系统资源管理和应用健壮性的一种深刻理解。当你直接创建线程时，你实际上是在把线程的生命周期管理、资源消耗以及调度策略等问题都甩给了自己。
想象一下，如果你的应用需要处理成千上万个并发请求，每个请求都
new Thread()
，那会发生什么？首先，线程的创建和销毁本身就是一项开销不小的操作，频繁地创建销毁会消耗大量的CPU和内存资源。其次，操作系统对进程能创建的线程数是有限制的，你很容易就会耗尽系统资源，导致
OutOfMemoryError
或者系统响应缓慢。更糟糕的是，你很难控制这些线程的行为，比如它们什么时候启动、什么时候结束，以及如何处理它们之间的优先级和资源竞争。
ExecutorService
则彻底改变了这种局面。它提供了一个抽象层，把任务的提交和任务的执行解耦了。你只需要定义好你的任务（
Runnable
或
Callable
），然后把它扔给
ExecutorService
，剩下的事情，比如线程的创建、复用、调度、任务队列管理，甚至包括线程的异常处理，都由
ExecutorService
来负责。这就像你把快递包裹交给快递公司，你不用关心快递员是怎么被雇佣的，也不用管他用什么交通工具，你只关心包裹能否按时送达。
通过线程池，我们可以：
重用线程：避免了频繁创建和销毁线程的开销。控制并发数：可以限制同时运行的线程数量，防止系统过载。管理任务队列：当线程池满时，新任务可以在队列中等待，而不是直接被拒绝或导致系统崩溃。提供高级功能：比如定时任务、获取任务执行结果（
Future
）、以及统一的关闭机制。
所以，与其说我们“倾向于”使用
ExecutorService
，不如说它已经成为处理并发任务的“标准姿势”。这不仅让代码更简洁、更易于维护，更重要的是，它让我们的应用在面对高并发场景时，能够更加稳定和高效。
几种常见的ExecutorService线程池类型及其适用场景分析
Executors
工厂类提供的几种标准线程池，其实是针对不同场景预设的
ThreadPoolExecutor
配置。理解它们背后的设计意图，能帮助我们更好地选择。
FixedThreadPool
(固定大小线程池)
特点：核心线程数和最大线程数相等，线程数量固定。当任务量超过线程数时，新任务会进入无界队列等待。适用场景：CPU密集型任务：如果任务主要消耗CPU，那么线程数通常设置为CPU核心数或核心数+1，以最大化CPU利用率，避免过多线程切换带来的开销。负载可预测的场景：例如，一个后台服务需要持续处理一定量的计算任务，且并发量相对稳定。我的看法：这是最常用也最“安全”的一种。因为它限制了并发，不会因为任务量暴增而耗尽系统资源。但缺点也很明显，如果任务都是I/O密集型，那么固定线程数可能导致CPU利用率不高，因为线程在等待I/O时无法执行其他任务。
CachedThreadPool
(可缓存线程池)
特点：核心线程数为0，最大线程数为
Integer.MAX_VALUE
。当有任务提交时，如果池中有空闲线程就复用；如果没有，就创建新线程。空闲线程在一定时间（默认60秒）后会被回收。使用
SynchronousQueue
作为工作队列，这意味着提交任务时必须有可用线程来立即执行，否则会创建新线程。适用场景：I/O密集型任务：任务执行时间短，但数量可能非常多，且并发量波动大。例如，处理大量的网络请求，每个请求都很快完成，但并发数不确定。任务生命周期短：线程在任务完成后很快就能被回收或复用。我的看法：
CachedThreadPool
很“聪明”，它能根据负载动态调整线程数。但它也有潜在的风险：如果任务持续不断且执行时间较长，可能会创建出非常多的线程，最终耗尽系统内存。所以在生产环境中，我通常会更谨慎地使用它，或者限制其最大线程数。
SingleThreadExecutor
(单线程线程池)
法语写作助手
法语助手旗下的AI智能写作平台，支持语法、拼写自动纠错，一键改写、润色你的法语作文。
31 查看详情 
特点：只有一个工作线程。所有任务都会按提交顺序依次执行。适用场景：需要保证任务严格顺序执行的场景：例如，更新某个共享资源，或者处理日志写入，确保不会出现并发问题。避免手动同步：通过将所有相关操作提交给单线程池，可以天然地避免复杂的锁机制。我的看法：这个池子在需要“串行化”处理某些逻辑时非常方便，它帮你省去了很多手动加锁、同步的麻烦。但如果任务本身执行很慢，它会成为性能瓶颈。
ScheduledThreadPool
(定时任务线程池)
特点：支持定时（延迟执行）和周期性任务执行。适用场景：周期性数据同步：例如，每隔5分钟同步一次数据。延迟执行任务：例如，用户下单后30分钟如果未支付则自动取消订单。后台监控或清理任务。我的看法：它是处理定时任务的首选，比
Timer
更健壮，因为它能更好地处理任务执行时的异常，并且可以配置多个线程并行执行定时任务。
在实际项目中，很多时候我们最终会发现，
Executors
提供的工厂方法虽然方便，但可能无法满足所有精细化的需求。这时，直接构造
ThreadPoolExecutor
就变得非常重要了。通过调整
corePoolSize
、
maximumPoolSize
、
keepAliveTime
、
workQueue
和
RejectedExecutionHandler
等参数，我们可以根据应用的具体负载特性，构建出最适合自己的线程池。例如，对于一个核心业务服务，我会倾向于自定义
ThreadPoolExecutor
，明确指定队列大小和拒绝策略，以防止系统在极端情况下崩溃。
在实际项目中，如何优雅地管理和关闭ExecutorService以避免资源泄露？
在实际项目中，
ExecutorService
的关闭往往比它的创建和使用更容易被忽视，但这恰恰是避免资源泄露、确保应用平稳退出的关键一环。我见过太多因为
ExecutorService
没有正确关闭，导致应用进程无法退出、内存持续增长或者在某些场景下出现诡异行为的案例。
为什么必须关闭？
ExecutorService
内部维护着工作线程，这些线程通常是守护线程（daemon thread）的补充，它们会阻止JVM正常退出。如果你不显式关闭它们，即使你的
main
方法执行完毕，JVM也可能因为这些活跃的非守护线程而一直运行。这在Web应用或长生命周期的服务中尤其危险，可能导致服务器资源耗尽，或者在应用重新部署时出现端口占用等问题。
优雅关闭的策略
调用
shutdown()
：启动有序关闭这是最常用的关闭方式。
shutdown()
方法会启动一个有序的关闭序列：
它会拒绝新的任务提交。但会等待所有已提交的任务执行完毕。一旦所有任务完成，线程池中的线程就会被终止。
最佳实践：在你的应用生命周期结束时（例如，Web应用的
destroy
方法、Spring应用的
@PreDestroy
方法，或者命令行应用的
main
方法结束前），调用
shutdown()
。
配合
awaitTermination()
：等待任务完成仅仅调用
shutdown()
并不能保证所有任务会立即完成。如果你需要在关闭前确保所有任务都执行完毕（例如，保存最终数据、清理资源），就需要使用
awaitTermination()
。
awaitTermination(long timeout, TimeUnit unit)
会阻塞当前线程，直到所有任务执行完毕，或者超时时间到达，或者当前线程被中断。
executor.shutdown(); // 启动关闭try { // 最多等待60秒，看所有任务是否完成 if (!executor.awaitTermination(60, TimeUnit.SECONDS)) { // 如果超时了，但任务还没完成，可以考虑强制关闭 executor.shutdownNow(); // 再次等待，给强制关闭一个机会 if (!executor.awaitTermination(60, TimeUnit.SECONDS)) { System.err.println("线程池未能完全关闭！"); } }} catch (InterruptedException ie) { // 当前线程在等待时被中断，强制关闭 executor.shutdownNow(); Thread.currentThread().interrupt(); // 重新设置中断状态}
这种模式兼顾了优雅和强制，是生产环境中推荐的做法。
使用
shutdownNow()
：立即强制关闭
shutdownNow()
会尝试立即停止所有正在执行的任务，并停止处理等待队列中的任务，同时返回一个尚未执行的任务列表。
它会中断正在执行的线程（如果线程响应中断）。队列中的任务不会被执行。
适用场景：当系统遇到紧急情况，需要快速释放资源，或者在
awaitTermination()
超时后仍有未完成任务时。
注意事项：
shutdownNow()
是“尽力而为”的，它依赖于任务代码对中断信号的响应。如果你的任务代码中没有处理
InterruptedException
，或者执行的是不可中断的I/O操作，那么线程可能不会立即停止。
结合资源管理（
try-finally
或
try-with-resources
）如果你的
ExecutorService
生命周期是局部的，例如只在一个方法内部使用，那么可以考虑使用
try-finally
块来确保其关闭：
ExecutorService executor = Executors.newFixedThreadPool(2);try { // 提交任务...} finally { executor.shutdown(); // 建议加上awaitTermination()}
对于Java 7+，如果
ExecutorService
实现了
AutoCloseable
接口（虽然标准库的
ExecutorService
没有直接实现，但你可以包装它），则可以使用
try-with-resources
。
JVM关闭钩子（Shutdown Hook）对于应用级别的、贯穿整个生命周期的
ExecutorService
，可以注册一个JVM关闭钩子，确保在JVM退出前执行关闭逻辑。
final ExecutorService executor = Executors.newFixedThreadPool(5);// ... 提交任务 ...Runtime.getRuntime().addShutdownHook(new Thread(() -> { System.out.println("JVM shutdown hook activated. Shutting down ExecutorService..."); executor.shutdown(); try { if (!executor.awaitTermination(30, TimeUnit.SECONDS)) { System.err.println("ExecutorService did not terminate gracefully, forcing shutdown."); executor.shutdownNow(); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); executor.shutdownNow(); } System.out.println("ExecutorService shutdown complete.");}));
这种方式可以捕获到JVM的正常退出信号（例如，通过Ctrl+C），从而执行清理工作。
总结正确关闭
ExecutorService
是构建健壮、可靠的并发应用不可或缺的一部分。这不仅仅是“最佳实践”，更是避免潜在系统问题和资源泄露的“必做事项”。我的经验是，永远不要假设你的线程池会自动关闭，而是要主动、有策略地去管理它的生命周期。
以上就是Java中线程池ExecutorService使用方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/326661.html
微信扫一扫 
支付宝扫一扫 
