前言

在 SOFA-RPC 的官方介绍里,介绍了自定义线程池,可以为指定服务设置一个独立的业务线程池,和 SOFARPC 自身的业务线程池是隔离的。多个服务可以共用一个独立的线程池。

API使用方式如下:

UserThreadPool threadPool = new UserThreadPool();
threadPool.setCorePoolSize(10);
threadPool.setMaximumPoolSize(100);
threadPool.setKeepAliveTime(200);
threadPool.setPrestartAllCoreThreads(false);
threadPool.setAllowCoreThreadTimeOut(false);
threadPool.setQueueSize(200); UserThreadPoolManager.registerUserThread("com.alipay.sofa.rpc.quickstart.HelloService", threadPool);

如上为 HelloService 服务设置了一个自定义线程池。

在 SOFABoot 中如下使用:

<bean id="customExcutor" class="com.alipay.sofa.rpc.server.UserThreadPool" init-method="init">
<property name="corePoolSize" value="10" />
<property name="maximumPoolSize" value="10" />
<property name="queueSize" value="0" />
</bean> <bean id="helloService" class="com.alipay.sofa.rpc.quickstart.HelloService"/> <sofa:service ref="helloService" interface="XXXService">
<sofa:binding.bolt>
<sofa:global-attrs thread-pool-ref="customExcutor"/>
</sofa:binding.bolt>
</sofa:service>

那么实现原理是什么呢?

一起来看看。

源码分析

关键代码:


UserThreadPoolManager.
registerUserThread("com.alipay.sofa.rpc.quickstart.HelloService", threadPool);

UserThreadPoolManager 是一个用户自定义线程池管理器。里面包含一个 Map, key 是接口名称,value 是线程池(一个 UserThreadPool对象)。

看看这个 UserThreadPool。

很简单的一个类,封装了 JDK 的线程池。并初始化了一些线程池参数,比如:

  • corePoolSize = 10
  • maximumPoolSize = 100
  • keepAliveTime = 300000(线程回收时间(毫秒))
  • queueSize = 0
  • threadPoolName = "SofaUserProcessor" 线程名字
  • boolean allowCoreThreadTimeOut 是否关闭核心线程池
  • boolean prestartAllCoreThreads 是否初始化核心线程池
  • volatile ThreadPoolExecutor executor

初始化的时候,默认参数不变,核心线程数 10,最大 100,默认不关闭核心线程池,默认不初始化线程池。默认是 SynchronousQueue 队列,此队列性能最高,也可以设置成阻塞队列,或者优先级队列。当然,这些都是可以改的。

这个线程池什么时候回起作用呢?

先说结论:当 Netty 读取数据(channelRead 方法)后,通过层层调用,会调用 RpcRequestProcessor 类的 process 方法。该方法会拿到上下文的 UserProcessor 对象(bolt 的话,实现类是 BoltServerProcessor),UserProcessor 有一个内部接口 ExecutorSelector,线程池选择器,该选择器定义了一个 select 方法,返回的是线程池,如果用户自定义了线程池,就会返回自定义线程池(方式:UserThreadPoolManager.getUserThread(service)),如果没有,返回系统线程池。

来看看具体代码。

RpcHandler 我们很熟悉了,就是 Netty 的 handler ,ChannelRead 方法中,会调用 RpcCommandHandler 的 handleCommand 方法,该方法会提交到线程池执行。任务内容是执行 process 方法。

通过调用,最后会执行 RpcRequestProcessor 的 process 方法。调用栈如下:

105 行会有如下判断:

// to check whether get executor using executor selector
if (null == userProcessor.getExecutorSelector()) {
executor = userProcessor.getExecutor();
} else {
// in case haven't deserialized in io thread
// it need to deserialize clazz and header before using executor dispath strategy
if (!deserializeRequestCommand(ctx, cmd, RpcDeserializeLevel.DESERIALIZE_HEADER)) {
return;
}
//try get executor with strategy
executor = userProcessor.getExecutorSelector().select(cmd.getRequestClass(),
cmd.getRequestHeader());
}

尝试获取线线程池选择器,如果是 null, 使用系统线程池,如果不是 null,调用选择器的 select 方法得到线程池,随后,使用这个线程执行任务。

// Till now, if executor still null, then try default
if (executor == null) {
executor = (this.getExecutor() == null ? defaultExecutor : this.getExecutor());
} // use the final executor dispatch process task
executor.execute(new ProcessTask(ctx, cmd));

那么这个 select 方法是如何实现的呢?目前仅有一个实现,BoltServerProcessor 的内部类 UserThreadPoolSelector。该方法逻辑如下:

从 Header 中获取服务名称,根据服务名称调用 UserThreadPoolManager.getUserThread(service) ,如果返回值不是 null ,说明用户设置自定义线程池了,就返回该线程池。如果是 null,返回系统线程池。

而 BoltServerProcessor 的 getExecutorSelector 判断规则如下:

    @Override
public ExecutorSelector getExecutorSelector() {
return UserThreadPoolManager.hasUserThread() ? executorSelector : null;
} public static boolean hasUserThread() {
return userThreadMap != null && userThreadMap.size() > 0;
} public BoltServerProcessor(BoltServer boltServer) {
this.boltServer = boltServer;
this.executorSelector = new UserThreadPoolSelector(); // 支持自定义业务线程池
}

可以看到,BoltServerProcessor 默认就会创建一个内部类对象,只要 UserThreadPoolManager 里面的 Map 不是空,就会尝试调用 select 方法,如果通过服务名称找到缓存中的自定义线程池,就直接返回了。非常完美。

需要注意一点,系统线程池只有一个,默认核心线程池大小 20 ,最大 200。貌似这也是 tomcat 的默认配置,因此,并发很高的时候,可能就需要用户使用自定义线程池了,能够显著提高并发量。

总结

好了,关于自定线程池的原理探究的差不多了,这个功能挺有用的,当系统并发很高的时候,或者某个服务很慢,不能让该服务影响其他服务,就可以使用自定线程池,将这些慢服务和其他服务隔离开。

原理则是通过 UserThreadPoolManager 与 Server 进行交互,当 Server 执行任务的时候,会从当前的上下文中,找到与调用服务对应的线程池,如果有的话,就返回 UserThreadPoolManager 管理的线程池,如果没有,返回框架线程池。

具体判断的代码在 Bolt 模块 com.alipay.remoting.rpc.protocol.RpcRequestProcessor 的 process 方法中。

bye!!!

SOFA 源码分析 — 自定义线程池原理的更多相关文章

  1. 深入源码分析Java线程池的实现原理

    程序的运行,其本质上,是对系统资源(CPU.内存.磁盘.网络等等)的使用.如何高效的使用这些资源是我们编程优化演进的一个方向.今天说的线程池就是一种对CPU利用的优化手段. 通过学习线程池原理,明白所 ...

  2. 源码分析—ThreadPoolExecutor线程池三大问题及改进方案

    前言 在一次聚会中,我和一个腾讯大佬聊起了池化技术,提及到java的线程池实现问题,我说这个我懂啊,然后巴拉巴拉说了一大堆,然后腾讯大佬问我说,那你知道线程池有什么缺陷吗?我顿时哑口无言,甘拜下风,所 ...

  3. 从JDK源码角度看线程池原理

    "池"技术对我们来说是非常熟悉的一个概念,它的引入是为了在某些场景下提高系统某些关键节点性能,最典型的例子就是数据库连接池,JDBC是一种服务供应接口(SPI),具体的数据库连接实 ...

  4. SOFA 源码分析— 自定义路由寻址

    前言 SOFA-RPC 中对服务地址的选择也抽象为了一条处理链,由每一个 Router 进行处理.同 Filter 一样, SOFA-RPC 对 Router 提供了同样的扩展能力. 那么就看看 SO ...

  5. SOFA 源码分析 —— 服务引用过程

    前言 在前面的 SOFA 源码分析 -- 服务发布过程 文章中,我们分析了 SOFA 的服务发布过程,一个完整的 RPC 除了发布服务,当然还需要引用服务. So,今天就一起来看看 SOFA 是如何引 ...

  6. netty源码分析 - Recycler 对象池的设计

    目录 一.为什么需要对象池 二.使用姿势 2.1 同线程创建回收对象 2.2 异线程创建回收对象 三.数据结构 3.1 物理数据结构图 3.2 逻辑数据结构图(重要) 四.源码分析 4.2.同线程获取 ...

  7. jQuery 2.0.3 源码分析Sizzle引擎解析原理

    jQuery 2.0.3 源码分析Sizzle引擎 - 解析原理 声明:本文为原创文章,如需转载,请注明来源并保留原文链接Aaron,谢谢! 先来回答博友的提问: 如何解析 div > p + ...

  8. Memcached源码分析之线程模型

    作者:Calix 一)模型分析 memcached到底是如何处理我们的网络连接的? memcached通过epoll(使用libevent,下面具体再讲)实现异步的服务器,但仍然使用多线程,主要有两种 ...

  9. SOFA 源码分析 — 调用方式

    前言 SOFARPC 提供了多种调用方式满足不同的场景. 例如,同步阻塞调用:异步 future 调用,Callback 回调调用,Oneway 调用. 每种调用模式都有对应的场景.类似于单进程中的调 ...

随机推荐

  1. C++实现最小堆及插入,调整顺序,删除堆顶元素的操作

    上次用Java实现了最大堆的封装,这次就来写一下最小堆的实现吧 插入函数的思路: 向堆中插入元素有两种情况,一种是堆为空,那么就让插入值作为根节点即可:另一种是堆不为空,那么此时就要进行判断当前节点与 ...

  2. (三十七)从私人通讯录引出的细节I -Notification -Segue -HUD -延时

    细节1:账号和密码都有值的时候才可以点击登录按钮,因此应该监听文本框的文本改变. 因为文本框的文本改变代理不能处理,因此应该使用通知Notification. 文本框文本改变会发出通知:通知的前两个参 ...

  3. 支持老版本IE的3种解决方案

    原文链接: 3 Solutions for Supporting Internet Explorer 翻译人员: 铁锚 翻译时间: 2014年2月14日 在刚发布的那几年,Internet Explo ...

  4. STL - queue(队列)

    Queue简介 queue是队列容器,是一种"先进先出"的容器. queue是简单地装饰deque容器而成为另外的一种容器. #include <queue> queu ...

  5. 客户端状态的存储空间——Session

    http协议在设计之初被设计成无状态特性,客户端的每次请求在服务端看来都是独立且无任何相关性,同一个客户端第一次请求不会与第二次请求有任何关联,即使相隔时间很短.无状态的特性让请求变得很快速且服务器也 ...

  6. Learning ROS for Robotics Programming Second Edition学习笔记(六) indigo xtion pro live

    中文译著已经出版,详情请参考:http://blog.csdn.net/ZhangRelay/article/category/6506865 Learning ROS for Robotics Pr ...

  7. Xcode中iOS模拟器程序中的plist路径

    Xcode6.4里写了个简单的iOS程序在模拟器中跑. 其中用到了NSUserDefaults来保存属性文件plist,那么这个文件实际路径在哪里呢?在网上搜了一下,发现几种说法(*表示当前用户名): ...

  8. 【45】java的封装剖析

    类是构造对象的模板或蓝图. 封装的一些概念 从形式上看,封装不过是将数据和行为组合到一个包中,并对对象的使用者隐藏了数据的实现形式. 每个对象都包含实例域和方法.实例域的集合代表了一个集合的状态,通过 ...

  9. Bloom filter 2

    1 Bloom filter 计算方法 如需要判断一个元素是不是在一个集合中,我们通常做法是把所有元素保存下来,然后通过比较知道它是不是在集合内,链表.树都是基于这种思路,当集合内元素个数的变大,我们 ...

  10. 网站系统压力测试Jmeter+Badboy

    最近项目需要压力测试,因此搜了几款试用,首选的是LoadRunner这款大名鼎鼎的测试软件: LoadRunner11 下载请猛戳这里 传送门LoadRunner破解文件 下载请猛戳这里 传送门Loa ...