线程不是越多越好，假如你的业务逻辑全部是计算型的(CPU密集型),不涉及到IO，并且只有一个核心。那肯定一个线程最好，多一个线程就多一点线程切换的计算，CPU不能完完全全的把计算能力放在业务计算上面，线程越多就会造成CPU利用率(用在业务计算的时间/总的时间)下降。

但是在WEB场景下，业务并不是CPU密集型任务，而是IO密集型的任务，一个线程是不合适，如果一个线程在等待数据时，把CPU的计算能力交给其他线程，这样也能充分的利用CPU资源。但是线程数量也要有个限度，一般线程数有一个公式：

最佳启动线程数 = [任务执行时间 / (任务执行时间 - IO等待时间)] * CPU内核数

超过这个数量，CPU要进行多余的线程切换从而浪费计算能力，低于这个数量，CPU要进行IO等待从而造成计算能力不饱和。总之就是要尽可能的榨取CPU的计算能力。

如果你的CPU处于饱和状态，并且没有多余的线程切换浪费，那么此时就是你服务的完美状态，如果再加大并发量，势必会造成性能上的下降。

线程多少对最高并发没有直接影响，任务计算时间才是影响最高并发数的根本原因。

当任务的执行时间减小，那么服务器每秒处理的请求就会增加，也就是说支持的并发变大。比如你在服务端只是简单的return ok;,稍微正常一点服务器上的Tomcat都能达到5000甚至10000的并发。只不过在大多数的web应用中，任务执行时间并不会太短，而且还涉及到数据库操作，所以大部分情况下Tomcat的最高并发就只有几百。

另外对于相同的任务执行时间，在不同的IO模型和线程模型中最高并发也表现的不一样。

在BIO模型中，线程数