[ Java ] 提高 tomcat 的工作线程最高数量 能不能提高吞吐量？

服务器配置跟得上的话可以提高一些

这应该有一个大概的函数关系吧，刚开始的时候提升线程数会增加吞吐量，到达极点以后再增加线程数会导致上下文切换带来的开销过大，反而降低吞吐量。所以如果能做一个实验的话，也许可以拟合出来这个关系？

需要基准测试

先找性能瓶颈啊，IO 密集还是 CPU 密集型的。CPU 密集的再怎么加线程也没用

你就是改到 10000 也行，能用到 200 的业务不是单服务器能玩的，不要浪费钱在单服务器上了

如果是 CPU 密集型，加了没用，如果是 IO 密集型，增加线程后数据库堵的更慌，所以也没用，要找点问题的点然后去解决。

木桶原理，找到系统瓶颈

@DovaKeen #2 确实是应该有一个函数关系 只不过我想弄清楚每一步的原理，好能更准确的找出那个最优值

@AngryPanda #3 不太懂 我一直在中小公司呆着 我上网查查

@gabon
@qilishasha
@liuxey
#4，#5，#6 是 IO 密集型 现在基础知识缺失较多 不太好找瓶颈在哪里 公司也没有大牛支持 很烦

压测一下

@Kraken 假如你什么都不清楚，那么你应该先用对应的工具进行 profiling，而不是瞎调参数。我记得 Oracle JDK 里面是有可以远程 profiling 的工具，你找找吧。或者自己分流程步骤打日志，定位热点，这样才好改

如果瓶颈是有更多的线程阻塞在等待数据库 IO，那么增加线程是有用的，直到上下文切换的代价大于此等待 IO 的代价

但是一般从经验上来看，单实例 200 线程足矣

这就是 java 头疼之处，tomcat 的优化，很折腾人，弃坑吧，学 golang

@jicg 哈哈哈 弃坑还行

@micean 为啥啊？ 如果有更多的线程阻塞在等数据库 IO 那加线程不是更多线程等待数据库了吗？

@Kraken 这个函数我觉得有很多因机器和场景而异的变量，大概是可以测出来一个特定场景的值，但是不能得到一个普适的函数的吧…

@DovaKeen #15 嗯 有道理 果然还是应该先压测什么的 掌握系统目前的各项性能指标

@jicg 你觉得用了 go 就不需要了解优化了?

@lihongjie0209 #17 哈哈哈 不可能的 无论什么语言都是需要优化的 就算是前端 也需要针对客户端优化 毕竟资源是有限的 技术才是硬道理啊！

能

@Kraken
我说的是假设外部条件有余的情况，只就这一个 tomcat 来说。
比方说，高铁多增加几个检票口，排队的旅客肯定能更快地过检，也就增加了吞吐量。

调一下 JVM 初始化堆的大小啊。。。立竿见影

@micean #20 没太明白 如果不换 cpu 那 cpu 的核心数和线程数是固定的啊 那假如我现在线程池的数量已经大于核心线程数量了 那再提高线程池的数量不应该是增加了同时调度线程的数量 相应的 每个线程执行的时间也变长了吗？ 因为有很多时间分配给其他线程了

@Gempty #21 早就已经调过啦 现在 3 分钟一次 full gc 我觉得还行

@Kraken 优化下线程~~~maxThreads、SpareThreads、acceptCount

@Gempty #23 优化了 maxThreads 从默认的 200 提到了 1000 但是之后没有什么爆款活动了，服务器压力一直不大，想通过理论知识想清楚这样到底能不能提升性能。因为 cpu 是 8 核 16 线程，那理论上无论在哪个瞬间，同时执行的线程数量都只有 16 个才对吧。提高线程数量，只是同时调度的线程数量变多了，那相应的每个线程的处理时间也变得更长，这样还会增加 cpu 切换线程的压力。我个人觉得逻辑应该是这样的。

还有一点就是不知道 fd 用不用调高上限，现在几乎一半的人回答用！另一半人回答不用！还有人说默认的 1024fd 效率是最好的，如果调高 fd 处理效率会降低。我也不知道哪些是对的。

果然还是应该自己掌握压测软件，多调多压……

@Kraken 上下文切换带来的损失远小于一次数据库操作

@Kraken
因为如果瓶颈在 io 的话，很多线程是在无谓的等待 io 返回，这时候增加线程数可以增加同时接客的数量。

@gz911122 +1
提高线程数能不能提高吞吐量，得看项目本身了。对 IO 密集型的来说通常是提高的，对 CPU 密集的来说用处就不大了，因为线程数可能根本没用完。
所以第一先观测线程使用的情况，简单的方式直接 `netstat -na | grep ESTAB | grep 8080 | wc -l`，如果线程数里现在配置的还远，就没必要动线程数。
第二观测吞吐量，要知道现在的每秒 /每分钟能处理多少请求。然后调整线程数再观察吞吐量数据。