java 并发线程个数的确定
本文从控制变量的角度来谈决定线程个数的依据。模型很简单，在实际的生产环境中，情况肯定比下文要复杂的多。要充分的进行测试，以使线程个数为优。
java应用程序大概分为两种：cpu密集型和io密集型。
cpu密集型
就是指线程大部分时间都在用cpu，一般来说，普通的操作都需要用到cpu，比如计算，读取，循环，赋值，查询，排序等等。在最理想的情况下，大牛们建议将线程数设置为count(cpu)+-1
io密集型
io操作一般不需要cpu的参与，线程在io时，线程会被阻塞（线程的六个状态之一就有Blocked）如果一个线程完成某项工作一共需要100ms,其中io需要80ms,cpu需要20ms(忽略其他时间).那么线程数应该设立为5.
有锁的情况
多线程为了安全，往往会加锁。对于关键代码（被频繁调用的代码），往往可以成为线程个数的依据之一。
对于全局锁（比如static上锁），无论多少个线程，代码都是串行执行的。这样线程越多反而越不好。对于锁粒度的越小，对于线程并发来说越有利。比如ConcurrentHashMap来说，分了16个segment，也就是加了16把锁。
在理性的情况下，锁粒度可以降低16倍，那么自然可以允许16个并发。最坏的情况是16个线程去争用一个segment。这个线程的个数需要根据实际情况去调优。
java 线程池线程数量确定思路
多线程可以快速执行任务的原理
因为服务器是拥有多个处理器核心的。运行某进程时，如果只有一个线程，则只能调动一个处理器核心，其他处理器核心可能处于空闲状态。如果是多线程，则可以调用多个处理器核心，用最大效率去处理任务。
创建线程池需要的参数
创建线程池一般需要参数有：核心线程数，最大线程数，线程销毁时间，任务队列，拒绝策略等。
线程池里的线程分为两种，分别是核心线程和非核心线程。当线程池接收到任务时，会先创建核心线程数去处理任务，直至待处理的任务数量超过任务队列长度和核心线程数之和时，会继续创建非核心线程直至最大线程数。
线程池接收到的任务数量在即将超过任务队列长度和最大线程数之和时，会触发拒绝策略处理该任务。
非核心线程在执行完成后会立即销毁，核心线程则会等待设置的销毁时间后再进行销毁。
当任务队列长度足够大时，核心线程数和最大线程数相等，不然不能触发到创建非核心线程
确定线程数
线程数计算公式为：
Nthreads=NcpuUcpu(1+w/c) =Ncpu*(1+w/c)
其中 Nthreads:线程数；Ncpu:处理器核心数；Ucpu：处理器的使用百分比；W/C：等待时间与计算时间的比率
Ncpu可以通过以下代码获取
Runtime.getRuntime().availableProcessors()
等待时间与计算时间的比率
针对IO密集型的，阻塞耗时w一般都是计算耗时几倍c，假设阻塞耗时=计算耗时的情况下，Nthreads=Ncpu*(1+1)=2Ncpu。所以这种情况下，考虑2倍的CPU核心数做为线程数
对于计算密集型的，阻塞耗时趋于0，即w/c趋于0，公式Nthreads = Ncpu。
线程数一般是处理器核心数的整数倍。线程数设置过多，在多任务并发情况下，则会影响服务器的整体运行速度；设置过少，则不能最大化应用服务器性能。所以需要根据具体业务来具体调整。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。