用户反馈请求生产网关springcloud gateway突然偶发性返回500异常，赶紧上线检查服务，发现有个别实例日志里开始零星出现 OutOfDirectMemoryError，频率还有逐渐升高的趋势，过不了一会服务基本不可用了，出现健康检测异常。完整报错信息是这样的：

io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16777216 byte(s) of direct memory (used: 1006632967, max: 1013645312) =1G
        at io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:667)
        at io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:622)
        at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:772)
        at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:748)
        at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:245)
        at io.netty.buffer.PoolArena.allocate(PoolArena.java:227)
        at io.netty.buffer.PoolArena.allocate(PoolArena.java:147)
        at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:342)


大致意思是16MB 的分配请求被拒，此时直接内存已经用掉了 1006632967 字节（约 960MB），上限是 1013645312 字节（约 967MB）。Netty 在 Epoll 事件循环里试图给 TCP 连接分配接收缓冲区的时候，发现直接内存已经见底了，直接抛了异常。

这个问题影响的是我们的主网关。网关一旦挂掉，所有经过它转发的请求全断，影响面不小。

但也只设了堆内存 1000m，对一般的服务这也没有什么问题，但对统一入口网关没有设置 -XX:MaxDirectMemorySize。这是个关键遗漏。JVM 在没显式设置这个参数的时候，会把 MaxDirectMemorySize 默认取 -Xmx 的值，也就是大约 1000MB。再扣掉 JVM 自身的一些开销，实际可用的直接内存大概 967MB，跟报错里的 max: 1013645312 完全对得上。

而我们K8s Deployment 里容器内存限制是 1500Mi，堆就吃了 1000MB，留给直接内存和其他 JVM 开销的空间本来就很紧张。

关于内存回收这一块直接内存Direct Memory是通过ByteBuffer.allocateDirect方法分配的，它与堆内存不同，直接内存不是由垃圾回收器GC管理的。直接内存的分配和释放是由操作系统的内存管理机制处理的，如果系统异常没有来得及回收，则直接内存将一直往上涨直到引起服务重启。

Spring Cloud Gateway 底层是 reactor-netty，所有的 HTTP 请求收发、连接管理都走的 Netty 的 PooledByteBufAllocator，也就是直接在堆外内存分配 ByteBuf。这是正常行为，网关天生就会大量使用直接内存。

但问题是，光 Netty 自身的 I/O 缓冲不至于把 967MB 吃光。真正的问题出在我们自己写的 Filter 里。

代码里面跟直接内存相关的定位到 GatewayContextFilter

这个 Filter 做的事情是缓存请求体——对 JSON 和 Form 类型的 POST 请求，把 Body 读出来存到 GatewayContext 里，方便后续的鉴权、签名校验、日志等 Filter 使用。

return DataBufferUtils.join(exchange.getRequest().getBody())
    .flatMap(dataBuffer -> {
        byte[] bytes = new byte[dataBuffer.readableByteCount()];
        dataBuffer.read(bytes);
        DataBufferUtils.release(dataBuffer);   // 这里释放了原始 buffer
        Flux<DataBuffer> cachedFlux = Flux.defer(() -> {
            DataBuffer buffer = exchange.getResponse().bufferFactory().wrap(bytes);
            DataBufferUtils.retain(buffer);    // 这里又 retain 了一个新 buffer
            return Mono.just(buffer);
        });
        // ... 用 cachedFlux 重建 request，继续走 filter chain
    });


 不管请求体多大，都往里读。来个 50MB 的文件上传，也照读不误，直接就在直接内存里分配 50MB 的 ByteBuf。

第二，retain() 增加了引用计数但缺乏可靠的释放保障。

 代码里确实 release了原始的dataBuffer，但后面 cachedFlux 里 retain() 出来的新 buffer，它的释放完全依赖下游 Filter 链正常消费。一旦下游出现异常、Hystrix 熔断超时，这个 buffer 就可能不会被释放。在高并发场景下，这些没释放的 buffer 会逐渐蚕食直接内存。

第三，readBody 的 flatMap 没有 onErrorResume 或 doFinally 兜底。

 如果 DataBufferUtils.join() 过程中连接断开或者下游报错，中间态的 buffer 直接就成了孤儿。

自定义的AccessLogFilter 也可能存在问题

Flux<? extends DataBuffer> fluxBody = (Flux<? extends DataBuffer>) body;
return super.writeWith(fluxBody.buffer().map(dataBuffer -> {
    DataBufferFactory dataBufferFactory = new DefaultDataBufferFactory();
    DataBuffer join = dataBufferFactory.join(dataBuffer);
    byte[] content = new byte[join.readableByteCount()];
    join.read(content);
    DataBufferUtils.release(join);
    responseBody.set(new String(content, StandardCharsets.UTF_8));
    return bufferFactory.wrap(content);
}));


这个 Filter 把响应体全部聚合到内存里做日志记录。bufferFactory.wrap(content) 用的是 response 的 bufferFactory，在 Netty 环境下这就是直接内存分配。而且 .buffer() 操作会把所有响应数据块攒到一起再处理，如果是大响应体直接就可能直接爆了。

平时流量低的时候，这些问题被掩盖了。一旦并发上来，或者碰上几个大请求同时进来，直接内存就被打爆了。

：显式设置 -XX:MaxDirectMemorySize=1000m，加上 -XX:+UseG1GC。堆和直接内存隔离开，谁也别挤占谁的空间。K8s 容器内存限制从 1500Mi 提到 2500Mi，给 JVM 留足呼吸空间。

：在 GatewayContextFilter 里加了 MAX_CACHE_BODY_SIZE = 1MB 的门槛，超过 1MB 的请求体直接跳过缓存，记一行 warn 日志。同时对 readBody() 的响应式链路补了 doFinally 保障资源释放。AccessLogFilter 那边也做了相应的限制。

这次问题的反应了我们对 Netty 直接内存这个概念缺乏足够认知。写 Java 的人习惯了只关心堆内存，GC 日志一看没问题就觉得万事大吉。但在 Netty 体系下，直接内存是一个独立的、不受 GC 管控的内存区域，它的分配和释放需要开发者自己操心。而Spring Cloud Gateway 把 Netty 包了一层又一层，用起来是方便了，但底层 ByteBuf 的生命周期管理并没有被完全屏蔽掉。

另外就是 Filter 这种链式架构，写的时候只想着正向流程怎么跑通，对异常路径下的资源回收考虑不够。

还有一个教训是配置管理方面的。-XX:MaxDirectMemorySize 这种关键参数应该显式设置，而不是依赖默认值。默认值在大多数场景下是够用的，但网关这种重度依赖直接内存的组件不行，必须自己兜住。

干货分享Gateway踩坑实录：Netty直接内存把网关吃垮了OutOfDirectMemoryError

用户反馈请求生产网关springcloud gateway突然偶发性返回500异常，赶紧上线检查服务，发现有个别实例日志里开始零星出现 OutOfDirectMemoryError，频率还有逐渐升高的趋势，过不了一会服务基本不可用了，出现健康检测异常。

后端

架构设计

运维

SpringCloudGateway在生产环境偶发500异常，根因是OutOfDirectMemoryError导致直接内存耗尽。未设置-XX:MaxDirectMemorySize参数，默认与堆内存一致，而自定义Filter缓存请求体无大小限制且释放不彻底，高并发下Netty直接内存被蚕食。解决方案包括显式设置直接内存参数、提升容器内存、限制缓存请求体大小并补充资源释放兜底逻辑。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

SpringCloudGateway在生产环境偶发500异常，根因是OutOfDirectMemoryError导致直接内存耗尽。未设置-XX:MaxDirectMemorySize参数，默认与堆内存一致，而自定义Filter缓存请求体无大小限制且释放不彻底，高并发下Netty直接内存被蚕食。解决方案包括显式设置直接内...

干货分享Gateway踩坑实录：Netty直接内存把网关吃垮了OutOfDirectMemoryError

干货分享Gateway踩坑实录：Netty直接内存把网关吃垮了OutOfDirectMemoryError

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐