Java线程池配置的一些常见误区总结

前言

由于线程的创建和销毁对操作系统来说都是比较重量级的操作,所以线程的池化在各种语言内都有实践,当然在 Java 语言中线程池是也非常重要的一部分,有 Doug Lea 大神对线程池的封装,我们使用的时候是非常方便,但也可能会因为不了解其具体实现,对线程池的配置参数存在误解。

我们经常在一些技术书籍或博客上看到,向线程池提交任务时,线程池的执行逻辑如下:

当一个任务被提交后,线程池首先检查正在运行的线程数是否达到核心线程数,如果未达到则创建一个线程。
如果线程池内正在运行的线程数已经达到了核心线程数,任务将会被放到 BlockingQueue 内。
如果 BlockingQueue 已满,线程池将会尝试将线程数扩充到最大线程池容量。
如果当前线程池内线程数量已经达到最大线程池容量,则会执行拒绝策略拒绝任务提交。
流程如图(摘自美团技术博客):

流程描述没有问题,但如果某些点未经过推敲,容易导致误解,而且描述中的情境太理想化,如果配置时不考虑运行时环境,也会出现一些非常诡异的问题。

转载随意,文章会持续修订,请注明来源地址: https://zhenbianshu.github.io

核心池

线程池内线程数量小于等于 coreSize 的部分我称为核心池,核心池是线程池的常驻部分,内部的线程一般不会被销毁,我们提交的任务也应该绝大部分都由核心池内的线程来执行。

线程创建时机的误解

有关核心池最常见的一个误区是没搞清楚核心池内线程的创建时机,这个问题,我觉得甩 10% 的锅给 Doug Lea 大神应该不算过分,因为他在文档里写道 “If fewer than corePoolSize threads are running, try to start a new thread with the given command as its first task”,其中 "running" 这个词就比较有歧义,因为在我们理解里 running 是指当前线程已被操作系统调度,拥有操作系统时间分片,或者被理解为正在执行某个任务。

基于以上的理解,我们很容易就认为如果任务的 QPS 非常低,线程池内线程数量永远也达不到 coreSize。 即如果我们配置了 coreSize 为 1000,实际上 QPS 只有 1,单个任务耗时 1s,那么核心池大小就会一直是 1,即使有流量抖动,核心池也只会被扩容到 3。因为一个线程每秒执行执行一个任务,刚好不用创建新线程就足以应对 1QPS。

创建过程

但如果简单设计一个测试,使用 jstack 打印出线程栈并数一下线程池内线程数量,会发现线程池内的线程数会随着任务的提交而逐渐增大,直到达到 coreSize。

因为核心池的设计初衷是想它能作为常驻池,承载日常流量,所以它应该被尽快初始化,于是线程池的逻辑是在没有达到 coreSize 之前,每一个任务都会创建一个新的线程,对应的源码为:

public void execute(Runnable command) {
  ...
  int c = ctl.get();
  if (workerCountOf(c) < corePoolSize) { // workerCountOf() 方法是获取线程池内线程数量
   if (addWorker(command, true))
    return;
   c = ctl.get();
  }
  ...
 }

而文档里的 running 状态也指的是线程已经被创建,我们也知道线程被创建后,会在一个 while 循环里尝试从 BlockingQueue 里获取并执行任务,说它正在 running 也不为过。

基于此,我们对一些高并发服务进行的预热,其实并不是期望 JVM 能对热点代码做 JIT 等优化,对线程池、连接池和本地缓存的预热才是重点。

BlockingQueue

BlockingQueue 是线程池内的另一个重要组件,首先它是线程池”生产者-消费者”模型的中间媒介,另外它也可以为大量突发的流量做缓冲,但理解和配置它也经常会出错。

运行模型

最常见的错误是不理解线程池的运行模型。首先要明确的一点是线程池并没有准确的调度功能,即它无法感知有哪些线程是处于空闲状态的,并把提交的任务派发给空闲线程。线程池采用的是”生产者-消费者”模式,除了触发线程创建的任务(线程的 firstTask)不会入 BlockingQueue 外,其他任务都要进入到 BlockingQueue,等待线程池内的线程消费,而任务会被哪个线程消费到完全取决于操作系统的调度。

对应的生产者源码如下:

public void execute(Runnable command) {
  ...
  if (isRunning(c) && workQueue.offer(command)) { isRunning() 是判断线程池处理戚状态
   int recheck = ctl.get();
   if (! isRunning(recheck) && remove(command))
    reject(command);
   else if (workerCountOf(recheck) == 0)
    addWorker(null, false);
  }
  ...
 }

对应的消费者源码如下:

private Runnable getTask() {
  for (;;) {
   ...
   Runnable r = timed ?
    workQueue.poll(keepAliveTime, TimeUnit.NANOSECONDS) :
    workQueue.take();
   if (r != null)
    return r;
   ...
  }
 }

BlockingQueue 的缓冲作用

基于”生产者-消费者”模型,我们可能会认为如果配置了足够的消费者,线程池就不会有任何问题。其实不然,我们还必须考虑并发量这一因素。

设想以下情况:有 1000 个任务要同时提交到线程池内并发执行,在线程池被初始化完成的情况下,它们都要被放到 BlockingQueue 内等待被消费,在极限情况下,消费线程一个任务也没有执行完成,那么这 1000 个请求需要同时存在于 BlockingQueue 内,如果配置的 BlockingQueue Size 小于 1000,多余的请求就会被拒绝。

那么这种极限情况发生的概率有多大呢?答案是非常大,因为操作系统对 I/O 线程的调度优先级是非常高的,一般我们的任务都是由 I/O 的准备或完成(如 tomcat 受理了 http 请求)开始的,所以很有可能被调度到的都是 tomcat 线程,它们在一直往线程池内提交请求,而消费者线程却调度不到,导致请求堆积。

我负责的服务就发生过这种请求被异常拒绝的情况,压测时 QPS 2000,平均响应时间为 20ms,正常情况下,40 个线程就可以平衡生产速度,不会堆积。但在 BlockingQueue Size 为 50 时,即使线程池 coreSize 为 1000,还会出现请求被线程池拒绝的情况。

这种情况下,BlockingQueue 的重要的意义就是它是一个能长时间存储任务的容器,能以很小的代价为线程池提供缓冲。根据上文可知,线程池能支持 BlockingQueue Size 个任务同时提交,我们把最大同时提交的任务个数,称为并发量,配置线程池时,了解并发量异常重要。

并发量的计算

我们常用 QPS 来衡量服务压力,所以配置线程池参数时也经常参考这个值,但有时候 QPS 和并发量有时候相关性并没有那么高,QPS 还要 搭配任务执行时间 来 推算 峰值并发量。

比如请求间隔严格相同的接口,平均 QPS 为 1000,它的并发量峰值是多少呢?我们并没有办法估算,因为如果任务执行时间为 1ms,那么它的并发量只有 1;而如果任务执行时间为 1s,那么并发量峰值为 1000。

可是知道了任务执行时间,就能算出并发量了吗?也不能,因为如果请求的间隔不同,可能 1min 内的请求都在一秒内发过来,那这个并发量还要乘以 60,所以上面才说知道了 QPS 和任务执行时间,并发量也只能靠推算。

计算并发量,我一般的经验值是 QPS*平均响应时间 ,再留上一倍的冗余,但如果业务重要的话,BlockingQueue Size 设置大一些也无妨(1000 或以上),毕竟每个任务占用的内存量很有限。

考虑运行时

GC

除了上面提到的各种情况下,GC 也是一个很重要的影响因素。

我们都知道 GC 是 Stop the World 的,但这里的 World 指的是 JVM,而一个请求 I/O 的准备和完成是操作系统在进行的,JVM 停止了,但操作系统还是会正常受理请求,在 JVM 恢复后执行,所以 GC 是会堆积请求的。

上文中提到的并发量计算一定要考虑到 GC 时间内堆积的请求同时被受理的情况,堆积的请求数可以通过 QPS*GC时间 来简单得出,还有一定要记得留出冗余。

业务峰值

除此之外,配置线程池参数时,一定要考虑业务场景。

假如接口的流量大部分来自于一个定时程序,那么平均 QPS 就没有了任何意义,线程池设计时就要考虑给 BlockingQueue 的 Size 设置一个大一些的值;而如果流量非常不平均,一天内只有某一小段时间才有高流量的话,而且线程资源紧张的情况下,就要考虑给线程池的 maxSize 留下较大的冗余;在流量尖刺明显而响应时间不那么敏感时,也可以设置较大的 BlockingQueue,允许任务进行一定程度的堆积。

当然除了经验和计算外,对服务做定时的压测无疑更能帮助掌握服务真实的情况。

小结

总结线程池的配置时,我最大的感受是一定要读源码!读源码!读源码!只看一些书和文章的总结是无法吃透一些重要概念的,即使搞懂了大部分也很容易会在一些角落踩坑。深入理解原理后,面对复杂情况,才有灵活配置的能力。

线程池可讨论的点有很多,本文应该会持续修订,请关注原文。

到此这篇关于Java线程池配置的一些常见误区的文章就介绍到这了,更多相关Java线程池配置误区内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

参考文献:

Java线程池实现原理及其在美团业务中的实践

(0)

相关推荐

  • Java中四种线程池的使用示例详解

    在什么情况下使用线程池? 1.单个任务处理的时间比较短 2.将需处理的任务的数量大 使用线程池的好处: 1.减少在创建和销毁线程上所花的时间以及系统资源的开销 2.如不使用线程池,有可能造成系统创建大量线程而导致消耗完系统内存以及"过度切换". 本文详细的给大家介绍了关于Java中四种线程池的使用,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍: FixedThreadPool 由Executors的newFixedThreadPool方法创建.它是一种线程数量固定的线程

  • java线程池使用后到底要关闭吗

    线程池做什么 网络请求通常有两种形式: 第一种,请求不是很频繁,而且每次连接后会保持相当一段时间来读数据或者写数据,最后断开,如文件下载,网络流媒体等. 另一种形式是请求频繁,但是连接上以后读/写很少量的数据就断开连接.考虑到服务的并发问题,如果每个请求来到以后服务都为它启动一个线程,那么这对服务的资源可能会造成很大的浪费,特别是第二种情况. 因为通常情况下,创建线程是需要一定的耗时的,设这个时间为T1,而连接后读/写服务的时间为T2,当T1>>T2时,我们就应当考虑一种策略或者机制来控制,使

  • java中通用的线程池实例代码

    复制代码 代码如下: package com.smart.frame.task.autoTask; import java.util.Collection;import java.util.Vector; /** * 任务分发器 */public class TaskManage extends Thread{    protected Vector<Runnable> tasks = new Vector<Runnable>();    protected boolean run

  • 四种Java线程池用法解析

    本文为大家分析四种Java线程池用法,供大家参考,具体内容如下 1.new Thread的弊端 执行一个异步任务你还只是如下new Thread吗? new Thread(new Runnable() { @Override public void run() { // TODO Auto-generated method stub } } ).start(); 那你就out太多了,new Thread的弊端如下: a. 每次new Thread新建对象性能差. b. 线程缺乏统一管理,可能无限

  • java简单实现多线程及线程池实例详解

    本文为大家分享了java多线程的简单实现及线程池实例,供大家参考,具体内容如下 一.多线程的两种实现方式 1.继承Thread类的多线程 /** * 继承Thread类的多线程简单实现 */ public class extThread extends Thread { public void run(){ for(int i=0;i<100;i++){ System.out.println(getName()+"-"+i); } } public static void mai

  • 深入java线程池的使用详解

    在Java 5.0之前启动一个任务是通过调用Thread类的start()方法来实现的,任务的提于交和执行是同时进行的,如果你想对任务的执行进行调度或是控制 同时执行的线程数量就需要额外编写代码来完成.5.0里提供了一个新的任务执行架构使你可以轻松地调度和控制任务的执行,并且可以建立一个类似数据库连接 池的线程池来执行任务.这个架构主要有三个接口和其相应的具体类组成.这三个接口是Executor, ExecutorService.ScheduledExecutorService,让我们先用一个图

  • Java实现终止线程池中正在运行的定时任务

    最近项目中遇到了一个新的需求,就是实现一个可以动态添加定时任务的功能.说到这里,有人可能会说简单啊,使用quartz就好了,简单粗暴.然而quartz框架太重了,小项目根本不好操作啊.当然,也有人会说,jdk提供了timer的接口啊,完全够用啊.但是我们项目的需求完全是多线程的模型啊,而timer是单线程的,so,楼主最后还是选择了jdk的线程池. 线程池是什么 Java通过Executors提供四种线程池,分别为: newCachedThreadPool :创建一个可缓存线程池,如果线程池长度

  • 详谈Java几种线程池类型介绍及使用方法

    一.线程池使用场景 •单个任务处理时间短 •将需处理的任务数量大 二.使用Java线程池好处 1.使用new Thread()创建线程的弊端: •每次通过new Thread()创建对象性能不佳. •线程缺乏统一管理,可能无限制新建线程,相互之间竞争,及可能占用过多系统资源导致死机或oom. •缺乏更多功能,如定时执行.定期执行.线程中断. 2.使用Java线程池的好处: •重用存在的线程,减少对象创建.消亡的开销,提升性能. •可有效控制最大并发线程数,提高系统资源的使用率,同时避免过多资源竞

  • Java线程池的几种实现方法及常见问题解答

    工作中,经常会涉及到线程.比如有些任务,经常会交与线程去异步执行.抑或服务端程序为每个请求单独建立一个线程处理任务.线程之外的,比如我们用的数据库连接.这些创建销毁或者打开关闭的操作,非常影响系统性能.所以,"池"的用处就凸显出来了. 1. 为什么要使用线程池 在3.6.1节介绍的实现方式中,对每个客户都分配一个新的工作线程.当工作线程与客户通信结束,这个线程就被销毁.这种实现方式有以下不足之处: •服务器创建和销毁工作的开销( 包括所花费的时间和系统资源 )很大.这一项不用解释,可以

  • Java 线程池详解及实例代码

    线程池的技术背景 在面向对象编程中,创建和销毁对象是很费时间的,因为创建一个对象要获取内存资源或者其它更多资源.在Java中更是如此,虚拟机将试图跟踪每一个对象,以便能够在对象销毁后进行垃圾回收. 所以提高服务程序效率的一个手段就是尽可能减少创建和销毁对象的次数,特别是一些很耗资源的对象创建和销毁.如何利用已有对象来服务就是一个需要解决的关键问题,其实这就是一些"池化资源"技术产生的原因. 例如Android中常见到的很多通用组件一般都离不开"池"的概念,如各种图片

随机推荐