Tomcat修改内存配置

488次阅读

共计 2015 个字符，预计需要花费 6 分钟才能阅读完成。

一、配置

Tomcat/conf/server.xml 修改配置

二、参数说明

maxIdleTime：最大空闲时间，超过这个空闲时间，且线程数大于 minSpareThreads 的，都会被回收，默认值 1 分钟（60000ms）；
minSpareThreads：最小空闲线程数，任何情况都会存活的线程数，即便超过了最大空闲时间，也不会被回收，默认值 4；
maxSpareThreads：最大空闲线程数，在最大空闲时间（maxIdleTime）内活跃过，此时空闲，当空闲时间大于 maxIdleTime 则被回收，小则继续存活，等待被调度，默认值 50；
maxThreads：最大线程数，大并发请求时，tomcat 能创建来处理请求的最大线程数，超过则放入请求队列中进行排队，默认值为 200；
acceptCount：当最大线程数（maxThreads）被使用完时，可以放入请求队列排队个数，超过这个数返回 connection refused（请求被拒绝），一般设置和 maxThreads 一样，不过这个具体需要根据自己的应用实际访问峰值和平均值来权衡，默认值为 100；
connectionTimeout：网络连接超时，假设设置为 0 表示永不超时，这样设置隐患巨大，通常可设置为 30000ms，默认 60000ms。
Windows Tomcat 允许每个进程 maxThreads（最大线程数）2000
Linux Tomcat 允许每个进程 maxThreads（最大线程数）1000

Tomcat 修改内存配置

图解线程池原理

Tomcat 修改内存配置

请看下面三种情况

情况 1：接受一个请求，此时 tomcat 起动的线程数没有到达 maxThreads，tomcat 会起动一个线程来处理此请求。

情况 2：接受一个请求，此时 tomcat 起动的线程数已经到达 maxThreads，tomcat 会把此请求放入等待队列，等待空闲线程。

情况 3：接受一个请求，此时 tomcat 起动的线程数已经到达 maxThreads，等待队列中的请求个数也达到了 acceptCount，此时 tomcat 会直接拒绝此次请求，返回 connection refused

maxThreads 如何配置

一般的服务器操作都包括量方面：1 计算（主要消耗 cpu），2 等待（io、数据库等）

第一种极端情况，如果我们的操作是纯粹的计算，那么系统响应时间的主要限制就是 cpu 的运算能力，此时 maxThreads 应该尽量设的小，降低同一时间内争抢 cpu 的线程个数，可以提高计算效率，提高系统的整体处理能力。

第二种极端情况，如果我们的操作纯粹是 IO 或者数据库，那么响应时间的主要限制就变为等待外部资源，此时 maxThreads 应该尽量设的大，这样才能提高同时处理请求的个数，从而提高系统整体的处理能力。此情况下因为 tomcat 同时处理的请求量会比较大，所以需要关注一下 tomcat 的虚拟机内存设置和 linux 的 open file 限制。

我在测试时遇到一个问题，maxThreads 我设置的比较大比如 3000，当服务的线程数大到一定程度时，一般是 2000 出头，单次请求的响应时间就会急剧的增加，

百思不得其解这是为什么，四处寻求答案无果，最后我总结的原因可能是 cpu 在线程切换时消耗的时间随着线程数量的增加越来越大，

cpu 把大多数时间都用来在这 2000 多个线程直接切换上了，当然 cpu 就没有时间来处理我们的程序了。

以前一直简单的认为多线程 = 高效率。。其实多线程本身并不能提高 cpu 效率，线程过多反而会降低 cpu 效率。

当 cpu 核心数 < 线程数时，cpu 就需要在多个线程直接来回切换，以保证每个线程都会获得 cpu 时间，即通常我们说的并发执行。

所以 maxThreads 的配置绝对不是越大越好。

现实应用中，我们的操作都会包含以上两种类型（计算、等待），所以 maxThreads 的配置并没有一个最优值，一定要根据具体情况来配置。

最好的做法是：在不断测试的基础上，不断调整、优化，才能得到最合理的配置。

acceptCount 的配置，我一般是设置的跟 maxThreads 一样大，这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

如果设的较小，可以保证接受的请求较快相应，但是超出的请求可能就直接被拒绝

如果设的较大，可能就会出现大量的请求超时的情况，因为我们系统的处理能力是一定的。

：