一般java 项目开发中做一些批量任务，较好的利用CPU资源，一般会采用 线程池来提高系统利用效率，降低内存损耗。
在java开发中，一般使用线程池无外乎两种，一种是jdk自带的四种线程池 newCachedThreadPool，newFixedThreadPool，newSingleThreadExector， newScheduledThreadPool，但是他们四种都是由Executors工具类创建的，线程池存在一定弊端：
线程池的几个参数定义
corePoolSize： 核心线程数，也是线程池中常驻的线程数，线程池初始化时默认是没有线程的，当任务来临时才开始创建线程去执行任务;
-maximumPoolSize： 最大线程数，在核心线程数的基础上可能会额外增加一些非核心线程，需要注意的是只有当workQueue(工作队列)队列填满时才会创建多于corePoolSize的线程(线程池总线程数不超过maxPoolSize)
keepAliveTime： 非核心线程的空闲时间超过keepAliveTime就会被自动终止回收掉，注意当corePoolSize=maxPoolSize时，keepAliveTime参数也就不起作用了(因为不存在非核心线程)； 超过时间了就回收了。
unit： keepAliveTime的时间单位
workQueue： 用于保存任务的队列，可以为无界、有界、同步移交三种队列类型之一，当池子里的工作线程数大于corePoolSize时，这时新进来的任务会被放到队列中。
handler： 线程池无法继续接收任务(队列已满且线程数达到maximunPoolSize)时的饱和策略，取值有AbortPolicy、CallerRunsPolicy、DiscardOldestPolicy、DiscardPolicy
线程池中任务有三种排队策略
-
直接提交。直接提交策略表示线程池不对任务进行缓存。新进任务直接提交给线程池，当线程池中没有空闲线程时，创建一个新的线程处理此任务。这种策略需要线程池具有无限增长的可能性。实现为：SynchronousQueue。
-
有界队列。当线程池中线程达到corePoolSize时，新进任务被放在队列里排队等待处理。有界队列(如ArrayBlockingQueue)有助于防止资源耗尽，但是可能较难调整和控制。队列大小和最大池大小可能需要相互折衷：使用大型队列和小型池可以最大限度地降低 CPU 使用率、操作系统资源和上下文切换开销，但是可能导致人工降低吞吐量。如果任务频繁阻塞(例如，如果它们是 I/O 边界)，则系统可能为超过您许可的更多线程安排时间。使用小型队列通常要求较大的池大小，CPU 使用率较高，但是可能遇到不可接受的调度开销，这样也会降低吞吐量。
-
无界队列。使用无界队列(例如，不具有预定义容量的 LinkedBlockingQueue)将导致在所有 corePoolSize 线程都忙时新任务在队列中等待。这样，创建的线程就不会超过 corePoolSize。(因此，maximumPoolSize 的值也就无效了。)当每个任务完全独立于其他任务，即任务执行互不影响时，适合于使用无界队列；例如，在 Web 页服务器中。这种排队可用于处理瞬态突发请求，当命令以超过队列所能处理的平均数连续到达时，此策略允许无界线程具有增长的可能性。
newFixedThreadPool
new ThreadPoolExecutor(var0, var0, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue())
最大线程数=核心线程数，线程的处理速度跟不上提交速度，使用的无界队列。
设置了corePoolSize=maxPoolSize，（最大线程数=核心线程数）无界队列，任务可以无限放入，当请求过多时(任务处理速度跟不上任务提交速度造成请求堆积)可能导致占用过多内存或直接导致OOM异常。
newSingleThreadExector
new ThreadPoolExecutor(1, 1, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue(), var0)
最大线程数=核心线程数
基本同 newFixedThreadPool，但是将线程数设置为了1，单线程，弊端和newFixedThreadPool 一致。
newCachedThreadPool 使用的构造方式为
new ThreadPoolExecutor(0, maxvalue, 60L, TimeUnit.SECONDS, new SynchronousQueue())
核心线程数=0，最大线程数等于Integer的最大值
corePoolSize=0，maxPoolSize为很大的数，同步移交队列，也就是说不维护常驻线程(核心线程)，每次来请求直接创建新线程来处理任务，也不使用队列缓冲，会自动回收多余线程，由于将maxPoolSize设置成Integer.MAX_VALUE，当请求很多时就可能创建过多的线程，导致资源耗尽OOM。
newScheduledThreadPool
使用的构造方式为
new ThreadPoolExecutor(var1, maxvalue, 0L, TimeUnit.NANOSECONDS, new ScheduledThreadPoolExecutor.DelayedWorkQueue())
支持定时周期性执行，注意一下使用的是延迟队列，弊端同newCachedThreadPool一致。
自定义线程池
需要使用ThreadPoolExecutor类。
ThreadPoolExecutor类的构造方法： public ThreadPoolExecutor(int coreSize,int maxSize,long KeepAliveTime,TimeUnit unit,BlockingQueue queue,ThreadFactory factory,RejectedExectionHandler handler)；
线程池大小计算
计算密集型
顾名思义就是应用需要非常多的CPU计算资源，在多核CPU时代，我们要让每一个CPU核心都参与计算，将CPU的性能充分利用起来，这样才算是没有浪费服务器配置，如果在非常好的服务器配置上还运行着单线程程序那将是多么重大的浪费。对于计算密集型的应用，完全是靠CPU的核数来工作，所以为了让它的优势完全发挥出来，避免过多的线程上下文切换，比较理想方案是：
线程数 = CPU核数+1，也可以设置成CPU核数*2，但还要看JDK的版本以及CPU配置(服务器的CPU有超线程)。
一般设置CPU * 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))
线程池相关参数配置
一定不要选择没有上限限制的配置项。
这也是为什么不建议使用 Executors 中创建线程的方法。
例如，Executors.newCachedThreadPool 的设置与无界队列的设置因为某些不可预期的情况，线程池会出现系统异常，导致线程暴增的情况或者任务队列不断膨胀，内存耗尽导致系统崩溃和异常。
推荐使用自定义线程池来避免该问题，这也是在使用线程池规范的首要原则！
第二，合理设置线程数量、和线程空闲回收时间，
根据具体的任务执行周期和时间去设定，避免频繁的回收和创建，虽然我们使用线程池的目的是为了提升系统性能和吞吐量，但是也要考虑下系统的稳定性，不然出现不可预期问题会很麻烦！
第三，根据实际场景，选择适用于自己的拒绝策略。
进行补偿，不要乱用JDK支持的自动补偿机制！尽量采用自定义的拒绝策略去进行兜底！
第四，线程池拒绝策略，自定义拒绝策略可以实现RejectedExecutionHandler接口。
JDK自带的拒绝策略如下：
AbortPolicy：直接抛出异常阻止系统正常工作。CallerRunsPolicy：只要线程池未关闭，该策略直接在调用者线程中，运行当前被丢弃的任务。DiscardOldestPolicy：丢弃最老的一个请求，尝试再次提交当前任务。DiscardPolicy：丢弃无法处理的任务，不给予任何处理。
