ElasticSearch 线程池类型分析之SizeBlockingQueue

尽管前面写好几篇ES线程池分析的文章(见文末参考链接),但都不太满意。但从ES的线程池中了解到了不少JAVA线程池的使用技巧,于是忍不住再写一篇(ES6.3.2版本的源码)。文中给出的每个代码片断,都标明了这些代码是来自哪个类的哪个方法。

ElasticSearch里面一共有四种类型的线程池,源码:ThreadPool.ThreadPoolType

        DIRECT("direct"),
FIXED("fixed"),
FIXED_AUTO_QUEUE_SIZE("fixed_auto_queue_size"),
SCALING("scaling");

GET、SEARCH、WRITE、INDEX、FLUSH...等各种操作是交由这些线程池实现的。为什么定义不同类型的线程池呢?举个最简单的例子:程序里面有IO密集型任务,也有CPU密集型任务,这些任务都提交到一个线程池中执行?还是根据任务的执行特点将CPU密集型的任务都提交到一个线程池,IO密集型任务都提交到另一个线程池执行?

不同种类的操作(INDEX、SEARCH...)交由不同类型的线程池执行是有很多好处的:

  1. 互不影响:INDEX操作频繁时,并不会影响SEARCH操作的执行。
  2. 资源合理利用(提升性能):如果只有一个线程池来处理所有的操作,线程池队列长度配置为多大合适?线程的数量配置多少合适?这些操作难道都要共用一个拒绝策略吗?线程执行过程中出现异常了,针对不同类型的操作,异常处理方案也是不一样的,显然:只有一个线程池(或者说只有一种类型的线程池),是无法满足这些需求的。

再来说一下ES中的线程池都是如何创建的?

ES节点启动时,执行Node类的构造方法 :org.elasticsearch.node.Node.Node(org.elasticsearch.env.Environment, java.util.Collection<java.lang.Class<? extends org.elasticsearch.plugins.Plugin>>)

final ThreadPool threadPool = new ThreadPool(settings, executorBuilders.toArray(new ExecutorBuilder[0]));

new ThreadPool对象,从这里开始创建线程池。看懂了ThreadPool类,就理解了ES线程池的一半。

每个操作都有一个线程池,每个线程池都有一个相应的 ExecutorBuilder 对象,线程池都是通过ExecutorBuilder类的build()方法创建的。

在org.elasticsearch.threadpool.ThreadPool.ThreadPool的构建函数里面创建各种ExecutorBuilder对象。可以看出:INDEX操作的线程池的 ExecutorBuilder对象实际类型是FixedExecutorBuilder

 builders.put(Names.GENERIC, new ScalingExecutorBuilder(Names.GENERIC, 4, genericThreadPoolMax, TimeValue.timeValueSeconds(30)));
builders.put(Names.INDEX, new FixedExecutorBuilder(settings, Names.INDEX, availableProcessors, 200, true));
builders.put(Names.WRITE, new FixedExecutorBuilder(settings, Names.WRITE, "bulk", availableProcessors, 200));
builders.put(Names.GET, new FixedExecutorBuilder(settings, Names.GET, availableProcessors, 1000));
builders.put(Names.ANALYZE, new FixedExecutorBuilder(settings, Names.ANALYZE, 1, 16));
builders.put(Names.SEARCH, new AutoQueueAdjustingExecutorBuilder(settings,
Names.SEARCH, searchThreadPoolSize(availableProcessors), 1000, 1000, 1000, 2000));

如上代码所示,虽然ES为我们内置好了许多线程池(GENERIC、INDEX、WRITE、GET...),但还可以自定义 ExecutorBuilder对象,创建自定义的线程池。所有的ExecutorBuilder对象创建完毕后,保存到一个HashMap里面。

        for (final ExecutorBuilder<?> builder : customBuilders) {
if (builders.containsKey(builder.name())) {
throw new IllegalArgumentException("builder with name [" + builder.name() + "] already exists");
}
builders.put(builder.name(), builder);
}

最后,遍历builders 这个HashMap 取出 ExecutorBuilder对象,调用它的build()方法创建线程池

        for (@SuppressWarnings("unchecked") final Map.Entry<String, ExecutorBuilder> entry : builders.entrySet()) {
final ExecutorBuilder.ExecutorSettings executorSettings = entry.getValue().getSettings(settings);
//这里执行build方法创建线程池
final ExecutorHolder executorHolder = entry.getValue().build(executorSettings, threadContext);
if (executors.containsKey(executorHolder.info.getName())) {
throw new IllegalStateException("duplicate executors with name [" + executorHolder.info.getName() + "] registered");
}
logger.debug("created thread pool: {}", entry.getValue().formatInfo(executorHolder.info));
executors.put(entry.getKey(), executorHolder);
}

创建INDEX操作的线程池需要指定任务队列,这个任务队列就是:SizeBlockingQueue。当然了,也有一些其他操作(比如GET操作)的线程池的任务队列也是SizeBlockingQueue。

下面参数可看出:该任务队列的长度为200,org.elasticsearch.threadpool.ThreadPool.ThreadPool的构造方法:

    builders.put(Names.INDEX, new FixedExecutorBuilder(settings, Names.INDEX, availableProcessors, 200, true));

前面已经提到了,每个线程池都由ExecutorBuilder的build方法创建的。具体到INDEX操作的线程池,它的ExecutorBuilder实例对象是: FixedExecutorBuilder对象,在ExecutorBuilder 保存一些线程池参数信息:(core pool size、max pool size、queue size...)

final ExecutorService executor =
EsExecutors.newFixed(settings.nodeName + "/" + name(), size, queueSize, threadFactory, threadContext);

如果queue_size配置为 -1,那就是一个无界队列(LinkedTransferQueue)。我们是可以修改线程池配置参数的:关于线程池队列长度的配置信息参考:官方文档threadpool

而INDEX操作对应的线程池的任务队列长度为200,因此下面代码创建了一个长度为200的 SizeBlockingQueue,在代码最后一行,为该线程池指定的拒绝策略是 EsAbortPolicy

    public static EsThreadPoolExecutor newFixed(String name, int size, int queueCapacity, ThreadFactory threadFactory, ThreadContext contextHolder) {
BlockingQueue<Runnable> queue;
if (queueCapacity < 0) {
queue = ConcurrentCollections.newBlockingQueue();
} else {
queue = new SizeBlockingQueue<>(ConcurrentCollections.<Runnable>newBlockingQueue(), queueCapacity);
}
return new EsThreadPoolExecutor(name, size, size, 0, TimeUnit.MILLISECONDS, queue, threadFactory, new EsAbortPolicy(), contextHolder);
}

下面开始分析SizeBlockingQueue的源码:

一般在自定义线程池时,要么是直接 new ThreadPoolExecutor,要么是继承ThreadPoolExecutor,在创建ThreadPoolExecutor对象时需要指定线程池的配置参数。比如,线程池的核心线程数(core pool size),最大线程数,任务队列,拒绝策略。这里我想提一下拒绝策略,因为某些ES的操作具有"强制"执行的特点:如果某个任务被标记为强制执行,那么向线程池提交该任务时,就不能拒绝它。是不是很厉害?想想,线程池是如何做到的?

下面举个例子:

//创建任务队列,这里没有指定任务队列的长度,那么这就是一个无界队列
private BlockingQueue<Runnable> taskQueue = new LinkedBlockingQueue<>();
//创建线程工厂,由它来创建线程
private ThreadFactory threadFactory = new ThreadFactoryBuilder().setNameFormat("thread-%d").setUncaughtExceptionHandler(exceptionHandler).build(); //创建线程池,核心线程数为4,最大线程数为16
private ThreadPoolExecutor executor = new ThreadPoolExecutor(4, 16, 1, TimeUnit.DAYS, taskQueue, threadFactory, rejectExecutionHandler);

这里创建的线程池,它的线程数量永远不可能达到最大线程数量16,为什么?因为我们的任务队列是一个无界队列,当向线程池中提交任务时,LinkedBlockingQueue.offer方法不会返回false。而在JDK源码java.util.concurrent.ThreadPoolExecutor.execute中,当任务入队列失败返回false时,才有可能触发addWork创建新线程。这个时候,你可能会说:在 new LinkedBlockingQueue的时候指定队列长度不就完了?比如这样指定队列长度为1024

private BlockingQueue<Runnable> taskQueue = new LinkedBlockingQueue<>(1024);

但是,有没有一种方法,能够做到:当core pool size 个核心线程数处理不过来时,先让线程池的线程数量创建到最大值(max pool size),然后,若还有任务提交到线程池,则让任务排队等待处理?SizeBlockingQueue 重写了BlockingQueue的offer方法,实现了这个功能。

另外,我再反问一下?如何确定1024就是一个合适的队列容量?万一提交任务速度很快,一下子任务队列就满了,长度1024就会导致大量的任务被拒绝。

ES中的 ResizableBlockingQueue 实现了一种可动态调整队列长度的任务队列,有兴趣的可以去研究一下。

SizeBlockingQueue 封装了 LinkedTransferQueue,而 LinkedTransferQueue 是一个无界队列,与LinkedBlockingQueue不同的是,LinkedTransferQueue的构造方法是不能指定任务队列的长度(capacity)的。因此,SizeBlockingQueue定义一个capacity属性提供了队列有界的功能。

好,来看看SizeBlockingQueue是如何重写offer方法的:org.elasticsearch.common.util.concurrent.SizeBlockingQueue.offer(E)

    @Override
public boolean offer(E e) {
while (true) {
//获取当前任务队列的长度,即:当前任务队列里面有多少个任务正在排队等待执行
final int current = size.get();
//如果正在等待排队的任务数量大于等于任务队列长度的最大值(容量),
//返回false 就有可能 触发 java.util.concurrent.ThreadPoolExecutor.addWorker 调用创建新线程
if (current >= capacity()) {
return false;
} //当前正在排队的任务数量尚未超过队列的最大长度,使用CAS 先将任务队列长度加1,[CAS的经典用法]
if (size.compareAndSet(current, 1 + current)) {
break;
}
}
//将任务添加到队列
boolean offered = queue.offer(e);
if (!offered) {
//如果未添加成功,再把数量减回去即可
size.decrementAndGet();
}
return offered;
}

上面,就是通过先判断当前排队的任务是否小于任务队列的最大长度(容量) 来实现:优先创建线程数量到 max pool size。下面来模拟一下使用 SizeBlockingQueue 时处理任务的步骤:

根据前面的介绍:线程池 core pool size=4,max pool size=16,taskQueue 是 SizeBlockingQueue,任务队列的最大长度是200

1,提交1-4号 四个任务给线程池,线程池创建4个线程处理这些任务

2,1-4号 四个任务正在执行中...此时又提交了8个任务到线程池

3,这时,线程池是再继续创建8个线程,处理 5-12号任务。此时,线程池中一共有4+8=12个线程,小于max pool size

4,假设 1-12号任务都正在处理中,此时又提交了8个任务到线程池

5,这时,线程池会再创建4个新线程处理其中的13-16号 这4个任务,线程数量已经达到max pool size,不能再创建新线程了,还有4个任务(17-20号)入队列排队等待。

有没有兴趣模拟一下使用LinkedBlockingQueue作为任务队列时,线程池又是如何处理这一共提交的20个任务的?

最后来分析一下 SizeBlockingQueue 如何支持:当向线程池提交任务时,如果任务被某种拒绝策略拒绝了,如果这种任务又很重要,那能不能强制将该任务提交到线程池的任务队列中呢?

这里就涉及到:在创建线程池时,为线程池配置了何种拒绝策略了。下面以INDEX操作的线程池为例说明:

在org.elasticsearch.common.util.concurrent.EsExecutors.newFixed 中:可知该线程池所使用的拒绝策略是:EsAbortPolicy

return new EsThreadPoolExecutor(name, size, size, 0, TimeUnit.MILLISECONDS, queue, threadFactory, new EsAbortPolicy(), contextHolder);

看 EsAbortPolicy 的源码:org.elasticsearch.common.util.concurrent.EsAbortPolicy.rejectedExecution

if (r instanceof AbstractRunnable) {
//判断该任务是不是一个 可强制提交的任务
if (((AbstractRunnable) r).isForceExecution()) {
BlockingQueue<Runnable> queue = executor.getQueue();
if (!(queue instanceof SizeBlockingQueue)) {
throw new IllegalStateException("forced execution, but expected a size queue");
}
//是一个可强制提交的任务,并且 线程池的任务队列是 SizeBlockingQueue时,强制提交任务
try {
((SizeBlockingQueue) queue).forcePut(r);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new IllegalStateException("forced execution, but got interrupted", e);
}
return;
}
}
rejected.inc();
//任务被拒绝且未能强制执行, 抛出EsRejectedExecutionException异常后,会被 EsThreadPoolExecutor.doExecute catch, 进行相应的处理
throw new EsRejectedExecutionException("rejected execution of " + r + " on " + executor, executor.isShutdown());

AbstractRunnable 是提交的Runnable任务,只要Runnable任务的 isForceExecution()返回true,就表明这个任务需要“强制提交”。关于AbstractRunnable,可参考:Elasticsearch中各种线程池分析

那为什么只有当任务队列是 SizeBlockingQueue 时,才可以强制提交呢?这很好理解:首先SizeBlockingQueue它封装了LinkedTransferQueue,LinkedTransferQueue本质上是一个无界队列,实际上可以添加无穷多个任务(不考虑OOM),只不过是用 capacity 属性限制了队列的长度而已。

如果,任务队列是 new LinkedBlockingQueue<>(1024),肯定是不能支持强制提交的,因为当LinkedBlockingQueue长度达到1024后,再提交任务,直接返回false了。从这里也可以借鉴ES线程池任务队列的设计方式,应用到项目中去。

综上:只有Runnable任务 isForceExecution返回true,并且线程池的任务队列是SizeBlockingQueue时,向线程池提交任务时,总是能提交成功(强制执行机制保证)。其他情况下,任务被拒绝时,会抛出EsRejectedExecutionException异常。

强制提交,把任务添加到任务队列 SizeBlockingQueue 中,源码如下:

org.elasticsearch.common.util.concurrent.SizeBlockingQueue.forcePut

    /**
* Forces adding an element to the queue, without doing size checks.
*/
public void forcePut(E e) throws InterruptedException {
size.incrementAndGet();
try {
queue.put(e);
} catch (InterruptedException ie) {
size.decrementAndGet();
throw ie;
}
}

总结:

ES会为每种操作创建一个线程池,本文基于INDEX操作分析了ES中线程池的任务队列SizeBlockingQueue。对于 INDEX 操作而言,它的线程池是由org.elasticsearch.threadpool.FixedExecutorBuilder 的build方法创建的,线程池的最大核心线程数和最大线程数相同,使用的任务队列是 SizeBlockingQueue,长度为200,拒绝策略是:org.elasticsearch.common.util.concurrent.EsAbortPolicy。

为什么要为不同的操作分配不同的线程池呢?

假设 index 操作 和 snapshot 操作使用同一个线程池,如果某节点发生故障,index操作被阻塞了,而 Client发起的索引文档操作的 QPS又很高,就很容易影响 snapshot 服务了。

SizeBlockingQueue 本质上是一个 LinkedTransferQueue,其实ES中所有的任务队列都是封装LinkedTransferQueue实现的,并没有使用LinkedBlockingQueue。

ES中的所有任务(Runnable)都是基于org.elasticsearch.common.util.concurrent.AbstractRunnable这个抽象类封装的,当然有一些任务是通过Lambda表达式的形式提交的。任务的具体处理逻辑在 org.elasticsearch.common.util.concurrent.AbstractRunnable#doRun 方法中,任务执行完成由onAfter()处理,执行出现异常由onFailure()处理。线程池的 org.elasticsearch.common.util.concurrent.EsThreadPoolExecutor#doExecute 方法 里面就是整个任务的处理流程:

    protected void doExecute(final Runnable command) {
try {
super.execute(command);
} catch (EsRejectedExecutionException ex) {
if (command instanceof AbstractRunnable) {
// If we are an abstract runnable we can handle the rejection
// directly and don't need to rethrow it.
try {
((AbstractRunnable) command).onRejection(ex);
} finally {
((AbstractRunnable) command).onAfter(); }
} else {
throw ex;
}
}
}

最后,ES的线程池模块代码主要在 org.elasticsearch.threadpool 和 org.elasticsearch.common.util.concurrent 包下。总体来说,threadpool模块相比于ES的其他模块,是一个小模块,代码不算复杂。但是threadpool又很重要,因为它是其他模块执行逻辑的基础,threadpool 再配上异步执行机制,是ES源码中其他操作的源码实现思路。

参考:

探究ElasticSearch中的线程池实现

Elasticsearch中各种线程池分析

ElasticSearch 线程池类型分析之SizeBlockingQueue的更多相关文章

  1. ElasticSearch 线程池类型分析之 ExecutorScalingQueue

    ElasticSearch 线程池类型分析之 ExecutorScalingQueue 在ElasticSearch 线程池类型分析之SizeBlockingQueue这篇文章中分析了ES的fixed ...

  2. ElasticSearch 线程池类型分析之 ResizableBlockingQueue

    ElasticSearch 线程池类型分析之 ResizableBlockingQueue 在上一篇文章 ElasticSearch 线程池类型分析之 ExecutorScalingQueue的末尾, ...

  3. JAVA线程池的分析和使用

    1. 引言 合理利用线程池能够带来三个好处.第一:降低资源消耗.通过重复利用已创建的线程降低线程创建和销毁造成的消耗.第二:提高响应速度.当任务到达时,任务可以不需要等到线程创建就能立即执行.第三:提 ...

  4. [转]ThreadPoolExecutor线程池的分析和使用

    1. 引言 合理利用线程池能够带来三个好处. 第一:降低资源消耗.通过重复利用已创建的线程降低线程创建和销毁造成的消耗. 第二:提高响应速度.当任务到达时,任务可以不需要等到线程创建就能立即执行. 第 ...

  5. EsRejectedExecutionException排错与线程池类型

    1.EsRejectedExecutionException异常示例 java.util.concurrent.ExecutionException: RemoteTransportException ...

  6. Java 线程池原理分析

    1.简介 线程池可以简单看做是一组线程的集合,通过使用线程池,我们可以方便的复用线程,避免了频繁创建和销毁线程所带来的开销.在应用上,线程池可应用在后端相关服务中.比如 Web 服务器,数据库服务器等 ...

  7. ThreadPoolExecutor线程池的分析和使用

    1. 引言 合理利用线程池能够带来三个好处. 第一:降低资源消耗.通过重复利用已创建的线程降低线程创建和销毁造成的消耗. 第二:提高响应速度.当任务到达时,任务可以不需要等到线程创建就能立即执行. 第 ...

  8. 聊聊并发(三)Java线程池的分析和使用

    1.    引言 合理利用线程池能够带来三个好处.第一:降低资源消耗.通过重复利用已创建的线程降低线程创建和销毁造成的消耗.第二:提高响应速度.当任务到达时,任务可以不需要的等到线程创建就能立即执行. ...

  9. java并发包&线程池原理分析&锁的深度化

          java并发包&线程池原理分析&锁的深度化 并发包 同步容器类 Vector与ArrayList区别 1.ArrayList是最常用的List实现类,内部是通过数组实现的, ...

随机推荐

  1. SpringBoot健康检查实现原理

    相信看完之前文章的同学都知道了SpringBoot自动装配的套路了,直接看spring.factories文件,当我们使用的时候只需要引入如下依赖 <dependency> <gro ...

  2. Java 之 Stack 集合

    一.Stack:栈 概述 栈是一种先进后出(FILO)或后进先出(LIFO:Last in first out)的数据结构. Stack是Vector的子类,比Vector多了几个方法,它的后进先出的 ...

  3. 高性能TcpServer(Python) - SocketServer

    源码下载  -> 提取码  QQ:505645074 程序结构图  测试截图 1. 正常接收测试 2. 并发测试

  4. windows10 docker安装使用

    一.安装部署 1.下载安装 https://hub.docker.com/editions/community/docker-ce-desktop-windows 需要注册完后,才可以下载.点击安装 ...

  5. day 68 作业

    ''' 有以下成绩单数据 scores = [ { name: 'Bob', math: 97, chinese: 89, english: 67 }, { name: 'Tom', math: 67 ...

  6. Python 和 R 中的一数多图

    R # 一数多图 x <- 2:6 y <- 7:3 y1 <- y +2 opar <- par(no.readonly = TRUE) par(mfrow=c(2, 3)) ...

  7. PacMan 01——地图的搭建

    版权申明: 本文原创首发于以下网站: 博客园『优梦创客』的空间:https://www.cnblogs.com/raymondking123 优梦创客的官方博客:https://91make.top ...

  8. 在K8S集群中使用busybox-dig镜像,来作DNS解析分析

    以前,判断K8S里的DNS功能是否正常时,得想很多办法. 如果有了busybox-dig镜像,则作这事就简单多了. 如下命令,直接部署 kubectl run busybox -it --image= ...

  9. GitHub 下载代码命令并且导入到IDEA环境

    git clone项目到本地(项目有master和其他分支) 1.首先新建一个空文件夹,在文件夹里面git初始化操作,在文件夹的根目录下,右键选择git bash here,在弹出窗体中:       ...

  10. centos7删除Apache组件

    非特殊需要不要删除centos7中Apache等组件!首先查看centos中Apache版本(前面我们说了centos7删除PHP,centos7删除MariaDB,可能很多朋友会有疑问为什么要把所有 ...