Executor与线程池

有没有思考过,为什么要用线程池?

想必你已经猜到,Java创建对象,仅在JVM堆中分配一块内存,创建线程,却需要调用操作系统API,操作系统再分配一系列资源,是一个非常耗时,好资源的过程。惯用思想,池化资源,得到共用。

想法没错,但是java的自带的线程池并不是采用池化资源来设计的,而是生产者-消费者模式。

Java 提供的线程池相关的工具类中,最核心的是ThreadPoolExecutor,下图是ThreadPollExecutor跟上游类之间的关系我已经列出

如何在IDEA中查看类图 参考:https://www.cnblogs.com/amberJava/p/12420875.html

 其中红框是最完备的方法。具体含义,

  • corePoolSize:表示线程池保有的最小线程数。有些项目很闲,但是也不能把人都撤了,至少要留 corePoolSize 个人坚守阵地。
  • maximumPoolSize:表示线程池创建的最大线程数。当项目很忙时,就需要加人,但是也不能无限制地加,最多就加到 maximumPoolSize 个人。当项目闲下来时,就要撤人了,最多能撤到 corePoolSize 个人。
  • keepAliveTime & unit:上面提到项目根据忙闲来增减人员,那在编程世界里,如何定义忙和闲呢?很简单,一个线程如果在一段时间内,都没有执行任务,说明很闲,keepAliveTime 和 unit 就是用来定义这个“一段时间”的参数。也就是说,如果一个线程空闲了keepAliveTime & unit这么久,而且线程池的线程数大于 corePoolSize ,那么这个空闲的线程就要被回收了。
  • workQueue:工作队列,和上面示例代码的工作队列同义。
  • threadFactory:通过这个参数你可以自定义如何创建线程,例如你可以给线程指定一个有意义的名字。
  • handler:通过这个参数你可以自定义任务的拒绝策略。如果线程池中所有的线程都在忙碌,并且工作队列也满了(前提是工作队列是有界队列),那么此时提交任务,线程池就会拒绝接收。至于拒绝的策略,你可以通过 handler 这个参数来指定。ThreadPoolExecutor 已经提供了以下 4 种策略。
    • CallerRunsPolicy:提交任务的线程自己去执行该任务。
    • AbortPolicy:默认的拒绝策略,会 throws RejectedExecutionException。
    • DiscardPolicy:直接丢弃任务,没有任何异常抛出。
    • DiscardOldestPolicy:丢弃最老的任务,其实就是把最早进入工作队列的任务丢弃,然后把新任务加入到工作队列。

不过不建议使用 Executors 的最重要的原因是:Executors 提供的很多方法默认使用的都是无界的 LinkedBlockingQueue,高负载情境下,无界队列很容易导致 OOM,而 OOM 会导致所有请求都无法处理,这是致命问题。所以强烈建议使用有界队列

列出了默认的几个创建线程池的方法。

那么在使用线程池需要注意哪些方面呢?

1.使用有界队列时,当任务过多时,线程池会触发执行拒绝策略,线程池默认的拒绝策略会 throw RejectedExecutionException 这是个运行时异常,对于运行时异常编译器并不强制 catch 它,所以开发人员很容易忽略。所以默认策略慎用,建议根据实际情况,用自己的策略

2.考虑执行线程遇到的各种异常,最稳妥和简单的方案还是捕获所有异常并按需处理。

猜你喜欢

转载自www.cnblogs.com/amberJava/p/12421250.html