系统OOM异常与中间件调整最大线程数

项目问题：
表象：系统在正常运行一段时间后，忽然不处理请求
监控报警：服务器线程数已达到400
查看服务器状态：
1.服务器并没有挂
2.无法进行正常访问
3.top -H -p 进程号 发现进程下的线程数已经达到400+

4.查看dump 文件和日志，大量线程 呈现粘滞，独占现象
集中在某产品的购买流程中
5.初步怀疑是不是 某些线程处理时间过程或者未释放
对堆栈进行转储分析，未发现异常
6.紧急处理，对服务进行重启
直接杀掉了进程，重启后线程恢复正常

大约20天后，问题再次爆出
线程数达到400

400这个词引起了我的注意，并且询问业务运营人员，
发现出现问题的日期，都是在某产品发售的当天，大量用户进行产品购买。

初步怀疑，是访问人数超过了中间件或者数据库的线程最大数

1.首先在开发环境对此功能进行压测（压测工具，大家可以去我另一篇去看，WAS轻便简单）
2.果然，在设置400并发量时，存在大量请求400错误，分散在各个请求当中，并且后台出现大量等待请求，服务器无法再访问
3.扩大数据库链接数，（无用，事后想想也是，用的时oracle数据库，人家默认1000）
4.查看中间件，果然再设置线程池最大400之后，服务依旧坚挺

tomcat 最大线程数和线程池使用调整
1.找到config 目录 ，找到server.xml 文件
下图为没有配置线程池和最大连接数

需要将上图的线程池放开，并调用即可，maxThreads为最大连接数

注意：
1.更改配置后，确认有没有改对位置，我刚开始测试时，用的是eclipse 启动项目，忘记了eclipse 会创建一个缓存路径，结果导致改的不生效，最后我直接去了缓存的目录下更改server.xml
2.下面的参数解释是我Copy 而来，做个记录

在tomcat配置文件server.xml中的配置中，和连接数相关的参数有：

minProcessors：最小空闲连接线程数，用于提高系统处理性能，默认值为10

maxProcessors：最大连接线程数，即：并发处理的最大请求数，默认值为75

acceptCount：允许的最大连接数，应大于等于maxProcessors，默认值为100

enableLookups：是否反查域名，取值为：true或false。为了提高处理能力，应设置为false

connectionTimeout：网络连接超时，单位：毫秒。设置为0表示永不超时，这样设置有隐患的。通常可设置为30000毫秒。

其中和最大连接数相关的参数为maxProcessors和acceptCount。如果要加大并发连接数，应同时加大这两个参数。

一顿操作猛如虎，结果发现生产上用的weblogic的中间件，版本为10.3.6，查询了相关资料发现，webogic10已经做了优化，线程池为自优化的线程池。

看来不是线程的问题，经排查，
weblogic分配的堆内存才512M 大小，使用jstat 后发现，使用的堆无限接近

将weblogic 的堆内存调整成2G后，经过了一个月的运行，再次查看，发现使用的堆内存在发生GC的大小在600M左右，并且线程数也未阻塞增加

总结

1. 线程的阻塞或者说程序的瓶颈，有时是多因素之间的相互影响
2. 堆栈大小，最大线程数，以及程序自身的处理时间，都可以能造成阻塞甚至系统挂起
   像因为堆栈大小而出现问题的还有：拉取的报表过大，导致堆栈不够用，反应出来的问题就是报表一直的拉取，始终拉取不了的情况等

有兴趣的话区看下 虚拟机的一些知识 也可以看下我自己整理的

深入学习Java虚拟机笔记

JVM 抛出此异常的 理论原因

在Java 虚拟机规范中，对这个区域规定了两种异常情况：
如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；
如果虚拟机栈可以动态扩展（当前大部分的Java虚拟机都可以动态扩展，只不过Java虚拟机规范中也允许固定长度的虚拟机栈），如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError
如果Java堆中没有内存完成实例分配，并且无法扩展时 就抛出了此OOM --------这就是本次问题的所在原因了