如何合理定义线程池大小

判断任务的特性

任务的性质：CPU密集型任务、IO密集型任务、混合型任务。
任务的优先级：高、中、低。
任务的执行时间：长、中、短。
任务的依赖性：是否依赖其他系统资源，如数据库连接等。
性质不同的任务可以交给不同规模的线程池执行。

现状

在这个项目里，是为代理，查表，以及domain层分别建立了一个线程池
coreporesize为20 最大为50 活跃时间为60s
采用LinkedBlockingQueue ，容量为20，防止队列过度扩展

并发编程网上的一个问题

高并发、任务执行时间短的业务怎样使用线程池？并发不高、任务执行时间长的业务怎样使用线程池？并发高、业务执行时间长的业务怎样使用线程池？
（1）高并发、任务执行时间短的业务，线程池线程数可以设置为CPU核数+1，减少线程上下文的切换
（2）并发不高、任务执行时间长的业务要区分开看：
　　a）假如是业务时间长集中在IO操作上，也就是IO密集型的任务，因为IO操作并不占用CPU，所以不要让所有的CPU闲下来，可以适当加大线程池中的线程数目，让CPU处理更多的业务
　　b）假如是业务时间长集中在计算操作上，也就是计算密集型任务，这个就没办法了，和（1）一样吧，线程池中的线程数设置得少一些，减少线程上下文的切换
（3）并发高、业务执行时间长，解决这种类型任务的关键不在于线程池而在于整体架构的设计，看看这些业务里面某些数据是否能做缓存是第一步，增加服务器是第二步，至于线程池的设置，设置参考（2）。最后，业务执行时间长的问题，也可能需要分析一下，看看能不能使用中间件对任务进行拆分和解耦。

总结

从这个答案上，可以看出这个项目其实并发并不高，并且任务执行时间偏长，线程数就是cpu核数*2
这个项目业务执行时间长的话，也拆分业务，现在已经拆分了业务，使用了并行。
做缓存的话，怎么做呢，没有了解过具体缓存的实践，可能需要了解下缓存的实践。
如果真的并发上去了，只有先加服务器了。单台服务器的线程数量是一定的。