spring微服务 undertow的容器引起网关CPU超高的解决办法

一个项目在做压测的时候碰到一个网关CPU超过100%的问题，即便是停止压测CPU仍然居高不降。

图中明显有一个进程 xnio-1 i/o 很高不降的 这个分析进程来自undertow容器的。分析发现这个进程但凡压测超过50%就会很快升高到100 而且长时间不降。

通过此图发现存在很多空循环 ，到目前始终无法知道是什么原因引起了空循环造成CPU根本不会下降 只能重启服务解决。

翻阅了无法资料都是在说版本问题 ，尝试升级版本已经存在此类问题。只能通过更换netty容器直接就解决了这个问题。

参考资料如下：

首先通过GTP分析：

“XNIO 是一个用于构建高性能非阻塞 I/O 的库。它提供了一种在 Java 中进行异步 I/O 操作的框架。XNIO 可以用于构建网络应用程序，支持高并发和低延迟的网络通信。

XNIO-1 I/O-1 进程的名称表明它与 XNIO 框架中的 I/O 操作有关。在异步 I/O 模型中，可能会创建多个线程或者使用事件循环等机制来处理并发的 I/O 操作。这样的进程通常是与网络通信相关的，用于处理输入和输出。

具体而言，XNIO-1 I/O-1 进程中的 XNIO-1 可能表示 XNIO 框架的一个实例或者一个线程池。I/O-1 可能表示这是与 I/O 操作相关的第一个线程或任务。

如果你在应用程序中使用了 XNIO，这个进程可能是你应用程序的一个工作线程，负责处理异步 I/O 事件。在网络应用程序中，这种异步处理方式通常能够提供更好的性能和可伸缩性。

如果你想要更详细的信息，你可以检查应用程序的代码和配置，以了解是什么导致了 XNIO-1 I/O-1 进程的创建。在进行代码审查的同时，你还可以使用性能分析工具，如 Java Mission Control、VisualVM 或 YourKit，来深入了解这个进程的性能特征和行为。”

问题：XNIO-1 I/O-1 XNIO-2 I/O-2 cpu占用超过100%不释放

“当 XNIO 进程的 CPU 占用超过 100% 且不释放时，可能是因为系统处于某种性能瓶颈状态或者出现了一些问题。

最要的信息是这个：XNIO I/O threads are taking high CPU (may be because its not closing CLOSE_WAIT TCP connections) -https://issues.redhat.com/browse/XNIO-335

结论是：Details:
1. We are using Spring boot + undertow (version details are mentioned below)
2. App server is behind NGnix load balancer. We are using keep alive connections from NGnix to app server
3. When we deploy the app server, everything is OK, CPU usage is low, app is able to close TCP connections.
4. After an hour or so, the app server process starts taking up 25% of the CPU. Upon some inspection, I see that app is not able to close the CLOSE_WAIT connections (which may be the root cause )
5. When we leave the app server up and running for few days, it takes up more than 50% of CPU and the number of CLOSE_WAIT connections grows.
6. We are consistently able to reproduce with following versions:

• spring-boot-starter-undertow: 2.1.1.RELEASE and 2.1.3.RELEASE
• xnio-nio: 3.6.5.Final and 3.7.0.Final

7. I have noticed one 502 (BAD GATEWAY) from the app server just around the time when it starts taking up high CPU and at that moment I see the CLOSE_WAIT connections (although this app server doesn't have much traffic). May be when XNIO I/O thread rejects the incoming request, it gets into this state?
8. Please see attached images.

Using following server options:

• builder.setServerOption(UndertowOptions.NO_REQUEST_TIMEOUT, 30 * 1000);
• builder.setServerOption(UndertowOptions.REQUEST_PARSE_TIMEOUT, 30 * 1000);
• builder.setServerOption(UndertowOptions.IDLE_TIMEOUT, 60 * 1000);
• server.connection-timeout=50000 (spring property)

是让我更换更好的版本与配置信息，但尝试过后 依旧没有解决问题。不知道问题是怎么触发到这个bug。