线程池参数设置

我自己电脑是 24核

如果设置的核心线程数>24 处理耗时都是差不多的

tomcat线程池默认核心线程数配置也是直接干到200的，tomcat线程池可以设置，那普通

线程池也是可以这么设置的，毕竟两者都是差不多的，只不过执行流程不太一样，普通线程池核心线程数满了，它是先入队列，队列满了再做一个非核心线程的扩充，知道达到最大线程数再触发拒绝策略。像tomcat的核心线程池，它最小是10，最大是200，它是当线程数超过10就会直接创建新的线程，达到最大线程数再入队，最后再触发拒绝策略。这两者的差别只有创建新线程树的差别。所以普通线程池和tomcat线程池就可以设置一个200的核心线程数了。

而我之前看八股的时候也是有了解到网上说核心线程数的设置要n+1 或者2n嘛，但当时我结合tomcat线程池的参数设置，就感觉怪怪的。然后有去疯狂谷歌搜索，像知道n+1和2n的说法来自于哪里，它其实是源于2006出版的java并发编程这本书，它里面就明确地提供了这个公式，就是线程池的线程树==cpu的核心数*cpu的利用率 *（1+cpu等待时间/cpu的计算时间）。然后我们假设CPU的利用率是100%，那么在CPU密集型场景下，，那么等待时间几乎为0，所以线程池的线程数为n，然后+1的话就是为了 说防止某线程假死了or暂停，增加一个冗余线程可以处理任务。如果是IO密集型的话，那他们就假设cpu等待时间/cpu的计算=1的。那么括弧里就等于2，那么结果自然就是2n。

然后一个就是为什么可以设置这么高

了解到因为长久以来一个一贯的说法就是

上下文切换回带来cpu的控制损耗。但其实这个说法是源自于1961年，有时代的局限性

2000左右的cpu上下文切换大概是5-10微妙，而当代cpu的上下文切换就只有1-3微妙。并且随着cpu超线程的发展，cpu核心数动不动就是64c 128c,除非是极端情况，比如高并发情况下，有几十万个线程正在切换，否则按照我们tomcat一般都是200个线程，甚至1000,2000的配置。这个损耗几乎是不计的。

像IO密集型的话，受限的其实是外部环境，比如数据库连接池的问题

所以如果是

还有就是个人感觉如果是这样的话，之前看过的一篇美团的关于动态线程池的技术博客，其实意义也不算大了，毕竟队列长和核心线程数并无直接关系，IO密集型的往大了调是没关事的，cpu密集型也是，毕竟怎么调大都没用，上下文损耗几乎忽略不计。

如果是生产环境的话，多个接口的话，可能会有线上其他任务抢占cpu调度的场景。那估计可能就会影响了。不过对于高并发服务器来说，其实在上面部署线程池其实是不合适的，IO密集型瓶计不在你，cpu密集型又影响其他。我个人感觉这种场景下MQ和调度任务是替代线程池的最好方案。

目前是根据一个经验值，核心线程数100，队列大小不限制

大概分析了每个线程要完成的工作，都会存在一些IO操作

根据机器2核4G的配置，所以给出一个经验值100

线程监控

beforeExecute()

重试纪元

afterExecute() 做重试逻辑，重试一定次数就报警