线程池技术在网络服务器中的应用

吉 利，潘林云，刘 姚

(南京邮电大学 通信与信息工程学院，江苏 南京 210003)

线程池技术在网络服务器中的应用

吉 利，潘林云，刘 姚

(南京邮电大学 通信与信息工程学院，江苏 南京 210003)

目前的网络服务器大多为C/S架构，其线程响应客户端要么短且频繁，要么长而连续，这两种服务请求均要求服务器根据系统负载提供稳定的响应时间，并在高并发情况下保证服务器系统的工作稳定性。传统的多线程技术虽能通过并发服务器发挥较好的性能，但线程频繁的创建与销毁会导致巨大的系统开销。为此，在研究线程池技术机理的基础上，针对常见的线程池容量估算的弊端，提出了经优化的池线程容量估算方法。该方法引入经优化的池线程，以解决因大量客户端服务请求所导致的服务器不稳定问题。线程池性能测试与验证结果表明，采用所提出的线程池容量估算方法和线程池策略，有效地降低了因频繁创建线程而导致的系统开销，既保证了高负载条件下服务器的稳定性，又能够为服务器提供稳定的吞吐量。

多线程；线程池；线程池容量；服务器

0 引 言

随着计算机技术的发展，计算机计算性能得到了质的飞跃，合理使用多线程技术较传统的单线程能够显著提升系统的吞吐量与响应速度，特别在高并发访问的情形下。电子商务[1]、消息中间件和其他基于网络的应用程序部分取决于网络服务器响应的及时和可靠性。多线程系统[2]，由于系统资源的有效利用和共享内存多处理器架构的普及已成为服务器实现的必然选择。然而在访问频率高且服务时间短的情况下，创建和销毁线程将消耗巨大的系统资源[3]。

线程池中的线程可以重新使用，线程的创建和销毁只发生一次。通过线程池使得多个任务重用线程，大大降低了线程创建与销毁的系统开销[4]。且多线程的并发执行，能够充分使用服务器主机资源。

传统的线程池策略采用固定大小的核心线程，即使在低负载的情况下，线程切换也会引起巨大的系统开销。为此，提出了线程池容量分配方法，保证在系统低负载与高负载的情况下，均能得到较高的性能[5]。

1 线程池原理

线程池包含几个重要的参数，工作线程，线程容量与缓存客户端请求的请求队列。线程池的工作原理如图1所示。请求队列用于缓存客户端请求，线程用于执行客户端的每一次请求，工作线程从请求队列取出请求，用可重用线程处理请求的任务，并在任务完成后向客户端返回信息。

图1 线程池的核心工作流程

当向线程池提交新的任务时，线程池执行以下规则来保证系统对客户端的响应：

(1)工作线程用于轮询接受新的客户端请求，如果线程池有足够的空闲线程，则直接提交给线程。若线程池已满，则进入步骤(2)。

(2)线程池判断请求队列是否已满，若未满则工作线程将该请求添加到请求队列中；若已满则向客户端返回服务器忙信息[6]。

(3)线程池判断是否有空闲线程以及请求队列是否有未完成的请求任务，循环从请求队列中取出请求任务交给空闲线程执行。

(4)若线程池没有空闲，且线程池的请求缓存队列已经存在大量缓存请求，可以适当创建新的线程来服务请求[7]。

2 线程池容量

线程池的容量单方面决定服务器的吞吐量性能参数，如果容量过小且并发请求数量超过该容量，请求将会加入阻塞队列，若队列中已包含大量的已缓存请求，则对系统的响应时间影响巨大。同时若线程池容量过大，线程的上下文切换也会造成巨大的系统开销[8]。

图2展示了当线程池容量小于CPU的核心数目时，CPU的利用率、系统的响应时间随请求数量增加的变化情况。

由于线程池容量较小，并没有充分利用CPU的全部资源，所以CPU使用率一直处于一个较低的水平，处理器的性能并没有被充分利用。在请求队列满时，服务器应用开始拒绝新的客户端请求，此时到达服务器的吞吐量。

图3展示了高容量线程池CPU的利用率、系统的响应时间随请求数量增加的变化情况。

图2 响应时间与请求数目的关系

图3 CPU利用率与请求数目的关系

并发用户请求数量增加，服务器创建相同数量的线程来服务请求，此时CPU很容易达到满载状态，但由于操作系统中存在大量线程，系统资源大量消耗在线程的上下文切换中。此时服务器的响应时间也会增加。所以线程池容量要避免设置太小或太大，太小不能充分使用CPU的性能，太大会造成频繁的上下文切换，带来巨大的系统开销。所以线程池容量需要根据负载和部署条件动态改变。

最佳容量大小可以通过设置等比例间隔通过实际压力测试获取最优结果。在计算密集型系统执行中能够获得最佳的CPU利用率[9]。然而在I/O密集型系统，需要用等待概率比例来估算任务的执行时间。Little’s Law公式为：

(1)

其中，W为请求的平均处理时间；L为长时间观察得到的平均请求数量；λ为新请求的到达率。

例如每秒有10个请求到达，并且每个请求消耗1秒进行处理。这种情况下需要创建具有10个线程容量的线程池，从而保证正常的响应时间。

3 线程池容量估算

服务器性能以该服务器的响应时间、吞吐量与CPU利用率来衡量。系统可利用的资源包括CPU核心数目与内存等。处理器执行周期衡量了处理器的处理速度，同时也是线程池管理的主要资源[10]。

JDK从1.5开始提供了ThreadPoolExecutor类管理线程池，该类提供了一系列接口配置与实时定制线程池容量，其可配置参数为CorePoolSize(核心大小)、MaximumPoolSize(最大值)与KeepAliveTime(线程存活时间)[11]。其中核心线程池尺寸可以通过设置这三个参数来达到线程池最优性能。而最大线程池尺寸一般不超过系统的资源限制。给出公式如下：

(2)

其中，Nt为需要设置的核心线程数目；Nc为当前CPU的可用核心数；Nu为预期的CPU核心利用率，为任务的等待时间与计算时间的比值。

4 线程池性能测试

构建简单的网络服务器，用Java代码实现服务器主线程代码片段(服务器绑定端口为8080)，如下：

ThreadPoolExecutor exec=prepareThreadPool();

ServerSocket listener=new ServerSocket(8080);

while(true) {

Socket sock=listener.accept();

exec.execute(new Task(sock));

}

线程池线程的任务是服务用户的响应，并模拟出1 ms的运算延时[1]。

public class Task implementsRunnable {

private Socketsocket;

public Task(Socket socket) {

this.socket=socket;

}

public void run() {

for(longi=0;i<10;i++);

try {

outPutData(socket);

}catch (IOException e) {

e.printStackTrace();

}

}

性能测试从CPU的利用率与响应时间两个参数进行测试[12]。服务器为每个请求执行0.1 ms的服务时间。并且预期的CPU利用率为60%，请求的平均等待时间与计算时间之比为500(预期等待时间为0.2 s)，根据容量估算公式得到相应的估算容量为600[13]。

在测量CPU利用率上，用户并发数采样点分别为[1,2,4,8,16,32,64,128,256,512,1 024]。监控CPU使用率，并通过Matlab绘制曲线[14-15]。

其CPU利用率如图4所示。在核心并发请求数不超过600时，CPU利用率线性增加，由于线程池并发线程数的影响，CPU利用率逐渐上升并稳定。

图4 CPU利用率与请求数目的关系

测试响应时间时，并发请求数从0至1 200，相邻采样间隔为50。测量每组给定的并发请求数目下的系统平均响应时间，记录并绘图。

其响应时间随并发连接数的关系如图5所示。在并发连接600以内可以保证稳定的系统响应时间(ms)。由于资源的竞争与大量请求的入队，系统的响应时间相应增加，当达到系统的最高负载后，拒绝新的请求。

图5 CPU利用率与请求数目的关系

5 结束语

为了降低因频繁创建线程而导致的巨大系统开销，在研究线程池工作原理的基础上，提出了线程池容量的估算方法。以服务器的CPU使用率与系统响应时间作为衡量标准，对线程池容量估算方法进行了有效性测试。结果表明，采用该方法的服务器在各种负载条件下均能满足有效的CPU利用率与稳定的系统响应时间，既保证了整体稳定性，又能提供稳定的吞吐量。

[1] 张垠波．线程池技术在并发服务器中的应用[J]．计算机与数字工程，2012,40(7):153-156.

[2] Ling Yibei，Mullen T，Lin Xiaola．Analysis of optimal thread pool size[J].ACM SIGOPS Operating Systems Review,2000,34(2):43-45.

[3] 李 昊，刘志镜．线程池技术的研究[J]．现代电子技术，2004,27(3):77-80.

[4] 詹新林，王公亭，徐晓钟.基于线程池数据分析系统的设计与实现[J]．微计算机信息，2008,24(33):266-268.

[5] 张尧学，宋 虹，张 高.计算机操作系统教程[M].第4版.北京：清华大学出版社，2013.

[6] 封 玮，周世平．Java中的线程池及实现[J].计算机系统应用，2004(8)：16-18.

[7] 王俊峰．一种实时集群系统负载均衡通用模型的研究及应用[D]．长沙：湖南大学，2008.

[8] 欧昌华，李炳法．线程池在网络服务器程序中的应用[J]．信息技术，2002(5)：11-14.

[9] 宋立昊．基于线程池的WEB服务器实现和监测[D]．长春：吉林大学，2011.

[10] 王 华,马 亮,顾 明.线程池技术研究与应用[J].计算机应用研究,2005，22(11):141-142.

[11] Pyarali I,Spivak M,Cytron R,et al.Evaluating and optimizing thread pool strategies for real-time CORBA[J].ACM SIGPLAN Notices,2001,36(8):214-222.

[13] 刘雪梅.服务器端软件性能分析和诊断[M].北京：北京邮电大学出版社，2011.

[14] Belkin R.Mechanism for obtaining a thread from,and returning a thread to,a thread pool without attaching and detaching:U.S.，6 766 349[P].2004-07-20.

[15] 许俊奎，徐凤刚，潘 清．Web服务器性能测试工具的设计与实现[J]．计算机测量与控制，2005,13(11):1204-1206.

Application of Thread Pool Technique in Network Server

JI Li，PAN Lin-yun，LIU Yao

(College of Communications and Systems Engineering,Nanjing University of Posts and Telecommunications,Nanjing 210003,China)

Network servers often use C/S architecture as the main framework currently.The server needs to create a thread frequently in response to a client short or long and continuous service requests.Each type of server requests are required to be able to provide a stable system load according to the response time for the request and guarantee the stability of the server system under the high concurrency.Traditional multi-threading technology can provide excellent performance in the concurrent server,but can lead to huge system overhead because of its frequent thread creation and destruction.An optimization method for estimating the capacity has been proposed according to the disadvantages of common thread pool capacity estimation so as to improve the thread pool server performance,in which the introduction of the thread pool is employed to solve the instability because of a large number of client request thread creation and destruction causing borderless.Thread pool performance testing and verification results show that thread pool takes a more excellent concurrency control strategy and has provided the stable throughput for the server.

multi-threading;thread pool;thread pool size;server

2016-06-02

2016-09-15 网络出版时间：2017-06-05

国家自然科学基金资助项目(61271234)

吉 利(1990-)，男，硕士，研究方向为卫星通信技术。

http://kns.cnki.net/kcms/detail/61.1450.TP.20170605.1506.024.html

TP39

A

1673-629X(2017)08-0149-03

10.3969/j.issn.1673-629X.2017.08.031