问题背景
项目整体上是微服务架构,微服务之前通过http的restfull请求交互。问题出现在接收其他微服务http响应的时候。单个微服务的启动参数-Xmx512m,即最大内存为512M。
报错信息
首先获取日志信息:
java.lang.OutOfMemoryError: Java heap space
at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57) ~[?:1.8.0_212]
at java.nio.ByteBuffer.allocate(ByteBuffer.java:335) ~[?:1.8.0_212]
at org.eclipse.jetty.util.BufferUtil.allocate(BufferUtil.java:116) ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.ByteBufferPool.newByteBuffer(ByteBufferPool.java:61) ~[jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.MappedByteBufferPool.acquire(MappedByteBufferPool.java:65) ~[jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.http.GZIPContentDecoder.acquire(GZIPContentDecoder.java:408) ~[jetty-http-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.http.GZIPContentDecoder.decodedChunk(GZIPContentDecoder.java:108) ~[jetty-http-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.http.GZIPContentDecoder.decodeChunks(GZIPContentDecoder.java:189) ~[jetty-http-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.http.GZIPContentDecoder.decode(GZIPContentDecoder.java:71) ~[jetty-http-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.client.HttpReceiver.responseContent(HttpReceiver.java:347) ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.content(HttpReceiverOverHTTP.java:283) ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.http.HttpParser.parseContent(HttpParser.java:1787) ~[jetty-http-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:1517) ~[jetty-http-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.parse(HttpReceiverOverHTTP.java:172) ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.process(HttpReceiverOverHTTP.java:135) ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.client.http.HttpReceiverOverHTTP.receive(HttpReceiverOverHTTP.java:73) ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.client.http.HttpChannelOverHTTP.receive(HttpChannelOverHTTP.java:133) ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.client.http.HttpConnectionOverHTTP.onFillable(HttpConnectionOverHTTP.java:155) ~[jetty-client-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) ~[jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) ~[jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:411) ~[jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:305) ~[jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) ~[jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) ~[jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) ~[jetty-io-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:765) ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:683) ~[jetty-util-9.4.14.v20181114.jar:9.4.14.v20181114]
通过错误堆栈可以看到,发生内存溢出时,正在解析http响应的body体。
通常 OutOfMemoryError 堆栈,并不能确定问题的根因。
如果系统存在内存泄漏,并且内存接近上限,此时,当正常业务流程需要申请一部分内存时,如果总量超过了最大内存,会抛出内存溢出异常。通过此时的堆栈,并不能找到问题的根因。
分析 .hprof 文件内容
接下来通过MAT查看hprof文件
450m以上的内存是一个MappedByteBufferPool对象。此处应该就是问题的根因。也正是问题发生时的log调用堆栈中的对象。
先大概查看一下源码。MappedByteBufferPool.java是一个内存缓冲池,提供了申请内存和释放内存的方法。 MappedByteBufferPool内存过高应该就是只申请而没有释放。 从源码上看释放内存应该是调用者的职责。
所以接下来通过调用栈,调用者是GZIPContentDecoder.java。从名字上看应该是在解压gzip的报文。
响应报文过大导致溢出?
通过之前的业务日志和业务代码上推断此处报文大小最多也就是几M的数量级,不会出现400多M的情况。
继续通过MAT查看内存的详细信息
内存缓存池以map形式存在,key是int,并且相邻两个key对应的内容相差2048字节内存。
通过上述分析,推断该问题可能是jetty框架的问题。
因为业务代码应该不会接触到 MappedByteBufferPool对象,并且业务的报文最大值大约是几M,单纯的业务报文不会导致内存溢出。
如果是开源框架问题,有可能已经有了解决方法,于是google一下。
google 关键字 GZIPContentDecoder + OutOfMemoryError 发现第一个在官方jetty项目下有个issue描述与此问题类似。
查看issue内容后发现,正是此问题,并且最新版本已经修复了该问题。
https://github.com/eclipse/jetty.project/issues/3373
https://github.com/eclipse/jetty.project/commit/057575f1cb8fd2c0c35e8eeeb26b726c1d4cea99
总结
org.eclipse.jetty.io.MappedByteBufferPool
org.eclipse.jetty.client.HttpClient
org.eclipse.jetty.http.GZIPContentDecoder
MappedByteBufferPool:提供缓存池,当前版本存在缺陷,缓存大小无上限
HttpClient:创建MappedByteBufferPool和GZIPContentDecoder,用于http通信消息的处理
GZIPContentDecoder: 当消息内容是经过压缩的,使用此类进行解压,解压过程也会使用到HttpClient创建的MappedByteBufferPool
GZIPContentDecoder的缺陷:无法确定解压的后内容的大小,先申请一块缓存,解压后确认大小是否够用,不够的话增加大小重新申请一块缓存,重新解压,这个过程会导致一个压缩报文反复申请缓存,逐渐增加大小,直到申请到合适大小的缓存才能成功,这过程重申请的缓存最终都被放入MappedByteBufferPool缓存池,产生的缓存大小为:2048 + 20482 +20483 + … … +2048*n,一个解压后大小为640k的报文,最终产生100M的缓存。
Jetty最新版本 9.4.17,MappedByteBufferPool进行了优化,增加了最大缓存大小的设置,超出会清理,但是默认构造还是不设置上限,并且HttpClient并没有优化后的构造方法,还是存在内存泄漏可能。
GZIPContentDecoder已修复了缺陷,不会反复重新解压,而是分段解压,最后合并结果。
参考:
jetty 源码
https://github.com/eclipse/jetty.projectMat工具
https://www.eclipse.org/mat/
原文链接
https://www.bestlang.cn/article/26