Java并发编程实战中的描述
给定下列定义:
Ncpu = CPU的数量
Ucpu = 目标CPU的使用率, 0 <= Ucpu <= 1
W/C = 等待时间与计算时间的比率
为保持处理器达到期望的使用率,最优的池的大小等于:
Nthreads = Ncpu x Ucpu x (1 + W/C)
你可以使用Runtime来获得CPU的数目:
int N_CPUS = Runtime.getRuntime().availableProcessors();
当然,CPU周期并不是唯一你可以使用线程池管理的资源。其他可以约束资源池大小的资源包括:内存、文件句柄、套接字句柄和数据库连接等。计算这些类型资源池的大小约束非常简单:首先累加出每一个任务需要的这些资源的总童,然后除以可用的总量。所 得的结果是池大小的上限。
Java 虚拟机并发编程中的描述
为了解决上述难题,我们希望至少可以创建处理器核心数那么多个线程。这就保证了有尽可能多地处理器核心可以投入到解决问题的工作中去。通过下面的代码,我们可以很容易地获取到系统可用的处理器核心数:
Runtime.getRuntime().availableProcessors();
所以,应用程序的最小线程数应该等于可用的处理器核数。如果所有的任务都是计算密集型的,则创建处理器可用核心数那么多个线程就可以了。在这种情况下,创建更多的线程对程序性能而言反而是不利的。因为当有多个仟务处于就绪状态时,处理器核心需要在线程间频繁进行上下文切换,而这种切换对程序性能损耗较大。但如果任务都是IO密集型的,那么我们就需要开更多的线程来提高性能。
当一个任务执行IO操作时,其线程将被阻塞,于是处理器可以立即进行上下文切换以便处理其他就绪线程。如果我们只有处理器可用核心数那么多个线程的话,则即使有待执行的任务也无法处理,因为我们已经拿不出更多的线程供处理器调度了。
如果任务有50%的时间处于阻塞状态,则程序所需线程数为处理器可用核心数的两倍。 如果任务被阻塞的时间少于50%,即这些任务是计算密集型的,则程序所需线程数将随之减少,但最少也不应低于处理器的核心数。如果任务被阻塞的时间大于执行时间,即该任务是IO密集型的,我们就需要创建比处理器核心数大几倍数量的线程。
我们可以计算出程序所需线程的总数,总结如下:
线程数 = CPU可用核心数/(1 - 阻塞系数),其中阻塞系数的取值在0和1之间。
计算密集型任务的阻塞系数为0,而IO密集型任务的阻塞系数则接近1。一个完全阻塞的任务是注定要挂掉的,所以我们无须担心阻塞系数会达到1。
为了更好地确定程序所需线程数,我们需要知道下面两个关键参数:
- 处理器可用核心数;
- 任务的阻塞系数;
第一个参数很容易确定,我们甚至可以用之前的方法在运行时查到这个值。但确定阻塞系数就稍微困难一些。我们可以先试着猜测,抑或采用一些性能分析工具或java.lang.management API来确定线程花在系统IO操作上的时间与CPU密集任务所耗时间的比值。
如上,在《Programming Concurrency on the JVM Mastering》一书中,给出了估算线程池大小的公式:
线程数 = Ncpu /(1 - 阻塞系数)
对于说法一,假设CPU 100%运转,即撇开CPU使用率这个因素,线程数 = Ncpu x (1 + W/C)。
现在假设将方法二的公式等于方法一公式,即Ncpu /(1 - 阻塞系数)= Ncpu x (1 + W/C),推导出:阻塞系数 = W / (W + C),即阻塞系数 = 阻塞时间 /(阻塞时间 + 计算时间),这个结论在方法二后续中得到印证,如下:
由于对Web服务的请求大部分时间都花在等待服务器响应上了,所以阻塞系数会相当高,因此程序需要开的线程数可能是处理器核心数的若干倍。假设阻塞系数是0.9,即每个任务90%的时间处于阻塞状态而只有10%的时间在干活,则在双核处理器上我们就需要开20个线程(使用第2.1节的公式计算)。如果有很多只股票要处理的话,我们可以在8核处理器上开到80个线程来处理该任务。
由此可见,说法一和说法二其实是一个公式。