升级之后，gateway和应用都出现eden space增长越来越快，从而导致gc越来越快，最后cpu飙升。
最后发现是因为gateway中 没有排除undertow，应用中没有排除tomcat相关依赖
整合gateway
在 Spring Cloud 项目中，Spring Cloud Gateway 和 Undertow 不能直接一起使用的原因主要与底层架构的差异有关。以下是详细的解释：
1. 技术栈的冲突
Spring Cloud Gateway 是基于 Spring WebFlux 构建的反应式（Reactive）网关，默认依赖 Netty 作为嵌入式服务器。
Undertow 是 Servlet 容器（如 Tomcat、Jetty 的替代），适用于传统的阻塞式（Servlet）应用（如 Spring MVC）。
二者的技术栈在本质上是冲突的：
WebFlux（Netty）：非阻塞、反应式模型，需要 Netty 作为底层服务器。
Undertow（Servlet）：基于 Servlet API，属于阻塞式模型。
如果尝试将二者混合使用，会导致应用无法启动，因为 Spring Boot 无法同时配置两种不同的 Web 服务器。
tomcat和undertow
1. 性能与资源占用
Undertow 的 NIO 模型更适合现代高并发场景，例如微服务、API 网关等。
Tomcat 默认的阻塞模型在处理大量并发请求时可能成为瓶颈，需手动配置为 NIO 模式（如
server.tomcat.protocol=NIO）。
2. 模块化与灵活性
Undertow：
高度模块化，可按需加载组件（如 Servlet、WebSocket 等）。
支持嵌入式部署，适合微服务架构中的轻量化需求。
提供 低层级 API，可直接操作 HTTP 协议，灵活性更高。
Tomcat：
功能全面但较为臃肿（如默认加载 JSP 支持）。
配置复杂（如
server.xml），适合传统 Web 应用。
3. 响应式编程支持
Undertow 直接支持 非阻塞式处理，与 Spring WebFlux 或 Quarkus 等反应式框架配合更高效。
Tomcat 虽然支持 NIO，但其线程模型仍以阻塞式为主，与反应式编程的契合度较低。
4. 启动速度
Undertow 启动时间更短，适合需要快速启停的云原生场景。
Tomcat 启动较慢（需初始化更多组件）。