java线程池优化_java开发之Tomcat线程池优化

前言：

上期我们说到了jvm的内存优化，这期我们来说说tomcat的线程池优化，此思路同样可用于c3p0等连接池

tomcat线程池优化

我们tomcat线程池的优化，其实就是最大限度的发挥tomcat的性能。即让服务器在保障性能的情况下并发最大

并发：所有线程，在同一秒一起访问同一个资源。

10个人，同一秒同时在访问网站，其中5个访问商品详情，另外5个访问商品列表。这个例子中什么是并发？

对于网站这个资源来说，并发就是10.

对于商品详情或者商品列表来说，并发就是5.

案例：tomcat最大并发数是多少？

同一秒访问tomcat的并发数有多少？

为什么要研究tomcat的并发数有多少？只有认清楚tomcat的并发数才能了解服务器的瓶颈。

测试用例1：直接访问tomcat首页，查看并发数。(不部署任何项目的情况下的并发数)

测试环境：

Tomcat：8.5.15、windows10、jdk11、idea、jmeter

用例名称：测试tomcat并发数(无项目部署)

测试步骤：

准一个空的(全新的)tomcat的。启动tomcat。访问tomcat的首页 预期结果：在浏览器正常访问tomcat的首页。启动jmeter，对tomcat首页进行压测，线程数100，周期1秒，执行1次。记录结果。重启tomcat，增加线程数到200，周期1秒，执行1次。记录结果。重启tomcat，继续增加100，周期1秒，执行1次。直至发现并发量瓶颈时，反复测试几次，记录结果。根据多次压测的结果得出tomcat首页并发量。为什么企业开发测试需要有测试用例呢？其中原因之一就是为了能复现测试流程，以便进行测试结果的复盘。

线程数100，周期1秒，执行1次。记录结果。

重启tomcat，增加线程数到200，周期1秒，执行1次。记录结果。

重启tomcat，增加线程数到300，周期1秒，执行1次。记录结果。

第一次执行

第二次执行

第三次执行

第四次执行

多次测试发现，瓶颈为300

此时线程池的配置：

maxThreads="40" minSpareThreads="4" maxIdleTime="30000"/>

name：线程池的名称

namePrefix：每一个线程的名称的前缀

maxThreads：最大线程数

minSpareThreads：最小空闲线程数

maxIdleTime：最大休眠时间

优化的配置

maxThreads="300" minSpareThreads="300" maxIdleTime="30000"/>

connectionTimeout="20000"

redirectPort="8443" executor="qifeng"/>

重启tomcat，增加线程数到300，周期1秒，执行1次。记录结果。

优化之后的结果

600个线程

1000个线程：557

2000个线程：521

3000个线程：547

疑问：是不是所有的页面和所有的接口都可以并发达到540左右呢？

疑问：为什么最大线程数是300，但是每秒的并发反而能超过300呢？是因为线程的使用时间短：1毫秒。一秒内同一个线程可以被复用多次。

测试用例2：准备一个项目放入tomcat中，访问我们的项目代码，查看并发数。(上面的测试是理论，此案例是实际情况)

重启tomcat、100、1、1

不重启tomcat，300、1、1

不重启tomcat，600,1,1

1000

2000

3000

4000

结论：

在本人垃圾配置的电脑上，有简单业务逻辑的代码并发量在200到300之间。同一时间能访问网站不报错的用户量大概是3000人左右。

一般情况下，并发量和实际用户量是10倍的差距。(前提是每一个用户只有一个请求)，比如一个用户请求一个页面发送三个请求，或者一个用户访问一个页面只发一个请求，前者能容纳的实际用户比后者要少很多。

结语

篇幅限制，先简单介绍这些，我们下期再细说，小编会定期分享自己学过的知识，各位看官可以点关注，一起分享学习的经验和方法，各位大佬对小编的看法有哪些补充或者不同的观点，欢迎在评论区留言斧正。