线程池笔记

线程池

  • 低资源消耗,降低了频繁创建线程和销毁线程的开销
  • 提高响应速度
  • 提高线程的可管理性,可以对线程进行一些操作,方便管理线程
线程池原理
image
线程池运行过程
image

线程池实现代码(阿里规范)

 /**
     * 响应阿里规范用线程池替换线程
     */
    private ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("demo-pool-%d").build();
    private ExecutorService executorTask = new ThreadPoolExecutor(5, 200, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>(1024), threadFactory, new ThreadPoolExecutor.AbortPolicy());
    //任务函数
    executorTask.execute(new Runnable() {
                @Override
                public void run() {
                    ResultResponse res = autoTestTools.runScene(entity);
                    if (res.isSuccess()) {
                        redisClient.set(scene.getTaskId() + "COPY", "true", "XX", "EX", overTime);
                    }
                }
            });

线程池重要的参数

  • corePoolSize 线程池核心线程大小

线程池中会维护一个最小的线程数量,即使这些线程处理空闲状态,他们也不会 被销毁,除非设置了allowCoreThreadTimeOut。这里的最小线程数量即是corePoolSize。

  • maximumPoolSize 线程池最大线程数量

一个任务被提交到线程池后,首先会缓存到工作队列(后面会介绍)中,如果工作队列满了,则会创建一个新线程,然后从工作队列中的取出一个任务交由新线程来处理,而将刚提交的任务放入工作队列。线程池不会无限制的去创建新线程,它会有一个最大线程数量的限制,这个数量即由maximunPoolSize来指定。

  • keepAliveTime 空闲线程存活时间

一个线程如果处于空闲状态,并且当前的线程数量大于corePoolSize,那么在指定时间后,这个空闲线程会被销毁,这里的指定时间由keepAliveTime来设定

  • unit 空间线程存活时间单位

keepAliveTime的计量单位

  • workQueue 工作队列

新任务被提交后,会先进入到此工作队列中,任务调度时再从队列中取出任务。jdk中提供了四种工作队列:

  1. ArrayBlockingQueue
基于数组的有界阻塞队列,按FIFO排序。新任务进来后,会放到该队列的队尾,有界的数组可以防止资源耗尽问题。当线程池中线程数量达到corePoolSize后,再有新任务进来,则会将任务放入该队列的队尾,等待被调度。如果队列已经是满的,则创建一个新线程,如果线程数量已经达到maxPoolSize,则会执行拒绝策略。
  1. LinkedBlockingQuene
基于链表的无界阻塞队列(其实最大容量为Interger.MAX),按照FIFO排序。由于该队列的近似无界性,当线程池中线程数量达到corePoolSize后,再有新任务进来,会一直存入该队列,而不会去创建新线程直到maxPoolSize,因此使用该工作队列时,参数maxPoolSize其实是不起作用的。
  1. SynchronousQuene
一个不缓存任务的阻塞队列,生产者放入一个任务必须等到消费者取出这个任务。也就是说新任务进来时,不会缓存,而是直接被调度执行该任务,如果没有可用线程,则创建新线程,如果线程数量达到maxPoolSize,则执行拒绝策略。
  1. PriorityBlockingQueue
具有优先级的无界阻塞队列,优先级通过参数Comparator实现。
  • threadFactory 线程工厂

创建一个新线程时使用的工厂,可以用来设定线程名、是否为daemon线程等等

  • handler 拒绝策略

当工作队列中的任务已到达最大限制,并且线程池中的线程数量也达到最大限制,这时如果有新任务提交进来,该如何处理呢。这里的拒绝策略,就是解决这个问题的,jdk中提供了4中拒绝策略:
1. CallerRunsPolicy
该策略下,在调用者线程中直接执行被拒绝任务的run方法,除非线程池已经shutdown,则直接抛弃任务。
2. AbortPolicy
该策略下,直接丢弃任务,并抛出RejectedExecutionException异常。
3. DiscardPolicy
该策略下,直接丢弃任务,什么都不做。
4. DiscardOldestPolicy
该策略下,抛弃进入队列最早的那个任务,然后尝试把这次拒绝的任务放入队列
5.

早期创建线程池方式

  • Executors#newCachedThreadPool => 创建可缓存的线程池

    1. corePoolSize => 0,核心线程池的数量为0

      maximumPoolSize => ==Integer.MAX_VALUE,可以认为最大线程数是无限的==

      keepAliveTime => 60L

      unit => 秒

      workQueue => SynchronousQueue
  • Executors#newSingleThreadExecutor => 创建单线程的线程池

    corePoolSize => 1,核心线程池的数量为1

    maximumPoolSize => 1,只可以创建一个非核心线程

    keepAliveTime => 0L

    unit => 秒

    ==workQueue => LinkedBlockingQueue==

    当一个任务提交时,首先会创建一个核心线程来执行任务,如果超过核心线程的数量,将会放入队列中,因为LinkedBlockingQueue是长度为Integer.MAX_VALUE的队列,可以认为是无界队列,因此往队列中可以插入无限多的任务,在资源有限的时候容易引起OOM异常,同时因为无界队列,maximumPoolSize和keepAliveTime参数将无效,压根就不会创建非核心线程

  • Executors#newFixedThreadPool => 创建固定长度的线程池

    corePoolSize => 1,核心线程池的数量为1

    maximumPoolSize => 1,只可以创建一个非核心线程

    keepAliveTime => 0L

    unit => 秒

    ==workQueue => LinkedBlockingQueue==

    它和SingleThreadExecutor类似,唯一的区别就是核心线程数不同,并且由于使用的是LinkedBlockingQueue,在资源有限的时候容易引起OOM异常

总结

FixedThreadPool和SingleThreadExecutor => 允许的请求队列长度为Integer.MAX_VALUE,可能会堆积大量的请求,从而引起OOM异常
CachedThreadPool => 允许创建的线程数为Integer.MAX_VALUE,可能会创建大量的线程,从而引起OOM异常

©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。