开个主题讨论下线程池参数自适应调整的可能性

在容器化这么流行的情况下，没必要对线程池进行自适应整定吧，如果负载上涨，降低线程池大小，一方面是不好测算具体值，一方面也可能对业务造成影响呀
还不如依靠容器平台的自动伸缩，负载或者请求量变化自动创建合适的容器数量

1 楼+1
动态扩缩线程池的使用场景是什么呢？……

@chendy 一般人应该用不上吧，始终不都是美团这样的公司

任何 pool 都可以自动调整啊，无非是从设定 pool 固定大小变成了 pool 的「最多空闲」「最长空闲时间」「最小」和「最大」而已……

楼上说得对，要看具体有没有实践意义…

不过虽然如此。但是学习楼主的代码我觉得还是有获益的。另外就是令我接触到大公司的编程思想。谢谢楼主

@smilekung 必要性因人而异吧，毕竟还是有很多公司系统没有这种快速扩缩的能力而且这也是两个不同维度，线程池更多偏重单机处理能力。这个问题也是使用 DynamicTp 框架的用户提出的，我觉得还是有一定探讨性的，比如系统负载不高的情况下，线程池负载比较高，是不是可以考虑调大下线程池参数；反之，系统负载高的情况下，一般也是由于线程过多造成，就可以考虑调小下线程池参数。但是就像你说的，很难把控具体值。

@rrfeng 意义我觉得还是有的，但是自动调整，具体数值不好把控，没有一个比较成熟的最简实践算法支持

@golangLover 谢谢你

挺有意思的。 如果判断准确的话，线程参数不需要用户调整，也可以获得 90 分以上的效果了。

一般情况下，大部分软件部署的时候，都需要人工针对目标服务器的配置，进行一些经验性的参数调整，才能更好发挥服务器性能，而普通用户其实很多时候是很难完全搞懂这些参数的。
如果大部分参数都能动态的自动调整，那对于普通用户，世界会美好很多。

楼主上一个帖子我忍住了没好意思说，这个帖子还是说下吧：

何不用 go?

我们一些服务用 go 替换 java 后，内存消耗普遍降低了 50+%、个别服务占用降低 70%，cpu 消耗降低了 30-70%不等

@lesismal #11
确定不是重构时候优化了一下代码吗。