gateway 堆外内存溢出

本文详细记录了在Spring Cloud Gateway项目中遇到的堆外内存溢出问题,通过设置Netty内存泄漏检测、检查代码中资源释放、排查第三方库如Redis客户端Lettuce的内存使用,最终确定为Gateway版本问题。升级Spring Cloud Gateway版本至2.2.8.RELEASE并更新相关依赖,成功解决了内存溢出问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

gateway 网关运行一段时间后会堆外内存溢出

gateway 网关工程依赖版本如下:

  <properties>
        <java.version>1.8</java.version>
        <spring-cloud.version>Hoxton.SR3</spring-cloud.version>
        <spring-cloud-alibaba.version>2.2.3.RELEASE</spring-cloud-alibaba.version>
    </properties>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.3.6.RELEASE</version>
        <relativePath />
    </parent>

网关分配2G内存, 当进程运行到2.9G时候开始所有请求报错

reactor.netty.ReactorNetty$InternalNettyException: io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16777216 byte(s) of direct memory (used: 2046820359, max: 2058354688)
Caused by: io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16777216 byte(s) of direct memory (used: 2046820359, max: 2058354688)
	at io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:775)
	at io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:730)
	at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:645)
	at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:621)
	at io.netty.buffer.PoolArena.allocateNormal(PoolArena.java:204)
	at io.netty.buffer.PoolArena.tcacheAllocateSmall(PoolArena.java:174)
	at io.netty.buffer.PoolArena.allocate(PoolArena.java:136)
	at io.netty.buffer.PoolArena.allocate(PoolArena.java:128)
	at io.netty.buffer.PooledByteBufAllocator.newDirectBuffer(PooledByteBufAllocator.java:378)
	at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
	at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:178)
	at io.netty.channel.unix.PreferredDirectByteBufAllocator.ioBuffer(PreferredDirectByteBufAllocator.java:53)
	at io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:114)
	at io.netty.channel.epoll.EpollRecvByteAllocatorHandle.allocate(EpollRecvByteAllocatorHandle.java:75)
	at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:780)
	at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:748)

解决问题:

1、启动加入 -Dio.netty.leakDetectionLevel=advanced 来看详细报错的代码。
2、检查代码,确认业务逻辑上是否有未关闭的堆外内存。发现只有一处使用到并且已经关闭。

public abstract class BaseFilter {
	/**
	 * 返回消息
	 * 
	 * @param exchange
	 * @param values
	 * @return
	 */
	protected Mono<Void> responseR(ServerWebExchange exchange, R r) {
		ServerHttpResponse response = exchange.getResponse();
		response.setStatusCode(HttpStatus.OK);
		response.getHeaders().setContentType(MediaType.APPLICATION_JSON);
		DataBuffer dataBuffer = response.bufferFactory().allocateBuffer()
				.write(JSON.toJSONString(r).getBytes(StandardCharsets.UTF_8));;
		try {
			return response.writeWith(Mono.just(dataBuffer));
		} finally {
			DataBufferUtils.release(dataBuffer);
		}
	}

	/**
	 * 从Flux<DataBuffer>中获取字符串的方法
	 * @return 请求体
	 */
	protected String resolveBodyFromRequest(ServerHttpRequest serverHttpRequest) {
		// 获取请求体
		Flux<DataBuffer> body = serverHttpRequest.getBody();
		AtomicReference<String> bodyRef = new AtomicReference<>();
		body.subscribe(buffer -> {
			try {
			bodyRef.set(StandardCharsets.UTF_8.decode(buffer.asByteBuffer()).toString());
			} finally {
				DataBufferUtils.release(buffer);
			}
		});
		return bodyRef.get();
	}

}

3、怀疑是网关中redis使用的Lettuce泄露, 更换了redis连接池为Jedis还是一样不行。
4、打开Hoxton.SR3 发现依赖的gateway版本为2.2.2.RELEASE。网上有人说2.2.5以下的是有bug。直接更换Hoxton.SR11 的版本,依赖gateway为2.2.8.RELEASE。 打包上线。解决。

  <properties>
        <java.version>1.8</java.version>
        <spring-cloud.version>Hoxton.SR11</spring-cloud.version>
        <spring-cloud-alibaba.version>2.2.3.RELEASE</spring-cloud-alibaba.version>
    </properties>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.3.6.RELEASE</version>
        <relativePath />
    </parent>
### Spring Gateway Direct Buffer 错误解决方案 在处理Spring Gateway中的`directBuffer`错误时,通常会遇到内存泄漏或缓冲区溢出等问题。此类问题可能由多种因素引起,包括配置不当、资源未正确释放等。 #### 配置调整 为了缓解与`directBuffer`有关的问题,可以尝试通过修改Netty的参数来优化性能并减少错误的发生频率: 1. **增加最大直接内存量** 调整JVM启动参数以允许更大的直接内存分配: ```bash -Dio.netty.maxDirectMemory=536870912 ``` 2. **设置TCP选项** 修改应用程序属性文件中的网络相关设置,例如禁用Nagle算法和启用快速重传机制: ```yaml server: netty: allocator: max-order: 3 transport: epoll # 如果Linux环境下可用epoll则更优 spring: cloud: gateway: httpclient: options: connect-timeout-millis: 5000 socket-timeout-millis: 5000 so-linger: -1 tcp-no-delay: true keep-alive: false ``` 3. **监控和日志记录** 启用详细的日志级别以便更好地跟踪潜在问题所在位置: ```properties logging.level.reactor.ipc.net.tcp.channel.ContextHandler=DEBUG logging.level.io.netty.buffer.PooledByteBufAllocator=DEBUG ``` 4. **垃圾回收调优** 对于长时间运行的服务端应用来说,定期触发完整的GC周期有助于防止因长期存活对象占用过多堆外空间而导致OOM异常: ```java System.gc(); Runtime.getRuntime().gc(); // 不推荐频繁使用此方法 ``` 以上措施能够有效改善大多数情况下由于`directBuffer`管理不善所引发的一系列问题[^1]。 另外,在某些场景下如果仍然无法解决问题,则可能是依赖库版本兼容性方面的原因造成的;此时建议升级至最新稳定版框架及其组件,并确保所有第三方模块均已更新到相互匹配的状态[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值