dubbo之线程池

最新推荐文章于 2024-09-09 19:29:12 发布
最新推荐文章于 2024-09-09 19:29:12 发布
阅读量5.1k 收藏 5
点赞数 1
分类专栏： dubbo 文章标签： dubbo线程池
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wang0907/article/details/122618149
版权

写在前面

dubbo目前提供了三种线程池的实现，如下：

fixed：固定大小的线程池，启动时建立，并且不会关闭，这也是缺省的设置。
cached：缓存线程池，空闲一分钟自动删除，需要时重建。
limited：可伸缩线程池，但是线程池中的线程数只会增长不会收缩，这样做的目的是为了避免当进行收缩时流量突然增加造成性能问题。

在dubbo源码中相关代码在dubbo-common模块，如下图：

在这里插入图片描述

图中的ThreadPool就是顶层的接口，我们就从这个接口开始吧！

1：ThreadPool

源码如下：

@SPI("fixed")
public interface ThreadPool {
    // public static final String THREADPOOL_KEY = "threadpool";
    @Adaptive({Constants.THREADPOOL_KEY})
    Executor getExecutor(URL url);
}

从接口中我们可以得到以下的信息:

@SPI("fixed"):是一个Dubbo SPI接口，并且默认使用名称为fixed的扩展实现类。
@Adaptive({Constants.THREADPOOL_KEY})：是一个自适应扩展类，并且使用public static final String THREADPOOL_KEY = "threadpool";作为key从URL上寻找值作为目标扩展类的名称。

关于自适应扩展类可以参考dubbo学习系列 中的"dubbo之@Adaptive注解分析"这篇文章。

类图如下：

在这里插入图片描述

下面我们从FixedThreadPool子类开始分析。

2：FixedThreadPool

固定大小线程数的线程池实现，启动时直接初始化，不关闭，一直持有，源码如下：

// 创建一个复用固定线程数的线程池，可参考jdk的API方法java.util.concurrent.Executors#newFixedThreadPool(int)
public class FixedThreadPool implements ThreadPool {

    @Override
    public Executor getExecutor(URL url) {
        // public static final String THREAD_NAME_KEY = "threadname";
        // public static final String DEFAULT_THREAD_NAME = "Dubbo";
        // 从URL上获取线程名称信息
        String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);
        // public static final String THREADS_KEY = "threads";
        // public static final int DEFAULT_THREADS = 200;
        // 从URL上获取线程数
        int threads = url.getParameter(Constants.THREADS_KEY, Constants.DEFAULT_THREADS);
        // public static final String QUEUES_KEY = "queues";
        // public static final int DEFAULT_QUEUES = 0;
        // 从URL上获取任务队列大小
        int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);
        // 2022-01-20 20:30:36
        return new ThreadPoolExecutor(threads, threads, 0, TimeUnit.MILLISECONDS,
                queues == 0 ? new SynchronousQueue<Runnable>() :
                        (queues < 0 ? new LinkedBlockingQueue<Runnable>()
                                : new LinkedBlockingQueue<Runnable>(queues)),
                new NamedInternalThreadFactory(name, true), new AbortPolicyWithReport(name, url));
    }
}

2022-01-20 20:30:36处是使用java.util.concurrent.ThreadPoolExecutor创建线程池，NamedInternalThreadFactory是定义自定义名称的线程池工厂，AbortPolicyWithReport是自定义拒绝策略。

3：CachedThreadPool

缓存线程池，带有一定的空闲时长，超过空闲时长则删除，需要时再创建，源码如下：

// 该线程池实现类可自动调整线程数。默认超过一分钟线程被回收，如果请求数增加会创建新线程。
// 具体可以参看：java.util.concurrent.Executors#newCachedThreadPool()
public class CachedThreadPool implements ThreadPool {

    @Override
    public Executor getExecutor(URL url) {
        // 线程的名称
        String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);
        // public static final String CORE_THREADS_KEY = "corethreads";
        // public static final int DEFAULT_CORE_THREADS = 0;
        // 核心线程数，默认0个
        int cores = url.getParameter(Constants.CORE_THREADS_KEY, Constants.DEFAULT_CORE_THREADS);
        // public static final String THREADS_KEY = "threads";
        // @Native public static final int   MAX_VALUE = 0x7fffffff;
        // 核心线程数，默认0x7fffffff
        int threads = url.getParameter(Constants.THREADS_KEY, Integer.MAX_VALUE);
        // public static final String QUEUES_KEY = "queues";
        // public static final int DEFAULT_QUEUES = 0;
        // 任务队列大小，默认为0
        int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);
        // public static final String ALIVE_KEY = "alive";
        // public static final int DEFAULT_ALIVE = 60 * 1000;
        // 回收前空闲时长，默认为1分钟
        int alive = url.getParameter(Constants.ALIVE_KEY, Constants.DEFAULT_ALIVE);
        return new ThreadPoolExecutor(cores, threads, alive, TimeUnit.MILLISECONDS,
                queues == 0 ? new SynchronousQueue<Runnable>() :
                        (queues < 0 ? new LinkedBlockingQueue<Runnable>()
                                : new LinkedBlockingQueue<Runnable>(queues)),
                new NamedInternalThreadFactory(name, true), new AbortPolicyWithReport(name, url));
    }
}

4：LimitedThreadPool

只增长不收缩的线程池，这么做的目的是避免进行收缩时突然来了大流量造成性能问题。

public class LimitedThreadPool implements ThreadPool {

    @Override
    public Executor getExecutor(URL url) {
        String name = url.getParameter(Constants.THREAD_NAME_KEY, Constants.DEFAULT_THREAD_NAME);
        int cores = url.getParameter(Constants.CORE_THREADS_KEY, Constants.DEFAULT_CORE_THREADS);
        int threads = url.getParameter(Constants.THREADS_KEY, Constants.DEFAULT_THREADS);
        int queues = url.getParameter(Constants.QUEUES_KEY, Constants.DEFAULT_QUEUES);
        // 通过设置过期时间为Long.MAX_VALUE保证永不过期
        return new ThreadPoolExecutor(cores, threads, Long.MAX_VALUE, TimeUnit.MILLISECONDS,
                queues == 0 ? new SynchronousQueue<Runnable>() :
                        (queues < 0 ? new LinkedBlockingQueue<Runnable>()
                                : new LinkedBlockingQueue<Runnable>(queues)),
                new NamedInternalThreadFactory(name, true), new AbortPolicyWithReport(name, url));
    }
}

该类和3：CachedThreadPool的区别就是超时时长设置的是一个超大值Long.MAX_VALUE，可以认为就是不超时。我们可以看到所有的线程池实现都使用了同一个拒绝策略AbortPolicyWithReport，具体参考5：AbortPolicyWithReport。

5：AbortPolicyWithReport

可通过如下代码debug拒绝策略代码的执行：

public class MyMain {

    public static void main(String[] args) {
        URL url = URL.valueOf("dubbo://192.168.0.101:20880?fruit.granter=banana");
        ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
                5,
                5,
                Long.MAX_VALUE,
                TimeUnit.MILLISECONDS,
                new LinkedBlockingQueue<Runnable>(5),
                new NamedInternalThreadFactory("dongshidaddy", true),
                new AbortPolicyWithReport("dongshidaddy", url));
        for (int i = 0; i < 100; i++) {
            threadPoolExecutor.execute(() -> {
                try {
                    Thread.sleep(Integer.MAX_VALUE);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
        }
    }
}

dubbo自定义的拒绝策略，当无可用线程，并且任务队列也满时会通过该类来执行拒绝策略，主要实现的是打印线程信息，定位问题。
源码如下：

class FakeCls {
    @Override
    public void rejectedExecution(Runnable r, ThreadPoolExecutor e) {
        // 2022-01-21 10:57:10
        String msg = String.format("Thread pool is EXHAUSTED!" +
                        " Thread Name: %s, Pool Size: %d (active: %d, core: %d, max: %d, largest: %d), Task: %d (completed: %d)," +
                        " Executor status:(isShutdown:%s, isTerminated:%s, isTerminating:%s), in %s://%s:%d!",
                threadName, e.getPoolSize(), e.getActiveCount(), e.getCorePoolSize(), e.getMaximumPoolSize(), e.getLargestPoolSize(),
                e.getTaskCount(), e.getCompletedTaskCount(), e.isShutdown(), e.isTerminated(), e.isTerminating(),
                url.getProtocol(), url.getIp(), url.getPort());
        // 打印警告日志
        logger.warn(msg);
        // 2022-01-21 11:01:38
        dumpJStack();
        // 抛出运行时异常java.util.concurrent.RejectedExecutionException
        throw new RejectedExecutionException(msg);
    }

}

2022-01-21 10:57:10生成相关的线程和任务运行信息，如Thread pool is EXHAUSTED! Thread Name: dongshidaddy, Pool Size: 5 (active: 5, core: 5, max: 5, largest: 5), Task: 10 (completed: 0), Executor status:(isShutdown:false, isTerminated:false, isTerminating:false), in dubbo://192.168.0.101:20880!。2022-01-21 11:01:38处是dump转存线程栈信息，具体参考5.1：dumpJStack。

5.1：dumpJStack

源码如下：

class FakeCls {
    private void dumpJStack() {
        long now = System.currentTimeMillis();
        // 考虑到避免影响系统性能，十分钟内只转存一次
        if (now - lastPrintTime < 10 * 60 * 1000) {
            return;
        } 
        // private static Semaphore guard = new Semaphore(1);
        // 值为1的信号量，即只允许一个线程进入，获取不到直接return返回
        if (!guard.tryAcquire()) {
            return;
        }
        // 启动一个线程来执行线程信息的准村
        Executors.newSingleThreadExecutor().execute(new Runnable() {
            @Override
            public void run() {
                // 转存路径：C:\Users\Administrator
                String dumpPath = url.getParameter(Constants.DUMP_DIRECTORY, System.getProperty("user.home"));
                SimpleDateFormat sdf;
                // 操作系统：windows 10
                String OS = System.getProperty("os.name").toLowerCase();
                // 这里特殊处理的原因是，win系统不支持文件名称带有:
                if(OS.contains("win")){
                    sdf = new SimpleDateFormat("yyyy-MM-dd_HH-mm-ss");
                } else {
                    sdf = new SimpleDateFormat("yyyy-MM-dd_HH:mm:ss");
                }
                String dateStr = sdf.format(new Date());
                FileOutputStream jstackStream = null;
                try {
                    // 创建文件的输出流，用于写信息
                    // C:\Users\Administrator Dubbo_JStack.log.2022-01-21_11-10-27
                    jstackStream = new FileOutputStream(new File(dumpPath, "Dubbo_JStack.log" + "." + dateStr));
                    // 2022-01-21 11:12:35
                    JVMUtil.jstack(jstackStream);
                } catch (Throwable t) {
                    logger.error("dump jstack error", t);
                } finally {
                    // 释放信号量，以便其他线程acquire
                    guard.release();
                    // 关闭流
                    if (jstackStream != null) {
                        try {
                            jstackStream.flush();
                            jstackStream.close();
                        } catch (IOException e) {
                        }
                    }
                }
                lastPrintTime = System.currentTimeMillis();
            }
        });
    }
}

2022-01-21 11:12:35处是写信息到文件中，具体参考5.2：JVMUtil.jstack。

5.2：JVMUtil.jstack

源码如下：

class FakeCls {
    public class JVMUtil {
        public static void jstack(OutputStream stream) throws Exception {
            ThreadMXBean threadMxBean = ManagementFactory.getThreadMXBean();
            for (ThreadInfo threadInfo : threadMxBean.dumpAllThreads(true, true)) {
                stream.write(getThreadDumpString(threadInfo).getBytes());
            }
        }
    
        private static String getThreadDumpString(ThreadInfo threadInfo) {
            StringBuilder sb = new StringBuilder("\"" + threadInfo.getThreadName() + "\"" +
                    " Id=" + threadInfo.getThreadId() + " " +
                    threadInfo.getThreadState());
            if (threadInfo.getLockName() != null) {
                sb.append(" on " + threadInfo.getLockName());
            }
            if (threadInfo.getLockOwnerName() != null) {
                sb.append(" owned by \"" + threadInfo.getLockOwnerName() +
                        "\" Id=" + threadInfo.getLockOwnerId());
            }
            if (threadInfo.isSuspended()) {
                sb.append(" (suspended)");
            }
            if (threadInfo.isInNative()) {
                sb.append(" (in native)");
            }
            sb.append('\n');
            int i = 0;
    
            StackTraceElement[] stackTrace = threadInfo.getStackTrace();
            MonitorInfo[] lockedMonitors = threadInfo.getLockedMonitors();
            for (; i < stackTrace.length && i < 32; i++) {
                StackTraceElement ste = stackTrace[i];
                sb.append("\tat " + ste.toString());
                sb.append('\n');
                if (i == 0 && threadInfo.getLockInfo() != null) {
                    Thread.State ts = threadInfo.getThreadState();
                    switch (ts) {
                        case BLOCKED:
                            sb.append("\t-  blocked on " + threadInfo.getLockInfo());
                            sb.append('\n');
                            break;
                        case WAITING:
                            sb.append("\t-  waiting on " + threadInfo.getLockInfo());
                            sb.append('\n');
                            break;
                        case TIMED_WAITING:
                            sb.append("\t-  waiting on " + threadInfo.getLockInfo());
                            sb.append('\n');
                            break;
                        default:
                    }
                }
    
                for (MonitorInfo mi : lockedMonitors) {
                    if (mi.getLockedStackDepth() == i) {
                        sb.append("\t-  locked " + mi);
                        sb.append('\n');
                    }
                }
            }
            if (i < stackTrace.length) {
                sb.append("\t...");
                sb.append('\n');
            }
    
            LockInfo[] locks = threadInfo.getLockedSynchronizers();
            if (locks.length > 0) {
                sb.append("\n\tNumber of locked synchronizers = " + locks.length);
                sb.append('\n');
                for (LockInfo li : locks) {
                    sb.append("\t- " + li);
                    sb.append('\n');
                }
            }
            sb.append('\n');
            return sb.toString();
        }
    }
}

如下是生成的转存文件和其部分内容：

在这里插入图片描述

在这里插入图片描述

一户董
关注
专栏目录
dubbo 自定义线程池
congge
04-17 1万+
Dubbo 自定义线程池
精尽 Dubbo 源码分析 —— 线程池
qq_32782279的博客
02-20 432
1. 概述 在 《Dubbo 用户指南 —— 线程模型.》 一文中，我们可以看到 Dubbo 提供了三种线程池的实现： ThreadPool fixed 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省) cached 缓存线程池，空闲一分钟自动删除，需要时重建。 limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题...
Dubbo 线程池策略
最新发布
happycao123的博客
09-09 1179
Dubbo 线程池，主要还是基于JDK线程池几个参数做文章，并没有发明什么新东西，因此理解Dubbo 线程池前提掌握jdk 线程池的工作原理，当然也可以自定义扩展实现。指定线程池方式如下。
Dubbo之线程池
weixin_43257196 的博客
04-11 509
Dubbo中提供了三种线程池的实现： fixed 固定大小线程池，启动时建立线程不关闭，一直持有。 cached 缓存线程池，空闲一分钟自动删除，需要时重建。 limited 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。 ThreadPool ，线程池接口： @SPI(“fixed”) 注解，Dubbo SPI 拓展点，默认为 ...
Dubbo 之 线程池
凉茶铺的博客
08-15 1574
在真实的使用过程中可能会因为使用fix模式的线程池，导致具体某些业务场景因为线程池中的线程数量不足而产生错误，而很多业务研发是对这些无感知的，只有当出现错误的时候才会去查看告警或者通过客户反馈出现严重的问题才去查看，结果发现是线程池满了。所以可以在创建线程池的时，通过某些手段对这个线程池进行监控，这样就可以进行及时的扩缩容机器或者告警。下面的这个程序就是这样子的，会在创建线程池后进行对其监控，并且及时作出相应处理。...
Dubbo线程池
qq_27615455的博客
12-19 922
Dubbo使用Netty作为网络调用框架，Netty是一个Reactor模型的框架，线程模型分为boss线程池和worker线程池，boss线程池负责监听、分配事件，worker线程池负责处理事件，简单说就是boss线程池负责hold请求，并分发到worker池，worker线程池负责处理具体事件。dubbo在原本的netty中的线程（boss线程和worker）做了一些修改，将其定义为io线程，而后由实现了一套用于处理业务的业务线程池，这就和上一篇介绍的Dubbo协议下的服务端线程模型。
springboot整合mybatis、dubbo、线程池、swagger等初始工程
10-16
压缩包内是一个初始的框架性质代码，是maven工程,里面整合了springboot、restful接口、mybatis、dubbo、juint、quartzjob、swagger等功能，方便下下来进行直接开发。 如果没有私有nexus，使用公共的也可以，打包如果...
Apache Dubbo系列：Dubbo的线程池策略
nuoWei_SenLin的博客
10-16 2019
概述 我们上篇文章讲到，Dubbo提供了多种线程模型，是为了尽早的释放I/O线程，把耗时的业务分派给业务线程池，那么这里的线程池是什么类型的线程池呢？是我们所熟知的JAVA线程池吗？并不是，这里的线程池，也是Dubbo的扩展接口ThreadPool。 ThreadPool Dubbo为我们提供了四种类型的线程池，分别是 1、FixedThreadPool(默认)，固定线程数的线程池。 2、LimitedThreadPool，线程池的线程数随着并发量动态增加，但不会超过配置的阈值。 3、Eag.
dubbo自定义线程池监控已有线程池的使用状态
qq_15736697的博客
02-08 642
创建一个maven工程 创建一个类继承FixedThreadPool package com.sherlock.service.impl; import org.apache.dubbo.common.URL; import org.apache.dubbo.common.threadpool.support.fixed.FixedThreadPool; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import java.uti.
Dubbo 线程池模型
liyong1028826685的专栏
06-03 565
前言 大家好，今天开始给大家分享 — Dubbo 专题之 Dubbo 线程池模型。在前面上个章节中我们讨论了 Dubbo SPI，了解了 Dubbo SPI 其本质是从 JDK 标准的 SPI (Service Provider Interface) 扩展点发现机制加强而来，同时解决了 Java 中 SPI 的一些缺陷。以及我们使用 Dubbo SPI 实现自定义能力的拓展。那本章节我们要讨论的 Dubbo 线程模型也是基于 SPI 实现，那什么是线程模型呢？以及其在我们的项目中有什么作用呢？那么我们在本章
dubbo 线程池
weixin_33907511的博客
09-24 92
在dubbo调用过程中被调用方有两个线程池：io线程池，业务线程池。 这也是dubbo调优的点。 配置信息： &lt;dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" /&gt; Dispatcher all 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心...
Dubbo的线程池策略
J_bean的博客
03-10 1292
Dubbo的线程池策略剖析和自定义线程池策略
dubbo的线程模型
武汉红喜
03-09 1196
        Dubbo默认的底层网络通讯使用的是Netty，服务提供方NettyServer使用两级线程池，其中 EventLoopGroup(boss) 主要用来接受客户端的链接请求，并把接受的请求分发给 EventLoopGroup(worker) 来处理，boss和worker线程组我们称之为IO线程。 如果服务提供方的逻辑能迅速完成，并且不会发起新的IO请求，那...
10 dubbo源码学习_线程池
shixiaoling123的博客
04-27 1958
dubbo内部采用netty做为通信工具，netty包括bossGroup和workerGroup，bossGroup负责接收accept连接，连接就绪后，将连接交给workerGroup进行处理；默认情况下：bossGroup：线程个数：1个，队列长度，Integer.MAX；创建1个NioEventLoop，这个NioEventLoop主要进行accept操作；
【Dubbo】Dubbo线程池问题思考Thread pool is EXHAUSTED!
极客中年的博客
05-22 1362
问题 前几天，我们的生产上突然出现了这样一个问题，调下面的查询方法报错，线程池满的问题，如下图： 问题思路 简单思考：我们都知道线程池的参数都包含什么含义！核心线程数，可建线程数，存储任务队列，拒绝策略！这块，大家不熟悉或者忘记的可以再补习补习！了解这几个参数我们不禁会问，任务处理不了，不是还有队列存储么？存储不了不是还有拒绝策略么？再者，怎么两百个线程就同时都被占用了？理论我们的场景没有这种量啊！带着这些问题，我们从源码中得到一些答案！ 根据上面的问题，我找到了Dubbo相关源码，看一下生产版本2.6.
Dubbo 源码分析之线程池
苏苏爱自由
01-19 1958
文章目录前言Dubbo 线程池分类Dubbo 线程工厂线程池拒绝策略CachedThreadPoolFixedThreadPoolLimitedThreadPool 前言 相信学过 netty 的都知道，每一个 ChannelHandler 都是通过它的 EventLoop(I/O线程) 来处理传递给它的事件，所以至关重要的是不要阻塞这个线程，因为这会对整体的 I/O 产生负面的影响。Dubbo...
dubbo 线程池调度策略
10-19
Dubbo的线程池调度策略通过SPI配置文件对外提供，在com.alibaba.dubbo.common.threadpool.ThreadPool文件中定义。Dubbo的线程池调度策略对外提供了三种策略，分别是fixed、cached、limited三类。 1. fixed策略：固定大小的线程池，当线程池达到最大值时，新的任务会在队列中等待。 2. cached策略：无限制大小的线程池，当线程池中的线程空闲时间超过60秒时，多余的线程会被回收。当有新任务到来时，如果线程池中有空闲线程，则会立即执行，否则会创建新的线程。 3. limited策略：有界队列的线程池，当线程池达到最大值时，新的任务会在队列中等待。当队列达到最大值时，新的任务将被拒绝。 除了以上三种策略，Dubbo还提供了自定义线程池的扩展接口SPI，可以根据业务需求进行定制。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值