线程池的管理，源码解析以及RejectedExecution

       对于线程池用的也不少，但是最近还是糟了一坑。还是要深入了解一下线程池的使用，以免以后遭重

        对于JavaEE项目来说，服务端项目是一直启动着，有的时候需要异步或者大并发的项目来的时候，就会想到使用多线程或者线程池来维护有关的线程。

       最近有一个很简单的需求，就是一个方法，可能是异步或者同步返回一个结果。该方法，全局一个调用就够了，不用很多线程同时工作。就想着用future，如果是同步的话就用get获取结果，同步返回。如果是异步的话，就不get，直接异步返回一个正在处理

       这个思路是没问题的，于是代码如下（因为原因是一样的问题，所以一下文章不考虑同步情况，只考虑异步）

      

package threadPools.zxy.threadPools.zxy;

import java.util.concurrent.Callable;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.ThreadPoolExecutor;
import java.util.concurrent.TimeUnit;

public class ThreadFuture {
	private static ThreadPoolExecutor executor = new ThreadPoolExecutor(1, 1, 0, TimeUnit.SECONDS,
			new LinkedBlockingQueue<Runnable>());

	public static void main(String[] args) {

		executor.submit(new Callable<String>() {
			public String call() throws Exception {
				System.out.println("task-->threadName:" + Thread.currentThread().getName());
				Thread.sleep(1000);
				return null;
			}
		});

		executor.shutdown();

	}
}

             假设这就是服务器上的代码，其实就是很简单，我计划申请一个线程池，corePoolSize为1, maximumPoolSize为1, keepAliveTime 为0, unit 为秒,workQueue为LinkedBlockingQueue。（其实这个和ExecutorService executor2 = Executors.newSingleThreadExecutor()，基本是一样的，newSingleThreadExecutor()就是封装后的ThreadPoolExecutor，这次就以ThreadPoolExecutor为例）

              我的想法很简单，就是就一个线程执行，也不需要其余线程存活时间，异步执行完一遍以后，线程池shutdown，释放线程池，节省空间，等待下一次用户的访问。

               结果在服务器上运行该代码，只有第一次访问的时候线程正常执行，后续访问没反应，会报错，就像这样：

Exception in thread "main" task-->threadName:pool-1-thread-1
java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@70dea4e rejected from java.util.concurrent.ThreadPoolExecutor@5c647e05[Shutting down, pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 0]
	at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
	at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
	at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
	at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
	at threadPools.zxy.threadPools.zxy.ThreadFuture.main(ThreadFuture.java:14)

              好好的代码，怎么会报错呢，赶时间开发，最随便查了下，有人说是策略的问题，换个策略就好了，于是就将代码改成：

        

public class ThreadFuture {
	private static ThreadPoolExecutor executor = new ThreadPoolExecutor(1, 1, 0, TimeUnit.SECONDS,
			new LinkedBlockingQueue<Runnable>(),new ThreadPoolExecutor.CallerRunsPolicy());

	public static void main(String[] args) {
		//模仿多次客户端请求
		for (int i = 0; i < 10; i++) {
			executor.submit(new Callable<String>() {
				public String call() throws Exception {
					System.out.println("task-->threadName:" + Thread.currentThread().getName());
					Thread.sleep(1000);
					return null;
				}
			});
			executor.shutdown();
		}
		

	}
}

       测了一下，现在是不报错了，但是客户端的十次请求，只有第一次访问有效，后来的访问全部没有。这还不是问题的解决啊。转而，想了下，会不会是executor.shutdown()的问题呢，可是很多人都说用完要关掉的啊，要不然不是每次访问都会新增很多线程吗!

      too native! 这就是对线程池了解太浅了

      其实，shutdown()方法就是关闭线程池，但其实准确来说，shutdown方法是已在运行的线程和队列中的线程可以继续运行，但是新加入的线程会被拒绝，因为，线程池已经说了，我要关闭了，就如同超市晚上关门，我不好意思敢客人们出来，你们继续买，但是新的客人我是不会在放进去了，因为最后的客人买完东西，我就要关门了。

     所以，盲目的改策略没有任何用，因为是线程池已经关闭了。

     什么时候，shutdown()呢，这里有个问题就是，你为什么需要线程池。

     其实，线程池的诞生就是因为，在大量访问进来的时候，不断的new thread(),会造成急剧的性能损失，而且，也不能对线程很方便的管理。就如同，一个公司，在一个月的某个时刻非常的忙，有100个任务，于是，公司在这个时候飞快的招了新的员工，在办完任务，就把100个员工全开除了，这显然是非常不合理的。

   线程池的作用就是，在一个公司招了一个人事主管，这个人事主管招了帮忙招了5个人，在100个任务来的时候，给每人一个任务，剩余的95个任务放在任务清单表里，一个一个分配着做完。在不忙的时候，让这五个人挂在哪里休息，或者设置keepAliveTime，有一段时间没活，还可以开除几个节省资源maximumPoolSize，只保留核心员工corePoolSize。

     刚刚的代码，在第一次执行以后，就把人事主管开除了，后续任务再进来，线程池都关闭了（公司都没人了），谁干活呢？

      所以，平时在用main方法的时候调用shutdown()是因为正常执行结束后，线程池也就没用了，但是服务器是一直运行的，shutdown要慎重啊，后续的代码，把shutdown去掉以后，服务也就正常执行了，但这也引起了我对线程池的兴趣。

       线程池的各个参数到底是什么意思呢，各个方法的调用和结束又经历了哪些过程呢？

       上一个代码：

	public static void main(String[] args) {
		final LinkedBlockingQueue<Runnable> queue = new LinkedBlockingQueue<Runnable>(4);
		ThreadPoolExecutor executor = new ThreadPoolExecutor(1, 3, 0, TimeUnit.SECONDS, queue,
				new ThreadPoolExecutor.AbortPolicy());

		// 模仿多次客户端请求
		for (int i = 0; i < 10; i++) {
			executor.submit(new Callable<String>() {
				public String call() throws Exception {
					Thread.sleep(500);
					System.out.println("task-->threadName:" + Thread.currentThread().getName());
					System.out.println("阻塞队列长度" + queue.size());
					Thread.sleep(500);
					return null;
				}
			});
		}

	}
}

           设一个阻塞队列长度为4，设核心线程为1，最大线程为3，最大线程存活时间为0，策略是报错抛出策略

           结果如下：

           分析一下结果，在这个显然核心线程不够用的例子中，十轮循环，阻塞队列最大的时候就是长度为4的时候，也是我设置的值，线程数最多启动了三个，也符合了maximumPoolSize的申明。

           首先线程报错，是因为阻塞队列放不下了，最大线程数也都起来了，但是还是不够，这个时候3+4=7，而并发跑入的程序是10条，这就导致了。十份'活'，给一个做，这个人做不完，放在队列里等着一会做，但是队列只能放4个，没办法，在赶紧招两个人，总共三个人，每人一份'活'，队列里放四个。全满了，再进来新的'活'的时候，队列放不下，又不能招人了，那还是算了，我干脆自爆吧，就按照异常策略抛出了异常。

           控制台的输出，也应证了这一点。一开始，线程1获取工作，开始做工，剩余的四个工作全部存入阻塞队列，接下来两份工作进来，没地方存，但是最大数量线程池告知还可以扩员，于是又赶忙招了2两个人，一起到达上线，maximumPoolSize=3，这个时候，在来新的工作，就没地方了，抛出了异常。

           虽然抛出了异常，但可以看到，剩余的线程仍勤勤恳恳得把线程池里面的剩余四个任务分着做完了，才低调的离去，最终队列长度为0

 总结：

          

• corePoolSize：核心线程数
• • 核心线程会一直存活，及时没有任务需要执行
  • 当线程数小于核心线程数时，即使有线程空闲，线程池也会优先创建新线程处理
  • 设置allowCoreThreadTimeout=true（默认false）时，核心线程会超时关闭
• queueCapacity：任务队列容量（阻塞队列）
• • 当核心线程数达到最大时，新任务会放在队列中排队等待执行
• maxPoolSize：最大线程数
• • 当线程数>=corePoolSize，且任务队列已满时。线程池会创建新线程来处理任务
  • 当线程数=maxPoolSize，且任务队列已满时，线程池会拒绝处理任务而抛出异常
• keepAliveTime：线程空闲时间
• • 当线程空闲时间达到keepAliveTime时，线程会退出，直到线程数量=corePoolSize
  • 如果allowCoreThreadTimeout=true，则会直到线程数量=0
• allowCoreThreadTimeout：允许核心线程超时
• rejectedExecutionHandler：任务拒绝处理器
• • 两种情况会拒绝处理任务：
  • • 当线程数已经达到maxPoolSize，切队列已满，会拒绝新任务
    • 当线程池被调用shutdown()后，会等待线程池里的任务执行完毕，再shutdown。如果在调用shutdown()和线程池真正shutdown之间提交任务，会拒绝新任务
  • 线程池会调用rejectedExecutionHandler来处理这个任务。如果没有设置默认是AbortPolicy，会抛出异常
  • ThreadPoolExecutor类有几个内部实现类来处理这类情况：
  • • AbortPolicy 丢弃任务，抛运行时异常
    • CallerRunsPolicy 执行任务
    • DiscardPolicy 忽视，什么都不会发生
    • DiscardOldestPolicy 从队列中踢出最先进入队列（最后一个执行）的任务
  • 实现RejectedExecutionHandler接口，可自定义处理器

 

ThreadPoolExecutor执行顺序：

     线程池按以下行为执行任务

 

1. 当线程数小于核心线程数时，创建线程。
2. 当线程数大于等于核心线程数，且任务队列未满时，将任务放入任务队列。
3. 当线程数大于等于核心线程数，且任务队列已满
   1. 若线程数小于最大线程数，创建线程
   2. 若线程数等于最大线程数，抛出异常，拒绝任务