Java 确定线程池中工作线程数的大小

以问答形式展开，会更有针对性：
1、工作线程是不是越多越好？

     不是。a、服务器cpu核数有限，所以同时并发或者并行的线程数是有限的，所以1核cpu设置1000个线程是没有意义的。

 b、线程切换也是有开销的。频繁切换线程会使性能降低。

2、调用sleep()函数的时候，县城是否会占用着CPU？

    不占用，sleep()函数切换时会把cpu让出来。accept()阻塞和recv()阻塞时也会让出cpu。

3、cpu单核，做多线程有用吗？

    多线程并发是有用的，但是起的线程数量太多会造成线程频繁上下文切换，开销大，性能衰弱。

    好了，回到我们主题，我们希望确定线程池中核心线程数的大小。之前来看的《java并发编程实战》，里面有讲，要正确地设置线程池的大小，你必须估算出任务的等待时间和计算时间的比值，这种估算不会很精确。也可以使用另一种方式，就是：在某一个基准负载下，分别设置不同大小的线程池来运行应用程序，并观察cpu利用率的水平。

    先将按公式计算线程池的大小，公式如下：

    对于，线程池中线程的个数，在《java虚拟机并发编程》中会定义如下：

    线程数=cpu可用核心数/（1-阻塞系数），其中阻塞系数的取值在[0,1]之间。计算密集型任务的阻塞系数为0，而IO密集型任务的阻塞系数则接近1。一般，我们让线程执行的任务是比较复杂的，不会是单一的计算密集型任务，或者单一的IO密集型任务，通常会夹杂着。那么就需要我们去计算阻塞系数了。阻塞系数的定义就是执行该任务阻塞的时间与（阻塞时间+计算时间）的比值，也就是w/(w+c)。

     两本书中对于可用线程数的定义公式是不一样的，但是到底原理是不是一样的呢?我们用假设法验证一下:假设两个公式计算的线程数是一样的，也就是说，得到如下等式：

也就是说，两本书上的公式原理是一样的，那么我们就可以方便使用了，这边可以考虑使用<java并发编程实战>的公式，因为他考虑到cpu使用率。也就是说我们在实际使用时，可以根据以上的公式计算出，服务器上能够长期存在的线程个数。可以设置CPU的使用率，cpu的可用核数可以通过java中的以下方法获得：

Runtime.getRuntime().availableProcessors()

该方法的注释可以理解用处:

/**
 * Returns the number of processors available to the Java virtual machine.
 *
 * <p> This value may change during a particular invocation of the virtual
 * machine.  Applications that are sensitive to the number of available
 * processors should therefore occasionally poll this property and adjust
 * their resource usage appropriately. </p>
 *
 * @return  the maximum number of processors available to the virtual
 *          machine; never smaller than one
 * @since 1.4
 */
public native int availableProcessors();
/*
返回Java虚拟机可用的处理器数。
     *
      * <p>在特定的虚拟机调用期间，此值可能会更改。 因此，对可用处理器数量敏感的应用程序应偶尔轮询此属性并适当调整其资源使用情况。</ p>
     *
      * @return虚拟机可用的最大处理器数量; 永远不会小于一个


所以在性能敏感的应用中，创建线程池时，最好根据这个值来动态设定线程池的核心线程数。
*/

     那么w/c怎么计算呢？可以将你的需要执行的任务量化，你需要确定哪些步骤是IO操作，哪些步骤的计算操作，然后跑一次，来确定执行这个任务耗费在IO多少时间，耗费在计算上多少时间，两者的比值就是W/C。在知道cpu可用核心数，预期的cpu使用率，和W/C这些值之后就可计算出工作线程数的大小了。

    这边介绍一下一般经验：

    IO密集型：如果存在ID，那么w/c>1，阻塞耗时一般都会比计算耗时的很多倍。如果不想做以上的计算，那么可以设置工作线程数为2倍cpu可用线程数。IO包括：数据库交互，文件上传下载，网络传输等

    计算密集型：工作线程数就是cpu可用核数。这样比较保险