Java线程池中的线程数设置多少个合适，什么情况下会导致OOM

线程池中线程数的多少一直是让人很迷惑的一个点，把控不住到底设置多少个合适，查相关资料的话，网上这个话题实际有用的内容都很少。

其实可以分两种情况，第一种情况是业务需要严格把控线程使用率，这种其实多数遇不到，只有在极端严格的开发标准中才会用到，因为在这种情况下，线程池中的线程数往往是个位数，这也是为什么JAVA里面有一个单线程池(SingleThreadPool)的原因。大家日常在使用线程池的时候，往往对单线程池不太关注，多数用的是定长线程池，但其实单线程池往往是高标准开发的最优解。不过我们用多线程就是为了提高资源使用率以及任务的执行效率，因此这种情况和我们一般情况的需求有一些不成正比。

在高标准情况下，无非就是两个目的，计算处理或IO任务，大家可以参考如下的设置方式：

如果线程池是用来计算的，则程池的大小应为 N+1 ，N为处理器个数。
如果线程池是用来处理I/O的，则线程池大小为N*(1+W/C) ，W是I/O 资源获取时间，C是处理时间。

当然大多数还属于一般情况，这就有些多样了，因为它涉及到一个oom的问题，当然不是说高标准高要求情况下就不会爆发oom，相反，也会发生，只是发生时反应出的问题很直白，就是单纯的资源不够。可是一般情况下，我们会设置很多线程数，所以就要考虑是不是线程数设置多了？而设置少了又达不到高效率的目标。

很多人都知道oom这个报错，但很少有人真触发过它，甚至都不知道它的全称是什么？所以需要先给大家解释一下oom到底是什么东西？oom的报错全称是java.lang.OutOfMemoryError: unable to create new native thread。有不少新手可能以为oom是由于JAVA虚拟机自身的内存不够了，从内部就像气球一样爆掉了，其实并不是这个样子，它是指当一个Java进程或者说虚拟机所需要的实际内存，超过了它在计算机上所能占用的最大内存时，被对应的监控组件直接杀死了，爆的一个错误，因此如果Java虚拟机本身所占内存过大，就容易爆发oom，这里说的监控组件指的是Java的守护程序或者所使用服务自身的监控组件等各种已有