Tag Archives: 线程池

支持配额的共享线程池

用了几个小时动手实现了一个简陋支持配额的共享线程池. 基本思路与放翁相同, 区别在于引入了两种线程分配策略:

悲观策略

简单的共享一个线程池, 最容易出现的问题就是不同类型任务(或事件)在随机争抢线程资源时, 可能出现”饿死”现象(即抢不到线程).

因此, 悲观策略的宗旨是绝对的保证每种任务都会被分配到预留的(reserve)配额, 这种做法本质上和多个线程池的做法一样. 如总共100个线程, A任务可用50个线程, B任务可用30个线程, C任务可用20个, 三者互不占用, 一旦任意谁的任务实例超过配额, 将被迫等待直至先前的任务实例结束释放了线程.

统一到一个共享的池中, 好处自然是归一化管理, 容易从全局上比较不同任务的优先级, 做出合理的资源分配; 坏处可能就是需要去实现这样一个支持配额的共享线程池. 当然, 若不觉得多个线程池有什么不好, 悲观策略其实意义不大:(.

乐观策略

无论是使用悲观策略的共享线程池, 还是精心规划多个线程池, 由于都是预定义, 难免在环境变化过程中出现线程资源不足或闲置的情况. 要是可以这样, 某个时段当A任务较少时,  它所闲置的线程能协调给负载较高的B任务, 那就完美了!

故,  共享线程池的乐观策略就是在保证每种任务预留最低资源的情况下, 允许任务依据一个弹性(elastic)配额去争抢线程资源, 达到线程利用率的最大化. 如有100个线程的池, A任务大部分的时候负载较高, 则给予50个的预留配额, 30个的弹性配额; 而B任务是偶尔某个时段复杂较高, 则给予20个线程的预留配额, 30个的弹性配额, 这样留了一个30个线程的资源空间, 让AB去合理竞争.

很多实现的细节, 还请参见源代码.

源代码

CentralExecutor.java

CentralExecutorTest.java

 

逻辑划分线程池

现在很多系统中,特别是事件驱动的系统中,对于线程池的维护很多时候根据业务处理类型的不同做划分和管理,但分开维护会带来下面两个问题:

1. 到处线程池,每个线程池都有上限设置,但是所有线程池到达上限的时候也许系统已经无法承受了,所以局部设计和限制无法达到全局限制的目标。

2. 合理的利用线程池的资源,当线程池逻辑上真实隔离后,就无法将空闲的线程资源借调给繁忙的任务处理使用。

设计中关注的:

虚拟隔离线程池需要有模型可以保证对于一些处理的保护,对于一些处理的降级。

设计思路:

简单的两种配置模式:保留,限制。

举个例子:

默认线程池大小设置为100。

A类任务设置为保留10,B类任务设置为限制50。

假设有A,B,C三种任务进入。

A最大可以使用100个线程,其中10个是它独占的(通过配置可以选择优先使用公有的还是私有的)

B最大可以使用50个线程,当公有线程(100-10=90)被消耗后剩余总数小于50,那么B消耗的数量就会小于50,假如公有90个线程都没有被消耗,此时B最多也只能消耗50个线程。总结来说,B消耗公有的线程资源,同时最多只能消耗他的设置(当然他设置如果超过公有线程,则以公有线程池最大作为上限)

C最大可以使用90个线程,也就是所有的公有线程。

当任何一种请求没有线程资源可以被使用的时候,将会被放入队列,等待线程可用,队列不区分任务类型。

第一版简单的Java代码参看:http://www.rayfile.com/zh-cn/files/66a89e61-4357-11e0-9ad5-0015c55db73d/
这里只是探讨一种简单的设计思路,以最小代价来全局化管理维护线程池或者资源池。