Jvisualvm监控Tomcat以及相关参数优化

Tomcat阻塞模式

阻塞模式（BIO） 客户端和服务器创建一个连接，它就会创建一个线程来处理这个连接，以为这客户端创建了几个连接，服务端就需要创建几个线程来处理你，导致线程会产生很多，有很多线程也处于休眠状态
非阻塞模式（NIO）

阻塞模式： Acceptor建立一个连接，并接收客户端发过来的请求，当Acceptor接收这个连接带给Worker来处理 ，如果Worker没处理完，Acceptor也只能等待，直到任务完成。
非阻塞模式：中间加了个Poller，多了个容器，Acceptor建立一个连接，并接收客户端发过来的请求之后，并没有给Worker，而是放在Poller容器里，给了之后Acceptor不会等待，继续完成其他任务，如果Worker太忙了会开启多个线程去处理，有可能1个Acceptor对应多个Worker

Tomcat Server Status

在conf/tomcat-users.xml里配置账号，方可访问

maxThreads 修改最大连接数

maxThreads：tomcat接收客户端请求的最大线程数，也就是同时处理任务的个数，它的默认大小为200，一般来说，在高并发的I/O密集型应用中，这个值设置为1000左右比较合理（前提是机器配置高）

 <Connector port="8080" protocol="HTTP/1.1"connectionTimeout="20000"redirectPort="8443" maxThreads="20" />

tomcat最高线程数设置了20，jmeter压力配置的线程数200，如下图，20个线程几乎都是绿色运行中状态，说明线程很忙，需要增加tomcat最高线程数，如果线程数配置过高，上下切换也是很消耗资源的，所以需要合理配置tomcat最高线程数。

maxConnections

这个参数是指同一时间，tomcat能够接受的最大连接数，对于java新的NIO模式，maxConnections默认值是10000，所以这个参数我们一般保持不变。
例如：jmeter开启2000线程压服务器，服务器端开启200哥线程处理客户端的请求，假设开启的连接数是2000，maxconnections=200，代表另外1800直接拒绝，都不需要等待，一般设置会比较大，有可能响应时间比较慢，但不会被拒绝。

acceptCount

当线程数量达到上面设置的值，所能接受的最大排队数量，超过这个值，请求就会被拒绝，一般和maxThreads设置成一样大。
server.xml

 <Connector port="8080" protocol="HTTP/1.1"connectionTimeout="20000"redirectPort="8443" maxThreads="20" acceptCount="30" />

当acceptCount=30，意思是超过30个排队的线程，就直接拒掉
maxThreads设置20，jmeter线程200，如下图

怎么判断最大线程池够不够用，maxThreads
场景一、jmeter压测线程设置1，maxThreads设置20
线程监控结果：

jvisualvm的thread监控图是每秒刷新一次，其中橙色代表TIMED_WAITING状态，没活儿干，绿色代表RUNNABLE状态，在干活
通过这个测试结果，你可以看到，在只有一个压力线程的情况下，这10个Worker是轮流提供响应的，典型的线程足够用的状态。
场景二、当压力线程数通过递增，慢慢超过服务端线程数时。


在这个场景中，特意把压力工具中的线程数设置得高于Tomcat线程数，并且通过递增的方式加压。
一开始线程数时足够用的，还有挺多的时间处于空闲状态，但随着压力的增加，Tomcat的线程越来越忙，直到不够用，于是Tomcat就自己调增了线程数，知道maxThreads的值，然后线程的空闲状态越来越小，到最后几乎没有空闲状态。
可以看到响应时间随着线程数的不够用而不断的增加。
这是典型的线程配置不够的状态。

常见瓶颈：

压力不断增大，服务器资源利用率一直保持很低（压力上不去），响应时间变长，吞吐量趋于稳定，并且有下降趋势。
排查：首先排查中间件（tomcat）线程使用情况