使用GZIPInputStream出现内存泄漏导致Java heap space OOM如何解决

核心问题排查 #

• 空catch块吞掉所有异常：解压过程中出现的格式错误、IO错误全部被忽略，既无法感知异常发生，高频异常场景还会额外占用内存。同时原代码在catch分支没有返回值，实际编译无法通过，属于明显的代码缺陷。
• 无解压大小限制：如果遇到高压缩比的GZIP炸弹，或者业务本身的大压缩包，ByteArrayOutputStream会持续扩容直到占满堆内存，是OOM的直接诱因。
• 多余的流包装：手动读取已经使用了4KB缓冲区，额外套BufferedInputStream属于冗余操作，会增加不必要的内存占用和GC压力。

优化后代码 #

// 按业务实际允许的最大解压大小调整，示例为100MB
private static final int MAX_DECOMPRESS_BYTES = 100 * 1024 * 1024;

public byte[] uncompress(byte[] msg) {
    if (msg == null || msg.length == 0) {
        return new byte[0];
    }
    byte[] buffer = new byte[4096];
    int readLen;
    int totalLen = 0;

    try (GZIPInputStream gzis = new GZIPInputStream(new ByteArrayInputStream(msg));
         ByteArrayOutputStream baos = new ByteArrayOutputStream()
    ) {
        while ((readLen = gzis.read(buffer)) >= 0) {
            totalLen += readLen;
            if (totalLen > MAX_DECOMPRESS_BYTES) {
                throw new IllegalArgumentException("解压后数据超过上限，最大允许：" + MAX_DECOMPRESS_BYTES + "字节");
            }
            baos.write(buffer, 0, readLen);
        }
        return baos.toByteArray();
    } catch (Exception e) {
        // 异常抛给上层处理或打印日志，禁止空吞
        throw new RuntimeException("GZIP解压失败", e);
    }
}

额外排查建议 #

• 排查上层业务逻辑是否长期持有解压后的字节数组，比如存入静态集合未清理，这是渐进式内存泄漏的最常见原因。
• 使用jmap导出堆快照，通过MAT工具分析大对象的引用链，可快速定位无法被GC的对象持有者。
• 如果业务允许，优先用流式处理解压数据，不要将完整的解压结果全部加载到内存中，可大幅降低内存占用。

内容的提问来源于stack exchange，提问作者user1881185