【045】Dubbo3从0到1系列之DefaultExecutorRepository

最新推荐文章于 2025-12-01 13:49:36 发布

原创最新推荐文章于 2025-12-01 13:49:36 发布 · 1k 阅读

26 ·

CC 4.0 BY-SA版权

文章标签：

#dubbo #rpc

Netty从0到1系列教程同时被 3 个专栏收录

125 篇文章

订阅专栏

gRPC从0到1系列

78 篇文章

订阅专栏

Dubbo3从0到1系列

49 篇文章

订阅专栏

文章目录

- 2.17 DefaultExecutorRepository

2.17 DefaultExecutorRepository

public class DefaultExecutorRepository implements ExecutorRepository, ExtensionAccessorAware {
	// ....
}

2.17.1 核心字段

private final ConcurrentMap<String, ConcurrentMap<String, ExecutorService>> data = new ConcurrentHashMap<>();

这是 DefaultExecutorRepository 类中的一个核心数据结构，用于存储和管理所有线程池执行器。

数据结构分析
类型结构

外层 Map: ConcurrentMap<String, ConcurrentMap<String, ExecutorService>>
- Key: 第一层键，通常表示执行器的类别或组件类型
- Value: 内层 Map，存储具体的服务执行器
内层 Map: ConcurrentMap<String, ExecutorService>
- Key: 第二层键，通常是服务的标识符（如端口号、消费者标识等）
- Value: ExecutorService 实际的线程池执行器实例

并发安全

使用 ConcurrentHashMap 确保线程安全，支持高并发环境下的读写操作。

设计目的:

分层管理线程池

// 第一层键示例:
// - EXECUTOR_SERVICE_COMPONENT_KEY ("provider")
// - CONSUMER_SHARED_EXECUTOR_SERVICE_COMPONENT_KEY ("consumer")

// 第二层键示例:
// - Provider: 端口号 (String.valueOf(url.getPort()))
// - Consumer: MAX_KEY (共享同一个线程池)

按服务隔离线程池

不同服务使用独立的线程池，避免相互影响
消费者共享全局线程池（通过 MAX_KEY 标识）
提供者按端口隔离线程池

高效查询和缓存

O(1) 时间复杂度获取特定服务的线程池
避免重复创建相同配置的线程池

2.17.2 使用场景

➡️ 1. 线程池创建流程

@Override
public synchronized ExecutorService createExecutorIfAbsent(URL url) {
    // 1. 获取第一层键 (executorKey)
    String executorKey = getExecutorKey(url);
    
    // 2. 获取或创建第二层Map
    ConcurrentMap<String, ExecutorService> executors =
            ConcurrentHashMapUtils.computeIfAbsent(data, executorKey, k -> new ConcurrentHashMap<>());

    // 3. 获取第二层键 (executorCacheKey)
    String executorCacheKey = getExecutorSecondKey(url);
    
     // If executor has been shut down, create a new one
    if (executor.isShutdown() || executor.isTerminated()) {
            executors.remove(executorCacheKey);
            executor = createExecutor(url); // createExecutor, spi机制
            executors.put(executorCacheKey, executor);
     }
    // 4. 获取或创建线程池
    ExecutorService executor =
            ConcurrentHashMapUtils.computeIfAbsent(executors, executorCacheKey, k -> createExecutor(url));
}

在createExecutor方法中:

protected ExecutorService createExecutor(URL url) {
    return (ExecutorService) extensionAccessor
        .getExtensionLoader(ThreadPool.class)
        .getAdaptiveExtension()
        .getExecutor(url);
}

ThreadPool被@SPI修饰:

@SPI(value = "fixed", scope = ExtensionScope.FRAMEWORK)
public interface ThreadPool {
    @Adaptive({THREADPOOL_KEY})
    Executor getExecutor(URL url);
}

默认使用 FixedThreadPool 实现，但是 ThreadPool 接口中的 getExecutor() 方法被 @Adaptive 注解修饰，动态生成的适配器类会优先根据 URL 中的 threadpool 参数选择 ThreadPool 的扩展实现。ThreadPool 接口的实现类如下图所示：

在这里插入图片描述
不同的实现会根据不同的URL创建不同特性的线程池, 以CacheThreadPool为例进行分析:

CachedThreadPool 是 Dubbo 框架中实现的一种自调节线程池，类似于 JDK 中的 Executors.newCachedThreadPool()。它能够根据负载自动调整线程数量，在空闲时回收线程，在需要时创建新线程

@Override
public Executor getExecutor(URL url) {
    // 1. 获取线程池配置参数
    String name = url.getParameter(THREAD_NAME_KEY, 
        (String) url.getAttribute(THREAD_NAME_KEY, DEFAULT_THREAD_NAME));
    int cores = url.getParameter(CORE_THREADS_KEY, DEFAULT_CORE_THREADS);
    int threads = url.getParameter(THREADS_KEY, Integer.MAX_VALUE);
    int queues = url.getParameter(QUEUES_KEY, DEFAULT_QUEUES);
    int alive = url.getParameter(ALIVE_KEY, DEFAULT_ALIVE);

    // 2. 根据队列大小配置创建相应阻塞队列
    BlockingQueue<Runnable> blockingQueue;
    if (queues == 0) {
        blockingQueue = new SynchronousQueue<>();
    } else if (queues < 0) {
        blockingQueue = new MemorySafeLinkedBlockingQueue<>();
    } else {
        blockingQueue = new LinkedBlockingQueue<>(queues);
    }

    // 3. 创建并返回 ThreadPoolExecutor 实例
    return new ThreadPoolExecutor(
            cores,
            threads,
            alive,
            TimeUnit.MILLISECONDS,
            blockingQueue,
            new NamedInternalThreadFactory(name, true),
            new AbortPolicyWithReport(name, url));
}

➡️ 关键配置参数

在这里插入图片描述

⬆️ 队列策略

三种队列类型选择：

SynchronousQueue (queues=0):
- 直接交付任务，不保存任务
- 提交的任务必须立即被消费
MemorySafeLinkedBlockingQueue (queues<0):
- 内存安全的链表阻塞队列
- 防止内存溢出的安全队列实现
LinkedBlockingQueue (queues>0):
- 固定容量的链表阻塞队列
- 有界队列，限制等待任务数量

✅ 线程池特性

自调节机制
- 无限扩展: 最大线程数设置为 Integer.MAX_VALUE
- 快速回收: 默认 1 分钟空闲后回收线程
- 按需创建: 新请求到来时即时创建线程
线程管理
- 使用 NamedInternalThreadFactory 创建命名线程
- 实现内部线程(ThreadLocal)的清理机制
- 提供详细的线程名称便于调试和监控
拒绝策略
- 采用 AbortPolicyWithReport 策略：
  - 任务被拒绝时抛出异常
  - 记录详细的拒绝原因和统计信息
  - 提供监控和告警支持

🚀 优点:

适合执行大量短期异步任务
能够根据负载动态调整资源使用
减少手动配置线程池的复杂性

➡️ 注意事项

可能创建过多线程导致资源耗尽
不适用于长期运行的任务
需要合理配置队列大小防止内存溢出

与其他线程池对比:
在这里插入图片描述

🚀 2. 线程池获取流程

@Override
public ExecutorService getExecutor(URL url) {
    // 1. 根据URL获取第一层键
    Map<String, ExecutorService> executors = data.get(getExecutorKey(url));
    
    // 2. 根据URL获取第二层键
    String executorCacheKey = getExecutorSecondKey(url);
    
    // 3. 获取具体线程池实例
    ExecutorService executor = executors.get(executorCacheKey);
}

2.17.3 存储策略

Provider 线程池存储

第一层键: EXECUTOR_SERVICE_COMPONENT_KEY (“provider”)
第二层键: 端口号，实现按端口隔离线程池
每个端口对应独立的线程池

Consumer 线程池存储

第一层键: CONSUMER_SHARED_EXECUTOR_SERVICE_COMPONENT_KEY (“consumer”)
第二层键: MAX_KEY (Integer.MAX_VALUE)，所有消费者共享同一份线程池
实现消费者线程池全局共享

2.17.4 生命周期管理

➡️ 1. 资源清理

@Override
public void destroyAll() {
    data.values().forEach(executors -> {
        if (executors != null) {
            executors.values().forEach(executor -> {
                if (executor != null && !executor.isShutdown()) {
                    ExecutorUtil.shutdownNow(executor, 100);
                }
            });
        }
    });
    data.clear(); // 清空整个数据结构
}