线程池的原理:?????
目前，一些著名的大公司都特别看好这项技术，并早已经在他们的产品中应用该技术。比如IBM的WebSphere，IONA的Orbix 2000在SUN的 Jini中，Microsoft的MTS（Microsoft Transaction Server 2.0），COM+等。现在您是否也想在服务器程序应用该项技术?线程池技术如何提高服务器程序的性能我所提到服务器程序是指能够接受客户请求并能处理请求的程序，而不只是指那些接受网络客户请求的网络服务器程序。多线程技术主要解决处理器单元内多个线程执行的问题，它可以显著减少处理器单元的闲置时间，增加处理器单元的吞吐能力。但如果对多线程应用不当，会增加对单个任务的处理时间。可以举一个简单的例子：假设在一台服务器完成一项任务的时间为TT1 创建线程的时间
T2 在线程中执行任务的时间，包括线程间同步所需时间
T3 线程销毁的时间显然T ＝ T1＋T2＋T3。注意这是一个极度简化的假设。可以看出T1,T3是多线程本身的带来的开销，我们渴望减少T1,T3所用的时间，从而减少T的时间。但一些线程的使用者并没有注意到这一点，所以在程序中频繁的创建或销毁线程，这导致T1和T3在T中占有相当比例。显然这是突出了线程的弱点（T1，T3），而不是优点（并发性）。线程池技术正是关注如何缩短或调整T1,T3时间的技术，从而提高服务器程序性能的。它把T1，T3分别安排在服务器程序的启动和结束的时间段或者一些空闲的时间段，这样在服务器程序处理客户请求时，不会有T1，T3的开销了。线程池不仅调整T1,T3产生的时间段，而且它还显著减少了创建线程的数目。在看一个例子：假设一个服务器一天要处理50000个请求，并且每个请求需要一个单独的线程完成。我们比较利用线程池技术和不利于线程池技术的服务器处理这些请求时所产生的线程总数。在线程池中，线程数一般是固定的，所以产生线程总数不会超过线程池中线程的数目或者上限（以下简称线程池尺寸），而如果服务器不利用线程池来处理这些请求则线程总数为50000。一般线程池尺寸是远小于50000。所以利用线程池的服务器程序不会为了创建50000而在处理请求时浪费时间，从而提高效率。这些都是假设，不能充分说明问题，下面我将讨论线程池的简单实现并对该程序进行对比测试，以说明线程技术优点及应用领域。线程池的简单实现及对比测试一般一个简单线程池至少包含下列组成部分。线程池管理器（ThreadPoolManager）:用于创建并管理线程池?
工作线程（WorkThread）: 线程池中线程?
任务接口（Task）:每个任务必须实现的接口，以供工作线程调度任务的执行。?
任务队列:用于存放没有处理的任务。提供一种缓冲机制。?
线程池管理器至少有下列功能：创建线程池，销毁线程池，添加新任务创建线程池的部分代码如下：
??…
? ?? ???//create threads
? ?? ???synchronized(workThreadVector)
? ?? ???{
? ?? ?? ?? ?for(int j = 0; j < i; j++)
? ?? ?? ?? ?{
? ?? ?? ?? ?? ? threadNum++;
? ?? ?? ?? ?? ?WorkThread workThread = new WorkThread(taskVector, threadNum);
? ?? ?? ?? ?? ? workThreadVector.addElement(workThread);
? ?? ?? ?? ?}? ?? ???}
…
注意同步workThreadVector并没有降低效率，相反提高了效率,请参考Brian Goetz的文章。 销毁线程池的部分代码如下：
??…
? ?? ???while(!workThreadVector.isEmpty())
? ?? ???{
? ?? ???if(debugLevel > 2)
? ?? ?? ?System.out.println("stop:"+(i));
? ?? ?? ?i++;
? ?? ?? ?? ?try
? ?? ?? ?? ?{
? ?? ?? ?? ?? ? WorkThread workThread = (WorkThread)workThreadVector.remove(0);
? ?? ?? ?? ?? ? workThread.closeThread();
? ?? ?? ?? ?? ? continue;
? ?? ?? ?? ?}
? ?? ?? ?? ?catch(Exception exception)
? ?? ?? ?? ?{
? ?? ?? ?? ?? ? if(debugLevel > 2)
? ?? ?? ?? ?? ?? ???exception.printStackTrace();
? ?? ?? ?? ?}
? ?? ?? ?? ?break;
? ?? ???}
? ?…
? ?添加新任务的部分代码如下：
? ?…
? ?? ???synchronized(taskVector)
? ?? ???{
? ?? ?? ?? ?taskVector.addElement(taskObj);
? ?? ?? ?? ?taskVector.notifyAll();
? ?? ???}
? ?…
? ?工作线程是一个可以循环执行任务的线程，在没有任务时将等待。由于代码比较多在此不罗列.任务接口是为所有任务提供统一的接口，以便工作线程处理。任务接口主要规定了任务的入口，任务执行完后的收尾工作，任务的执行状态等。在文章结尾有相关代码的下载。以上所描述的线程池结构很简单，一些复杂的线程池结构将不再此讨论。在下载代码中有测试驱动程序（TestThreadPool），我利用这个测试程序的输出数据统计出下列测试结果。测试有两个参数要设置：线程池中线程数，即线程池尺寸。?
要完成的任务数。?
分别将一个参数固定，另一个参数变动以考察两个参数所产生的不同结果。所用测试机器分别为普通PC机（Win2000 JDK1.3.1）和SUN服务器(Solaris Unix JDK1.3.1)，机器配置在此不便指明。表1:测试数据及对应结果?
线程池尺寸 任务数 没有应用线程池所用的时间（单位:毫秒，OS:win） 应用线程池所用的时间（单位:毫秒，OS:win） 没有应用线程池所用的时间（单位:毫秒，OS:Solaris） 应用线程池所用的时间（单位:毫秒，OS:Solaris）?
1 5000 3896 130 6513 327?
2 5000 3455 151 6221 659?
4 5000 3425 120 5448 433?
8 5000 3475 160 5769 1478?
16 5000 3505 211 5785 1970?
32 5000 3455 251 6403 875?
64 5000 3595 501 5182 1103?
128 5000 3515 881 5154 405?
256 5000 3495 3104 5502 1589?
512 5000 3425 5488 5667 1262?
16 1 20 0 22 3?
16 2 20 20 21 13?
16 4 20 10 27 10?
16 8 20 20 22 24?
16 16 30 20 29 48?
16 32 40 20 46 108?
16 64 60 20 72 199?
16 128 110 20 148 335?
16 256 201 20 252 132?
16 512 411 40 522 382?
16 1024 811 71 1233 610?
16 2048 1552 80 2045 135?
16 4096 2874 250 4828 787?
图1.线程池的尺寸的对服务器程序的性能影响?
根据以上统计数据可得出下图：图2.任务数对服务器程序的冲击?数据分析如下：图1是改变线程池尺寸对服务器性能的影响，在该测试过程中，服务器的要完成的任务数固定为为5000。从图1中可以看出合理配置线程池尺寸对于大量任务处理的效率有非常明显的提高，但是一旦尺寸选择不合理（过大或过小）就会严重降低影响服务器性能。理论上"过小"将出现任务不能及时处理的情况,但在图表中显示出某些小尺寸的线程池表现很好，这是因为测试驱动中有很多线程同步开销，且这个开销相对于完成单个任务的时间是不能忽略的。"过大"则会出现线程间同步开销太大的问题，而且在线程间切换很耗CPU时间，在图表显示的很清楚。可见任何一个好技术，如果滥用都会造成灾难性后果。图2是用不同数量的任务来冲击服务器程序，在该测试过程中，服务器线程池尺寸固定为16。可以看出线程池在处理少量任务时的优势不明显。所以线程池技术有一定的适应范围，关于适用范围将在后面讨论。但对于大量的任务的处理，线程池的优势表现非常卓越，服务器程序处理请求的时间虽然有波动，但是其平均值相对小多了。值得注意的是测试方案中，统计任务的完成时间没有包含了创建线程池的时间。在实际线程池工作时，即利用线程池处理任务时，创建线程池的时间是不必计算在内的。由于测试驱动程序有很多同步代码，特别是等待线程执行完毕的同步（代码中为sleepToWait(long l)方法的调用），这些代码降低了代码执行效率，这是测试驱动一个缺点，但这个测试驱动可以说明线程池相对于简单使用线程的优势。关于高级线程池的探讨简单线程池存在一些问题，比如如果有大量的客户要求服务器为其服务，但由于线程池的工作线程是有限的，服务器只能为部分客户服务，其它客户提交的任务，只能在任务队列中等待处理。一些系统设计人员可能会不满这种状况，因为他们对服务器程序的响应时间要求比较严格，所以在系统设计时可能会怀疑线程池技术的可行性，但是线程池有相应的解决方案。调整优化线程池尺寸是高级线程池要解决的一个问题。主要有下列解决方案：方案一：动态增加工作线程在一些高级线程池中一般提供一个可以动态改变的工作线程数目的功能，以适应突发性的请求。一旦请求变少了将逐步减少线程池中工作线程的数目。当然线程增加可以采用一种超前方式，即批量增加一批工作线程，而不是来一个请求才建立创建一个线程。批量创建是更加有效的方式。该方案还有应该限制线程池中工作线程数目的上限和下限。否则这种灵活的方式也就变成一种错误的方式或者灾难，因为频繁的创建线程或者短时间内产生大量的线程将会背离使用线程池原始初衷--减少创建线程的次数。举例：Jini中的TaskManager，就是一个精巧线程池管理器，它是动态增加工作线程的。SQL Server采用单进程(Single Process)多线程(Multi-Thread)的系统结构，1024个数量的线程池，动态线程分配，理论上限32767。方案二：优化工作线程数目如果不想在线程池应用复杂的策略来保证工作线程数满足应用的要求，你就要根据统计学的原理来统计客户的请求数目，比如高峰时段平均一秒钟内有多少任务要求处理，并根据系统的承受能力及客户的忍受能力来平衡估计一个合理的线程池尺寸。线程池的尺寸确实很难确定，所以有时干脆用经验值。举例：在MTS中线程池的尺寸固定为100。方案三：一个服务器提供多个线程池在一些复杂的系统结构会采用这个方案。这样可以根据不同任务或者任务优先级来采用不同线程池处理。举例：COM+用到了多个线程池。这三种方案各有优缺点。在不同应用中可能采用不同的方案或者干脆组合这三种方案来解决实际问题。线程池技术适用范围及应注意的问题下面是我总结的一些线程池应用范围,可能是不全面的。线程池的应用范围：需要大量的线程来完成任务，且完成任务的时间比较短。
WEB服务器完成网页请求这样的任务，使用线程池技术是非常合适的。因为单个任务小，而任务数量巨大，你可以想象一个热门网站的点击次数。
但对于长时间的任务，比如一个Telnet连接请求，线程池的优点就不明显了。因为Telnet会话时间比线程的创建时间大多了。对性能要求苛刻的应用，比如要求服务器迅速相应客户请求。?
接受突发性的大量请求，但不至于使服务器因此产生大量线程的应用。
突发性大量客户请求，在没有线程池情况下，将产生大量线程，虽然理论上大部分操作系统线程数目最大值不是问题，短时间内产生大量线程可能使内存到达极限，并出现"OutOfMemory"的错误。?
结束语本文只是简单介绍线程池技术。可以看出线程池技术对于服务器程序的性能改善是显著的。线程池技术在服务器领域有着广泛的应用前景。希望这项技术能够应用到您的多线程服务程序中。参考资料Danny Ayers 等:Professional Java Server Programming
Tarak Modi: Why Thread Pools are Important in Java
Brett Spell :Professional java Programming
Jini(TM) v1.2.1代码
Brian Goetz 的 Java 理论和实践专栏
????? 来看一下线程池究竟是怎么一回事？其实线程池的原理很简单，类似于操作系统中的缓冲区的概念，它的流程如下：先启动若干数量的线程，并让这些线程都处于睡眠状态，当客户端有一个新请求时，就会唤醒线程池中的某一个睡眠线程，让它来处理客户端的这个请求，当处理完这个请求后，线程又处于睡眠状态。可能你也许会问：为什么要搞得这么麻烦，如果每当客户端有新的请求时，我就创建一个新的线程不就完了？这也许是个不错的方法，因为它能使得你编写代码相对容易一些，但你却忽略了一个重要的问题??性能！就拿我所在的单位来说，我的单位是一个省级数据大集中的银行网络中心，高峰期每秒的客户端请求并发数超过100，如果为每个客户端请求创建一个新线程的话，那耗费的CPU时间和内存将是惊人的，如果采用一个拥有200个线程的线程池，那将会节约大量的的系统资源，使得更多的CPU时间和内存用来处理实际的商业应用，而不是频繁的线程创建与销毁。
???数据库连接池:
?????
???? 数据库连接是一种关键的有限的昂贵的资源，这一点在多用户的网页应用程序中体现得尤为突出。
?? ? 一个数据库连接对象均对应一个物理数据库连接，每次操作都打开一个物理连接，使用完都关闭连接，这样造成系统的 性能低下。 数据库连接池的解决方案是在应用程序启动时建立足够的数据库连接，并讲这些连接组成一个连接池(池”里放了好多半成品的数据库联接对象)，由应用程序动态地对池中的连接进行申请、使用和释放。对于多于连接池中连接数的并发请求，应该在请求队列中排队等待。并且应用程序可以根据池中连接的使用率，动态增加或减少池中的连接数。?
?? ?连接池技术尽可能多地重用了消耗内存地资源，大大节省了内存，提高了服务器地服务效率，能够支持更多的客户服务。通过使用连接池，将大大提高程序运行效率，同时，我们可以通过其自身的管理机制来监视数据库连接的数量、使用情况等。
??? 1) 最小连接数是连接池一直保持的数据库连接，所以如果应用程序对数据库连接的使用量不大，将会有大量的数据库连接资源被浪费；?
??? 2) 最大连接数是连接池能申请的最大连接数，如果数据库连接请求超过此数，后面的数据库连接请求将被加入到等待队列中，这会影响之后的数据库操作。
目前，一些著名的大公司都特别看好这项技术，并早已经在他们的产品中应用该技术。比如IBM的WebSphere，IONA的Orbix 2000在SUN的 Jini中，Microsoft的MTS（Microsoft Transaction Server 2.0），COM+等。现在您是否也想在服务器程序应用该项技术?线程池技术如何提高服务器程序的性能我所提到服务器程序是指能够接受客户请求并能处理请求的程序，而不只是指那些接受网络客户请求的网络服务器程序。多线程技术主要解决处理器单元内多个线程执行的问题，它可以显著减少处理器单元的闲置时间，增加处理器单元的吞吐能力。但如果对多线程应用不当，会增加对单个任务的处理时间。可以举一个简单的例子：假设在一台服务器完成一项任务的时间为TT1 创建线程的时间
T2 在线程中执行任务的时间，包括线程间同步所需时间
T3 线程销毁的时间显然T ＝ T1＋T2＋T3。注意这是一个极度简化的假设。可以看出T1,T3是多线程本身的带来的开销，我们渴望减少T1,T3所用的时间，从而减少T的时间。但一些线程的使用者并没有注意到这一点，所以在程序中频繁的创建或销毁线程，这导致T1和T3在T中占有相当比例。显然这是突出了线程的弱点（T1，T3），而不是优点（并发性）。线程池技术正是关注如何缩短或调整T1,T3时间的技术，从而提高服务器程序性能的。它把T1，T3分别安排在服务器程序的启动和结束的时间段或者一些空闲的时间段，这样在服务器程序处理客户请求时，不会有T1，T3的开销了。线程池不仅调整T1,T3产生的时间段，而且它还显著减少了创建线程的数目。在看一个例子：假设一个服务器一天要处理50000个请求，并且每个请求需要一个单独的线程完成。我们比较利用线程池技术和不利于线程池技术的服务器处理这些请求时所产生的线程总数。在线程池中，线程数一般是固定的，所以产生线程总数不会超过线程池中线程的数目或者上限（以下简称线程池尺寸），而如果服务器不利用线程池来处理这些请求则线程总数为50000。一般线程池尺寸是远小于50000。所以利用线程池的服务器程序不会为了创建50000而在处理请求时浪费时间，从而提高效率。这些都是假设，不能充分说明问题，下面我将讨论线程池的简单实现并对该程序进行对比测试，以说明线程技术优点及应用领域。线程池的简单实现及对比测试一般一个简单线程池至少包含下列组成部分。线程池管理器（ThreadPoolManager）:用于创建并管理线程池?
工作线程（WorkThread）: 线程池中线程?
任务接口（Task）:每个任务必须实现的接口，以供工作线程调度任务的执行。?
任务队列:用于存放没有处理的任务。提供一种缓冲机制。?
线程池管理器至少有下列功能：创建线程池，销毁线程池，添加新任务创建线程池的部分代码如下：
??…
? ?? ???//create threads
? ?? ???synchronized(workThreadVector)
? ?? ???{
? ?? ?? ?? ?for(int j = 0; j < i; j++)
? ?? ?? ?? ?{
? ?? ?? ?? ?? ? threadNum++;
? ?? ?? ?? ?? ?WorkThread workThread = new WorkThread(taskVector, threadNum);
? ?? ?? ?? ?? ? workThreadVector.addElement(workThread);
? ?? ?? ?? ?}? ?? ???}
…
注意同步workThreadVector并没有降低效率，相反提高了效率,请参考Brian Goetz的文章。 销毁线程池的部分代码如下：
??…
? ?? ???while(!workThreadVector.isEmpty())
? ?? ???{
? ?? ???if(debugLevel > 2)
? ?? ?? ?System.out.println("stop:"+(i));
? ?? ?? ?i++;
? ?? ?? ?? ?try
? ?? ?? ?? ?{
? ?? ?? ?? ?? ? WorkThread workThread = (WorkThread)workThreadVector.remove(0);
? ?? ?? ?? ?? ? workThread.closeThread();
? ?? ?? ?? ?? ? continue;
? ?? ?? ?? ?}
? ?? ?? ?? ?catch(Exception exception)
? ?? ?? ?? ?{
? ?? ?? ?? ?? ? if(debugLevel > 2)
? ?? ?? ?? ?? ?? ???exception.printStackTrace();
? ?? ?? ?? ?}
? ?? ?? ?? ?break;
? ?? ???}
? ?…
? ?添加新任务的部分代码如下：
? ?…
? ?? ???synchronized(taskVector)
? ?? ???{
? ?? ?? ?? ?taskVector.addElement(taskObj);
? ?? ?? ?? ?taskVector.notifyAll();
? ?? ???}
? ?…
? ?工作线程是一个可以循环执行任务的线程，在没有任务时将等待。由于代码比较多在此不罗列.任务接口是为所有任务提供统一的接口，以便工作线程处理。任务接口主要规定了任务的入口，任务执行完后的收尾工作，任务的执行状态等。在文章结尾有相关代码的下载。以上所描述的线程池结构很简单，一些复杂的线程池结构将不再此讨论。在下载代码中有测试驱动程序（TestThreadPool），我利用这个测试程序的输出数据统计出下列测试结果。测试有两个参数要设置：线程池中线程数，即线程池尺寸。?
要完成的任务数。?
分别将一个参数固定，另一个参数变动以考察两个参数所产生的不同结果。所用测试机器分别为普通PC机（Win2000 JDK1.3.1）和SUN服务器(Solaris Unix JDK1.3.1)，机器配置在此不便指明。表1:测试数据及对应结果?
线程池尺寸 任务数 没有应用线程池所用的时间（单位:毫秒，OS:win） 应用线程池所用的时间（单位:毫秒，OS:win） 没有应用线程池所用的时间（单位:毫秒，OS:Solaris） 应用线程池所用的时间（单位:毫秒，OS:Solaris）?
1 5000 3896 130 6513 327?
2 5000 3455 151 6221 659?
4 5000 3425 120 5448 433?
8 5000 3475 160 5769 1478?
16 5000 3505 211 5785 1970?
32 5000 3455 251 6403 875?
64 5000 3595 501 5182 1103?
128 5000 3515 881 5154 405?
256 5000 3495 3104 5502 1589?
512 5000 3425 5488 5667 1262?
16 1 20 0 22 3?
16 2 20 20 21 13?
16 4 20 10 27 10?
16 8 20 20 22 24?
16 16 30 20 29 48?
16 32 40 20 46 108?
16 64 60 20 72 199?
16 128 110 20 148 335?
16 256 201 20 252 132?
16 512 411 40 522 382?
16 1024 811 71 1233 610?
16 2048 1552 80 2045 135?
16 4096 2874 250 4828 787?
图1.线程池的尺寸的对服务器程序的性能影响?
根据以上统计数据可得出下图：图2.任务数对服务器程序的冲击?数据分析如下：图1是改变线程池尺寸对服务器性能的影响，在该测试过程中，服务器的要完成的任务数固定为为5000。从图1中可以看出合理配置线程池尺寸对于大量任务处理的效率有非常明显的提高，但是一旦尺寸选择不合理（过大或过小）就会严重降低影响服务器性能。理论上"过小"将出现任务不能及时处理的情况,但在图表中显示出某些小尺寸的线程池表现很好，这是因为测试驱动中有很多线程同步开销，且这个开销相对于完成单个任务的时间是不能忽略的。"过大"则会出现线程间同步开销太大的问题，而且在线程间切换很耗CPU时间，在图表显示的很清楚。可见任何一个好技术，如果滥用都会造成灾难性后果。图2是用不同数量的任务来冲击服务器程序，在该测试过程中，服务器线程池尺寸固定为16。可以看出线程池在处理少量任务时的优势不明显。所以线程池技术有一定的适应范围，关于适用范围将在后面讨论。但对于大量的任务的处理，线程池的优势表现非常卓越，服务器程序处理请求的时间虽然有波动，但是其平均值相对小多了。值得注意的是测试方案中，统计任务的完成时间没有包含了创建线程池的时间。在实际线程池工作时，即利用线程池处理任务时，创建线程池的时间是不必计算在内的。由于测试驱动程序有很多同步代码，特别是等待线程执行完毕的同步（代码中为sleepToWait(long l)方法的调用），这些代码降低了代码执行效率，这是测试驱动一个缺点，但这个测试驱动可以说明线程池相对于简单使用线程的优势。关于高级线程池的探讨简单线程池存在一些问题，比如如果有大量的客户要求服务器为其服务，但由于线程池的工作线程是有限的，服务器只能为部分客户服务，其它客户提交的任务，只能在任务队列中等待处理。一些系统设计人员可能会不满这种状况，因为他们对服务器程序的响应时间要求比较严格，所以在系统设计时可能会怀疑线程池技术的可行性，但是线程池有相应的解决方案。调整优化线程池尺寸是高级线程池要解决的一个问题。主要有下列解决方案：方案一：动态增加工作线程在一些高级线程池中一般提供一个可以动态改变的工作线程数目的功能，以适应突发性的请求。一旦请求变少了将逐步减少线程池中工作线程的数目。当然线程增加可以采用一种超前方式，即批量增加一批工作线程，而不是来一个请求才建立创建一个线程。批量创建是更加有效的方式。该方案还有应该限制线程池中工作线程数目的上限和下限。否则这种灵活的方式也就变成一种错误的方式或者灾难，因为频繁的创建线程或者短时间内产生大量的线程将会背离使用线程池原始初衷--减少创建线程的次数。举例：Jini中的TaskManager，就是一个精巧线程池管理器，它是动态增加工作线程的。SQL Server采用单进程(Single Process)多线程(Multi-Thread)的系统结构，1024个数量的线程池，动态线程分配，理论上限32767。方案二：优化工作线程数目如果不想在线程池应用复杂的策略来保证工作线程数满足应用的要求，你就要根据统计学的原理来统计客户的请求数目，比如高峰时段平均一秒钟内有多少任务要求处理，并根据系统的承受能力及客户的忍受能力来平衡估计一个合理的线程池尺寸。线程池的尺寸确实很难确定，所以有时干脆用经验值。举例：在MTS中线程池的尺寸固定为100。方案三：一个服务器提供多个线程池在一些复杂的系统结构会采用这个方案。这样可以根据不同任务或者任务优先级来采用不同线程池处理。举例：COM+用到了多个线程池。这三种方案各有优缺点。在不同应用中可能采用不同的方案或者干脆组合这三种方案来解决实际问题。线程池技术适用范围及应注意的问题下面是我总结的一些线程池应用范围,可能是不全面的。线程池的应用范围：需要大量的线程来完成任务，且完成任务的时间比较短。
WEB服务器完成网页请求这样的任务，使用线程池技术是非常合适的。因为单个任务小，而任务数量巨大，你可以想象一个热门网站的点击次数。
但对于长时间的任务，比如一个Telnet连接请求，线程池的优点就不明显了。因为Telnet会话时间比线程的创建时间大多了。对性能要求苛刻的应用，比如要求服务器迅速相应客户请求。?
接受突发性的大量请求，但不至于使服务器因此产生大量线程的应用。
突发性大量客户请求，在没有线程池情况下，将产生大量线程，虽然理论上大部分操作系统线程数目最大值不是问题，短时间内产生大量线程可能使内存到达极限，并出现"OutOfMemory"的错误。?
结束语本文只是简单介绍线程池技术。可以看出线程池技术对于服务器程序的性能改善是显著的。线程池技术在服务器领域有着广泛的应用前景。希望这项技术能够应用到您的多线程服务程序中。参考资料Danny Ayers 等:Professional Java Server Programming
Tarak Modi: Why Thread Pools are Important in Java
Brett Spell :Professional java Programming
Jini(TM) v1.2.1代码
Brian Goetz 的 Java 理论和实践专栏
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
