问题
接上篇文章 K8S集群中高并发应用undertow线程数不足引起的重启，产生的原因则是使用的undertow的系统默认配置，undertow线程数不足引起的问题。
建议
undertow默认配置情况下，官方默认配置的是 CPU核数*8，比如8核CPU，实际工作线程数也就8*8=64，这个配置对于高并发场景来看，一台8核CPU的机器一般内存都会32G或以上，即使跑满64线程，占用的资源远远无法充分利用该机器的性能。
当然啦，官方也是建议工作线程数的配置，取决于你机器的负载情况，其实也就是跟你的具体业务有关，我们现在的业务场景，64线程跑满的情况，CPU利用率仅仅百分之十几、CPU内存远远没利用完，再有请求过来，undertow则直接阻塞队列中，无法正常处理，资源浪费严重，还导致了服务中断的情况。
因此，从实际情况来看，一定不要采用undertow的官方默认配置。像我们线上业务来看，每个API接口业务耗时大多数在10ms以内，少部分耗时30-50ms时间，单接口耗用资源不大。 修改undertow配置 worker-threads=256，单节点可以承载256的并发任务，剩下的就是根据实际业务情况动态扩展节点数量即可。
io-threads：IO线程数, 它主要执行非阻塞的任务，它们会负责多个连接，默认设置每个CPU核心一个线程，不可设置过大，否则启动项目会报错：打开文件数过多。
worker-threads：阻塞任务线程池，当执行类似servlet请求阻塞IO操作，undertow会从这个线程池中取得线程。它的值取决于系统线程执行任务的阻塞系数，默认值是 io-threads*8，这里我们手动指定相应的值。
server:
port: 1112
undertow:
io-threads: 8
worker-threads: 256
版权声明：除特殊说明，文章均为博主 久酷 原创文章，转载请注明来源