本文探讨了线程池在实际开发中的应用技巧，包括线程命名的重要性、异常处理的最佳实践、线程池队列长度的优化及监控策略等。此外，还分析了Spring框架在异步任务异常处理方面的不足及其改进。
译文：http://www.importnew.com/20263.html 原文：http://www.nurkiewicz.com/2014/11/executorservice-10-tips-and-tricks.html
不转发全文了，写点自己的观点
第一点很强烈使用。不管用什么方式，最好都对自己的线程命名，这对调试很有帮助。你应该知道不使用 Google Guava 的情况下如何自定义线程池中的线程。当然，实际开发中最好能用 Guava 就用，减少重复代码。
第二点是进阶的线程命名技巧，能用最好，但是我不知道对实际工作的帮助有多大，肯定是对调试有点用的。
第三点，使用线程池一定要知道 shutdown 和 shutdownNow 的异同，根据情况选择使用
第四点，线程中断机制一定要了解，不多解释
第五点，线程池队列一定要保持优先长度，默认的20亿太大了。并且最好能监控
第六点，正常情况使用线程池很多人都会，报异常之后怎么处理就未必了。开发人员需要知道使用 execute 执行任务如何处理异常，使用 submit 执行任务如何处理异常。在这一点上，即便是 Spring 框架也会犯错。看看 Spring 4.0 中 @Async 任务是如何处理异常的，答案是没处理，重新抛出来。问题是在使用 @Async 注解实现异步任务的场景中，又有谁会执行 Future.get() 来得到重新抛出的异常呢？所以，稍不注意，异常就静悄悄地丢了。Spring 4.1 之后改进了这个问题，感兴趣的可以看一下 Spring 的源代码：https://github.com/spring-projects/spring-framework/blob/4.0.x/spring-aop/src/main/java/org/springframework/aop/interceptor/AsyncExecutionInterceptor.java
所以，不论是使用原生的线程池还是 Spring 的线程池，都需要了解线程池中异常的处理机制。
注：这一段译文翻译有错
第七点，监控任务在队列中等待的时间
第八点，可能80%情况下不用这么做也能解决问题，但是剩下20%可能就需要这种方法帮助你更好地调试程序
第九点，其实我对 CompletableFuture 并不感冒，方法太多了，看的头晕。我更喜欢 Guava 和 Spring 里的 ListenableFuture。不过 CompletableFuture 毕竟是 JDK 提供的，而且作者还是大名鼎鼎的 Doug Lea，看来只怪自己学艺不精了。
第十点，不做解释，感兴趣可以看看源代码
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
