使用线程池的原因:
- 1.避免频繁的创建和销毁线程。
- 2.方便管理这些线程对象,如果无限制的创建线程和销毁线程不仅会浪费系统的资源,线程太多导致频繁切换线程,还会降低系统的稳定性。使用线程池可以进行统一的分配、调优和监控。
什么场景下使用:
如果线程的创建时间T1与销毁时间T2的总和对于线程运行时间T3来讲,比值较大,即(T1+T2)/T3比值较大,为了降低不必要的等待时间,提升线程复用性,可以使用线程池技术。
如何创建线程池
利用Executors创建不同的线程池满足不用场景的需求
1.newFixedThreadExecutor(n)
固定线程数量的线程池,每次最大只能有固定数量的线程同时执行任务,其余的线程只能进入等待队列中等待线程池中的线程执行完毕。
2.newSingleThreadExecutor
单个数量的线程池,每次最大只有一个线程执行任务,可保证所有线程都按顺序执行。
3.newCacheThreadExecutor
可缓存的线程池,不限制线程数量,默认缓存线程一定时间,当线程空闲时间达到阈值时自动销毁。适合用于处理大量短时间工作任务的线程池。
4.定时周期性调度的单个或多个线程池,根据不同的场景去选择不同的线程池。,上述这些线程池都是通过返回ThreadPoolExecutor或者ScheduledThreadPoolExecutor的实例来创建线程池的,所以在实际应用过程中也可以根据实际情况创建它们的实例,给他们传预定的参数如指定核心线程数、最大线程数、线程最大等待时间、线程池所用的任务缓冲队列等等常来自己创建线程池对象。
线程池工作原理:
- 如果当前线程数小于核心线程数,则创建新线程。
- 如果当前线程数等于核心线程数,且任务队列未满(无界队列永远也不会满,除非资源耗尽)时,将任务放入队列中。
- 如果当前线程数等于核心线程数,且任务队列已满。
- 3.1 若当前线程数小于最大线程数,则创建线程
- 3.2 若当前线程数等于最大线程数,则会执行拒绝策略。
线程池线参数配置:
- 核心线程数配置:分析应用属于哪种类型,如果是CPU密集型,则可配置核心线程数为N+1,因为CPU密集型本身对CPU的利用比较充分,切换线程对CPU的利用率也没什么提升空间,所以一般核心线程数为N+1。如果是IO密集型,可配置大一点,一般为2N左右。根据8020原则,假设每个任务处理需要0.1秒,若80%的情况下每秒任务数小于200,则核心线程数可设置为20。
- 任务队列的长度:任务队列长度跟核心线程数相关,也和客户端允许的等待时间有关。设置过长会导致任务响应时间过长。可设置为(核心线程数/每个任务花费的时间)*2。如上述中(20/0.1)2=400.
- 最大线程数:最大线程数与每秒最大任务量相关,可参考设置为: (每秒最大任务量-任务队列长度)*每个任务需要的时间,如上述中(1000-400)*0.1=60。若使用无界队列,那么这个参数将不起作用
- 线程空闲等待时间:这个参数应当根据任务峰值持续时间来设定。
- 线程等待时间单位TimeUnit:
- TimeUnit.DAYS:天
- TimeUnit.HOURS:小时
- TimeUnit.MINUTES:分
- TimeUnit.SECONDS:秒
- TimeUnit.MILLISECONDS:毫秒
- TimeUnit.MICROSECONDS:微妙
- TimeUnit.NANOSECONDS:纳秒
6. 线程池队列的选择:
SynchronousQueue:同步队列,队列中仅容纳一个元素,对其操作必须是放和取交替进行;
ArrayBlockingQueue:有界队列,初始化时必须指定容量大小,并且无法修改,先入先出原则。
LinkedBlockingQueue:无界队列,初始化时指定容量就是有界队列,未指定容量就是无边界的,其实是Integer.MAX_VALUE的容量,内部实现是链表,先入先出。
7. 线程池的四种策略:
AbortPolicy :丢弃任务并抛出异常,线程池默认的策略。
DiscardPolicy:丢弃任务单不抛出异常,静默抛弃。
DiscardOldestPolicy:丢弃队列最前面的任务,然后重新提交被拒绝的任务。
CallerRunsPolicy:由调用线程处理任务。
实际生产环境,可以根据自己业务需要,选择通过实现RejectedExecutionHandler接口来定义拒绝策略。比如把线程池无法执行的任务信息持久化写入到数据库去,后台专门启动一个线程,后续等待线程池的工作负载降低了,这个后台线程就可以慢慢的从磁盘里读取任务重新提交到线程池中。
总结:以上参数的设定在实际应当考虑cpu的性能在内,如果线程数达到50时cpu使用率就已经很高了,那最大线程数不应超过50,此时应设法降低每个任务处理的时间,或者降低任务并发量。