线程池的使用场景

创建线程和销毁线程的花销是比较大的（比如项目中手动创建线程， new Thread 类），这些时间有可能比处理业务的时间还要长。这样频繁的创建线程和销毁线程，再加上业务工作线程，消耗系统资源的时间，可能导致系统资源不足。（我们可以把创建和销毁的线程的过程去掉）

1、提高效率 创建好一定数量的线程放在池中，等需要使用的时候就从池中拿一个，这要比需要的时候创建一个线程对象要快的多。
2、方便管理 可以编写线程池管理代码对池中的线程同一进行管理，比如说启动时有该程序创建100个线程，每当有请求的时候，就分配一个线程去工作，如果刚好并发有101个请求，那多出的这一个请求可以排队等候，避免因无休止的创建线程导致系统崩溃。

（1）请求量大，任务执行时间短的业务，线程池线程数可以设置为少一些（以CPU核数+1为准），减少线程上下文的切换
（2）无论请求量大小，任务执行时间长的业务，解决这种类型任务的关键不在于线程池而在于整体架构的设计

• 第一步看看这些业务里面某些数据是否能做缓存

• 第二步增加服务器

• 第三步业务执行时间长的问题，也可能需要分析一下，看看能不能使用中间件（例mq）对任务进行拆分和解耦

• 第四步使用线程池，在实际开发中，如果是要求实时响应性比较高的系统，或者采用了类似Dubbo这种SOA微服务分布式的系统，一次请求的响应时间需要进行控制，这种情况下，如果代码执行到可能发生阻塞操作的地方（例如：查询数据量比较大的表、循环多次操作Redis Cache等），往往就可能出现服务超时的问题（Timeout Exception），对于具体情况，看是否需要使用1、2、3，也可以考虑采用线程池解决这个问题，使用线程池时主线程一般要各个子线程返回的结果。

  采用线程池的话，将线程池定义为全局静态对象，在方法中使用，可以将可预见的会发生阻塞操作的代码块部分放入线程池进行执行，如此这样，当主线程执行到线程池的部分，会执行线程池的run()方法，然后主线程会继续向下执行，直到最后直接返回结果，而阻塞的部分将在run()方法中执行，不会阻塞主线程的执行，这样可以达到一个异步非阻塞的快速响应

使用线程池时通常我们可以将执行的任务分为两类：

• cpu 密集型任务
• io 密集型任务

cpu 密集型任务，需要线程长时间进行的复杂的运算，这种类型的任务需要少创建线程（以CPU核数+1为准），过多的线程将会频繁引起上文切换，降低任务处理处理速度

而 io 密集型任务，由于线程并不是一直在运行，可能大部分时间在等待 IO 读取/写入数据，增加线程数量可以提高并发度，尽可能多处理任务