线程池大小设定

    网上看到有人说线程池大小设定原则，其主要问题就是怕设置大了影响性能。我以前也是这么认为，因为首先书上这么写的，其次是像weblogic有自调优线程池.也间接论证了需要仔细设定线程池大小。
    不过有一次心血来潮，想写一个自调优线程池的时候，（使用HP小型机做的调试）发现实际情况不是这样。线程设置大一些，并不会对应用有多大的负面效果，充其量CPU消费可能比最佳线程数大小多一点点。相反，不可以找这个最佳值，设定一个较为大的值是有好处的。因为如果特定应用属于高IO，低计算的易用，如数据库存储，那么处理线程池当然是越大越好。对于以计算为主的，譬如大量的xml解析，及时设置过大的线程数，但因为操作系统内核线程数固定，虚拟机线程只能映射到固定的内核线程上，所以，设置多少都没有关系了。

   本来测试的有一组数据，就懒得公布了。结论就是线程池设置大一些，没有关系的 ：）

评论

8 楼 mvpwar 2011-02-16  

都是高手啊，学习学习

7 楼 javamonkey 2011-02-15  

频繁切换是因为业务逻辑的要求，譬如读一个文件，访问数据库等，线程频繁切换是要造成影响，可这跟设置线程池大小有什么关系？

6 楼 iaimstar 2011-02-15  

我好像写错了、、、、防止误导 删了

5 楼 aofeng 2011-02-14  

对于以计算为主的，譬如大量的xml解析，及时设置过大的线程数，但因为操作系统内核线程数固定，虚拟机线程只能映射到固定的内核线程上，所以，设置多少都没有关系了。

？？？

不能过大，过多的线程会给CPU造成负担，各线程之间的切换也会消耗资源。如果线程池是针对数据库和文件操作，就更加要适量。可以通过测试得出合理利用资源的数量。具体的环境要具体测试才能得出最佳数据。

4 楼 jellyfish 2011-02-14  

two other considerations when using threads are:
1. CPU has L1/2/3 level caches, cache miss has a high performance penality.
2. Thread context switching also has performance penalty.

So frequently switching of threads might not be a good idea.

3 楼 DAOException 2011-02-14  

javamonkey 写道

yangyi 写道

CPU敏感应用：N 或者 N+1，如存在阻塞I/O，则因非所有线程都占用CPU，需要更多线程，其数量一般为：N*(1+WT/ST)，其中WT/ST是等待时间和服务时间比，N为CPU Core数。一般来说，可以用NIO来替换BIO这样就可以省去额外线程所需的资源，包括CPU，内存等。当线程池大到一定程度时，I/O，FD，数据库连接等都可能成为新的瓶颈。

看不懂，不过最后一句话结论是认同的，因为线程池设置过大，如果其他地方，譬如数据库连接实际上也要用到自己的线程池。会有显著的影响的

他的意思是合理利用CPU资源，不管在阻塞或者非阻塞的情况下，尽量不让CPU空闲下来

2 楼 javamonkey 2011-02-14  

yangyi 写道

CPU敏感应用：N 或者 N+1，如存在阻塞I/O，则因非所有线程都占用CPU，需要更多线程，其数量一般为：N*(1+WT/ST)，其中WT/ST是等待时间和服务时间比，N为CPU Core数。一般来说，可以用NIO来替换BIO这样就可以省去额外线程所需的资源，包括CPU，内存等。当线程池大到一定程度时，I/O，FD，数据库连接等都可能成为新的瓶颈。

看不懂，不过最后一句话结论是认同的，因为线程池设置过大，如果其他地方，譬如数据库连接实际上也要用到自己的线程池。会有显著的影响的

1 楼 yangyi 2011-02-12  

CPU敏感应用：N 或者 N+1，如存在阻塞I/O，则因非所有线程都占用CPU，需要更多线程，其数量一般为：N*(1+WT/ST)，其中WT/ST是等待时间和服务时间比，N为CPU Core数。一般来说，可以用NIO来替换BIO这样就可以省去额外线程所需的资源，包括CPU，内存等。当线程池大到一定程度时，I/O，FD，数据库连接等都可能成为新的瓶颈。