Java应用中线程数量的合理性评估

        相信大多使用Java的同窗曾经都遇到过由于写多线程代码引发的一些不正常现象，因此在使用须要多线程的地方会很当心或者刻意避免使用多线程。可是另外一方面，它可以显著提升应用性能、改善应用结构、增长处理器执行效率。现在的主机动辄2四、32核，有性能要求的场景下多线程则成为必选方案。其实大多数多线程编程引发的血案无非是如下几点的问题：1）变量的读写无控制；2）资源竞争致使的死锁；3）依赖执行顺序。可以避免掉上面三个问题，接下来若是还要说多线程可以致使的问题，那就是性能问题了。

    虽然说多线程可以显著提升性能增长处理器的执行效率，但不合理的使用一样可以减慢响应速度，甚至拖垮操做系统。

这里举一个栗子，由一个线上报警提及：阳光明媚的一天，收到了一个报警，内容是这么说的

，很显然，报警阀值是2000。最初收到报警有点方：“应用有异常了！我要赶快到机器上处理下。”，关流量、查看线程数GC以及内存状况、dump文件、重启应用、开流量一鼓作气。静下来思考发现其实重点在于你设置的阀值是否合理？是否引发了性能问题？

        要评估这个数字并非一件很难的事情，先从一台主机可以支撑多少个线程数提及。先看JVM中可以分配多少个线程，JVM运行在系统层面，其自己在受系统约束的前提下，也有几个参数能够控制线程的数量：     

-Xms	最小heap区域所占大小
-Xmx	最大heap区域所占大小
-Xss	每一个线程栈的容量大小

了解虚拟机运行数据区的同窗应该知道，每一个线程运行时所存放的私有数据都在虚拟机栈和本地方法栈，因此当-Xms、-Xmx定义的数字越大，就意味线程私有数据可存放的空间越小，可建立的线程越小。-Xss定义了单个线程栈的容量，那么它越大，一样可建立的线程数量也就越小。

        Java自身的限制肯定了之后来肯定系统层面，Linux中一样有线程的概念，那么这将是一个影响因素。这个线程同时会受pid的约束，由于一组同源线程的pid是一致的（比如一个Java进程下N多个线程，top -p [pid] -H 可查看），进而可知pid也将是约束之一。通常状况下不会超过这两个限制，接下来要说的一个参数相信大多数同窗都遇到过：ulimit -u ，这个是用户级别的线程限制。总结下来就是这样的：

cat /proc/sys/kernel/threads-max	thread-max
cat /proc/sys/kernel/pid_max	pid_max
ulimit -u	max_user_process

前面的命令能够直接查出系统线程上的限制。从上面的两个分析中得知，系统层面有线程数量的直接限制，JVM层面由控制内存从而间接限制了内存数量。

        参考以上结论并分析栗子，2000与系统限制相差甚远；JVM给的内存非常足崩；意味着2000是这两个层面彻底容许的线程数量。可是做为一个默认报警阀值，它表明了绝大多数Java应用的线程阀值，因此“容许”并不意味着它必定是安全的，接下来分析业务线程。

        jstack [pid]可看到全部java线程，首先按照状态去分析线程，优先看死锁，再看状态占有率。死锁0个，可是“WAITING ”状态的线程居然占到了几乎五分之三，线程栈中均为ThreadPoolExecutor调用，哈，都是线程池中的线程，这些线程这样的状态是不是业务指望呢，从线程栈中并不能获得更多的信息，这点须要你们注意，线程池建立时必定要在threadFactory中指定线程名字，便于分析和排查问题。我这里的栗子因为没有指定，因此只能抓瞎，计算了同组下线程数量最多的，发现是256*3个，剩下的有128*2等，128*2为druid-conn组，那么256*3从何而来，翻了翻代码找了一个逻辑，一共三个线程池定义：newFixedThreadPool，数量为CPUprocessors*2，bingo~ 这就对上了，这256*3均为该逻辑生产而来，且因为该线程池定义为固定大小，即建立一个任务就生产一个线程直至到定义的最大限制，无释放线程功能。因此线程总数一直处于线程池的峰值，频繁出现报警。

        因为线程池比较复杂，因此在定义池子的规则时比较麻烦，因此JDK提供了一系列工厂类来生成经常使用的线程池：

• newSingleThreadExecutor：建立一个单线程的线程池。这个线程池只有一个线程在工做，也就是至关于单线程串行执行全部任务。若是这个惟一的线程由于异常结束，那么会有一个新的线程来替代它。此线程池保证全部任务的执行顺序按照任务的提交顺序执行。
• newFixedThreadPool：建立固定大小的线程池。每次提交一个任务就建立一个线程，直到线程达到线程池的最大大小。线程池的大小一旦达到最大值就会保持不变，若是某个线程由于执行异常而结束，那么线程池会补充一个新线程。
• newCachedThreadPool：建立一个可缓存的线程池。若是线程池的大小超过了处理任务所须要的线程，那么就会回收部分空闲（60秒不执行任务）的线程，当任务数增长时，此线程池又能够智能的添加新线程来处理任务。此线程池不会对线程池大小作限制，线程池大小彻底依赖于操做系统（或者说JVM）可以建立的最大线程大小。
• newScheduledThreadPool：建立一个大小无限的线程池。此线程池支持定时以及周期性执行任务的需求。
• newSingleThreadScheduledExecutor：建立一个单线程的线程池。此线程池支持定时以及周期性执行任务的需求。

线程池的出现可以解决大量线程建立以及切换消耗系统资源的问题，可是定义的策略也关系到系统资源的利用率。虽然这个栗子并无直接影响到系统资源，可是在资源可用的状况下维护这么大一个线程池也未必会提升利用率。从业务上来看使用该线程池的场景天天只有个位数频度，咱们不须要使用newFixedThreadPool使全部线程等待，进而替换为可收缩的线程池定义：

便可解决线程过多的问题。知道了缘由以及解法，2000即变成线程数峰值，而不是常态了。

Java的线程池实现众多，咱们这里只讨论了线程池的建立，ThreadPoolExecutor，在线程池的架构版图中处于以下位置。

这个栗子中，咱们分析了系统层面的限制，讨论了JVM层面内存配置对线程数量的影响，但具体线程数量仍是要从业务自己出发，选择合适的线程池，可让咱们充分利用线程池避免过早触碰天花板。系统和JVM只能给咱们定义数量天花板，当业务所需数量触碰到天花板时，意味着你早早就该升级机器啦！