论如何优雅的自定义ThreadPoolExecutor线程池
更好的markDown阅读体验可直接访问我的CSDN博客：https://blog.csdn.net/u012881584/article/details/85221635
前言
线程池想必大家也都用过，JDK的Executors 也自带一些线程池。但是不知道大家有没有想过，如何才是最优雅的方式去使用过线程池吗？ 生产环境要怎么去配置自己的线程池才是合理的呢？
今天周末，刚好有时间来总结一下自己所认为的'优雅', 如有问题欢迎大家指正。
线程池使用规则
要使用好线程池，那么一定要遵循几个规则：
线程个数大小的设置
线程池相关参数配置
利用Hook嵌入你的行为
线程池的关闭
线程池配置相关
线程池大小的设置
这其实是一个面试的考点，很多面试官会问你线程池coreSize 的大小来考察你对于线程池的理解。
首先针对于这个问题，我们必须要明确我们的需求是计算密集型还是IO密集型，只有了解了这一点，我们才能更好的去设置线程池的数量进行限制。
1、计算密集型：
顾名思义就是应用需要非常多的CPU计算资源，在多核CPU时代，我们要让每一个CPU核心都参与计算，将CPU的性能充分利用起来，这样才算是没有浪费服务器配置，如果在非常好的服务器配置上还运行着单线程程序那将是多么重大的浪费。对于计算密集型的应用，完全是靠CPU的核数来工作，所以为了让它的优势完全发挥出来，避免过多的线程上下文切换，比较理想方案是：
线程数 = CPU核数+1，也可以设置成CPU核数*2，但还要看JDK的版本以及CPU配置(服务器的CPU有超线程)。
一般设置CPU * 2即可。
2、IO密集型
我们现在做的开发大部分都是WEB应用，涉及到大量的网络传输，不仅如此，与数据库，与缓存间的交互也涉及到IO，一旦发生IO，线程就会处于等待状态，当IO结束，数据准备好后，线程才会继续执行。因此从这里可以发现，对于IO密集型的应用，我们可以多设置一些线程池中线程的数量，这样就能让在等待IO的这段时间内，线程可以去做其它事，提高并发处理效率。那么这个线程池的数据量是不是可以随便设置呢？当然不是的，请一定要记得，线程上下文切换是有代价的。目前总结了一套公式，对于IO密集型应用：
线程数 = CPU核心数/(1-阻塞系数) 这个阻塞系数一般为0.8~0.9之间，也可以取0.8或者0.9。
套用公式，对于双核CPU来说，它比较理想的线程数就是20，当然这都不是绝对的，需要根据实际情况以及实际业务来调整：final int poolSize = (int)(cpuCore/(1-0.9))
针对于阻塞系数，《Programming Concurrency on the JVM Mastering》即《Java 虚拟机并发编程》中有提到一句话：
对于阻塞系数，我们可以先试着猜测，抑或采用一些性能分析工具或java.lang.management API 来确定线程花在系统/IO操作上的时间与CPU密集任务所耗的时间比值。
线程池相关参数配置
说到这一点，我们只需要谨记一点，一定不要选择没有上限限制的配置项。
这也是为什么不建议使用Executors 中创建线程的方法。
比如，Executors.newCachedThreadPool的设置与无界队列的设置因为某些不可预期的情况，线程池会出现系统异常，导致线程暴增的情况或者任务队列不断膨胀，内存耗尽导致系统崩溃和异常。 我们推荐使用自定义线程池来避免该问题，这也是在使用线程池规范的首要原则！ 小心无大错，千万别过度自信！
可以看下Executors中四个创建线程池的方法：
//使用无界队列public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>());
}//线程池数量是无限的public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>());
}其他的就不再列举了，大家可以自行查阅源码。
第二，合理设置线程数量、和线程空闲回收时间，根据具体的任务执行周期和时间去设定，避免频繁的回收和创建，虽然我们使用线程池的目的是为了提升系统性能和吞吐量，但是也要考虑下系统的稳定性，不然出现不可预期问题会很麻烦！
第三，根据实际场景，选择适用于自己的拒绝策略。进行补偿，不要乱用JDK支持的自动补偿机制！尽量采用自定义的拒绝策略去进行兜底！
第四，线程池拒绝策略，自定义拒绝策略可以实现RejectedExecutionHandler接口。
JDK自带的拒绝策略如下：
AbortPolicy：直接抛出异常阻止系统正常工作。
CallerRunsPolicy：只要线程池未关闭，该策略直接在调用者线程中，运行当前被丢弃的任务。
DiscardOldestPolicy：丢弃最老的一个请求，尝试再次提交当前任务。
DiscardPolicy：丢弃无法处理的任务，不给予任何处理。
利用Hook
利用Hook，留下线程池执行轨迹：
ThreadPoolExecutor提供了protected类型可以被覆盖的钩子方法，允许用户在任务执行之前会执行之后做一些事情。我们可以通过它来实现比如初始化ThreadLocal、收集统计信息、如记录日志等操作。这类Hook如beforeExecute和afterExecute。另外还有一个Hook可以用来在任务被执行完的时候让用户插入逻辑，如rerminated 。
如果hook方法执行失败，则内部的工作线程的执行将会失败或被中断。
我们可以使用beforeExecute和afterExecute来记录线程之前前和后的一些运行情况，也可以直接把运行完成后的状态记录到ELK等日志系统。
关闭线程池
内容当线程池不在被引用并且工作线程数为0的时候，线程池将被终止。我们也可以调用shutdown来手动终止线程池。如果我们忘记调用shutdown，为了让线程资源被释放，我们还可以使用keepAliveTime和allowCoreThreadTimeOut来达到目的!
当然，稳妥的方式是使用虚拟机Runtime.getRuntime().addShutdownHook方法，手工去调用线程池的关闭方法！
线程池使用实例
线程池核心代码：
public class AsyncProcessQueue { // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/**
* Task 包装类<br>
* 此类型的意义是记录可能会被 Executor 吃掉的异常<br>
*/
public static class TaskWrapper implements Runnable { private static final Logger _LOGGER = LoggerFactory.getLogger(TaskWrapper.class); private final Runnable gift; public TaskWrapper(final Runnable target) { this.gift = target;
} @Override
public void run() { // 捕获异常，避免在 Executor 里面被吞掉了
if (gift != null) { try {
gift.run();
} catch (Exception e) {
_LOGGER.error("Wrapped target execute exception.", e);
}
}
}
} // ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/**
* 执行指定的任务
*
* @param task
* @return
*/
public static boolean execute(final Runnable task) { return AsyncProcessor.executeTask(new TaskWrapper(task));
}
}public class AsyncProcessor { static final Logger LOGGER = LoggerFactory.getLogger(AsyncProcessor.class); /**
* 默认最大并发数<br>
*/
private static final int DEFAULT_MAX_CONCURRENT = Runtime.getRuntime().availableProcessors() * 2; /**
* 线程池名称格式
*/
private static final String THREAD_POOL_NAME = "ExternalConvertProcessPool-%d"; /**
* 线程工厂名称
*/
private static final ThreadFactory FACTORY = new BasicThreadFactory.Builder().namingPattern(THREAD_POOL_NAME)
.daemon(true).build(); /**
* 默认队列大小
*/
private static final int DEFAULT_SIZE = 500; /**
* 默认线程存活时间
*/
private static final long DEFAULT_KEEP_ALIVE = 60L; /**NewEntryServiceImpl.java:689
* Executor
*/
private static ExecutorService executor; /**
* 执行队列
*/
private static BlockingQueue<Runnable> executeQueue = new ArrayBlockingQueue<>(DEFAULT_SIZE); static { // 创建 Executor
// 此处默认最大值改为处理器数量的 4 倍
try {
executor = new ThreadPoolExecutor(DEFAULT_MAX_CONCURRENT, DEFAULT_MAX_CONCURRENT * 4, DEFAULT_KEEP_ALIVE,
TimeUnit.SECONDS, executeQueue, FACTORY); // 关闭事件的挂钩
Runtime.getRuntime().addShutdownHook(new Thread(new Runnable() { @Override
public void run() {
AsyncProcessor.LOGGER.info("AsyncProcessor shutting down.");
executor.shutdown(); try { // 等待1秒执行关闭
if (!executor.awaitTermination(1, TimeUnit.SECONDS)) {
AsyncProcessor.LOGGER.error("AsyncProcessor shutdown immediately due to wait timeout.");
executor.shutdownNow();
}
} catch (InterruptedException e) {
AsyncProcessor.LOGGER.error("AsyncProcessor shutdown interrupted.");
executor.shutdownNow();
}
AsyncProcessor.LOGGER.info("AsyncProcessor shutdown complete.");
}
}));
} catch (Exception e) {
LOGGER.error("AsyncProcessor init error.", e); throw new ExceptionInInitializerError(e);
}
} /**
* 此类型无法实例化
*/
private AsyncProcessor() {
} /**
* 执行任务，不管是否成功<br>
* 其实也就是包装以后的 {@link Executer} 方法
*
* @param task
* @return
*/
public static boolean executeTask(Runnable task) { try {
executor.execute(task);
} catch (RejectedExecutionException e) {
LOGGER.error("Task executing was rejected.", e); return false;
} return true;
} /**
* 提交任务，并可以在稍后获取其执行情况<br>
* 当提交失败时，会抛出 {@link }
*
* @param task
* @return
*/
public static <T> Future<T> submitTask(Callable<T> task) { try { return executor.submit(task);
} catch (RejectedExecutionException e) {
LOGGER.error("Task executing was rejected.", e); throw new UnsupportedOperationException("Unable to submit the task, rejected.", e);
}
}
}使用方式：
AsyncProcessQueue.execute(new Runnable() { @Override
public void run() { //do something
}
});可以根据自己的使用场景灵活变更，我这里并没有用到beforeExecute和afterExecute以及拒绝策略。
