从一次netty 内存泄露问题来看netty对POST请求的解析

背景

最近生产环境一个基于 netty 的网关服务频繁 full gc

观察内存占用，并把时间维度拉的比较长，可以看到可用内存有明显的下降趋势

出现这种情况，按往常的经验，多半是内存泄露了

问题定位

找运维在生产环境 dump 了快照文件，一分析，果然不出所料,在一个 LinkedHashSet 里面， 放入 N 多的临时文件路径

可以看到，该 LinkedHashSet 是被类 DeleteOnExitHook 所引用。

DeleteOnExitHook

DeleteOnExitHook 是 jdk 提供的一个删除文件的钩子类，作用很简单， 在 jvm 退出时，通过该类里面的钩子删除里面所记录的所有文件

我们简单的看下源码

class DeleteOnExitHook {

    private static LinkedHashSet<String> files = new LinkedHashSet<>();

    static {

        // 注册钩子， runHooks 方法在 jvm 退出的时候执行

        sun.misc.SharedSecrets.getJavaLangAccess()

            .registerShutdownHook(2 /* Shutdown hook invocation order */,

                true /* register even if shutdown in progress */,

                new Runnable() {

                    public void run() {

                       runHooks();

                    }

                }

        );

    }

    private DeleteOnExitHook() {}

    // 添加文件全路径到该类里面的set里

    static synchronized void add(String file) {

        if(files == null) {

            // DeleteOnExitHook is running. Too late to add a file

            throw new IllegalStateException("Shutdown in progress");

        }

        files.add(file);

    }

    static void runHooks() {

       // 省略代码。。。 该方法用做删除 files 里面记录的所有文件

    }

}

我们基本猜测出，在应用不断的运行过程中，不断有程序调用 DeleteOnExitHook.add 方法，放入了大量临时文件路径，导致了内存泄露

其实关于 DeleteOnExitHook 类的设计，不少人认为这个类设计不合理，并且反馈给官方，但官方觉得是合理的，不打算改这个问题

有兴趣的可以看下 https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6664633

原因分析

既然已经定位到了出问题的地方，那么到底是什么情况下触发了这个 bug 了呢？

因为我们的网关是基于 netty 实现的，很快定位到了该问题是由 netty 引起的，但要说清楚这个问题并不容易

HttpPostRequestDecoder

如果我们要用 netty 处理一个普通的 post 请求，一种典型的写法是这样，使用 netty 提供的解码器解析 post 请求

// request 为 FullHttpRequest 对象

HttpPostRequestDecoder decoder = new HttpPostRequestDecoder(request);

try {

    for (InterfaceHttpData data : decoder.getBodyHttpDatas()) {

        // TODO 根据自己的需求处理 body 数据

    }

    return params;

} finally {

    decoder.destroy();

}

HttpPostRequestDecoder 其实是一个解码器的代理对象， 在构造方法里使用默认使用 DefaultHttpDataFactory 作为 HttpDataFactory

同时会判断请求是否是 Multipart 请求，如果是，使用 HttpPostMultipartRequestDecoder，否则使用 HttpPostStandardRequestDecoder

public HttpPostRequestDecoder(HttpRequest request) {

        this(new DefaultHttpDataFactory(DefaultHttpDataFactory.MINSIZE), request, HttpConstants.DEFAULT_CHARSET);

}

public HttpPostRequestDecoder(HttpDataFactory factory, HttpRequest request, Charset charset) {

        // 省略参数校验相关代码

        // Fill default values

        if (isMultipart(request)) {

            decoder = new HttpPostMultipartRequestDecoder(factory, request, charset);

        } else {

            decoder = new HttpPostStandardRequestDecoder(factory, request, charset);

        }

    }

DefaultHttpDataFactory

HttpDataFactory 作用很简单，就是创建 httpData 实例，httpData 有多种实现，后续我们会讲到

HttpDataFactory 有两个关键参数

• 参数 useDisk ，默认 false，如果设为 true，创建 httpData 优先使用磁盘存储
• 参数 checkSize，默认 true，使用混合存储，混合存储会通过校验数据大小，重新选择存储方式

HttpDataFactory 里方法虽然不少，其实都是相同逻辑的不同实现，我们选取一个来看下源码

@Override

public FileUpload createFileUpload(HttpRequest request, String name, String filename,

        String contentType, String contentTransferEncoding, Charset charset,

        long size) {

	// 如果设置了用磁盘，默认会用磁盘存储的 httpData， userDisk 默认是 false

    if (useDisk) {

        FileUpload fileUpload = new DiskFileUpload(name, filename, contentType,

                contentTransferEncoding, charset, size);

        fileUpload.setMaxSize(maxSize);

        checkHttpDataSize(fileUpload);

        List<HttpData> fileToDelete = getList(request);

        fileToDelete.add(fileUpload);

        return fileUpload;

    }

	// checkSize 默认 true

    if (checkSize) {

		// 创建 MixedFileUpload 对象

        FileUpload fileUpload = new MixedFileUpload(name, filename, contentType,

                contentTransferEncoding, charset, size, minSize);

        fileUpload.setMaxSize(maxSize);

        checkHttpDataSize(fileUpload);

        List<HttpData> fileToDelete = getList(request);

        fileToDelete.add(fileUpload);

        return fileUpload;

    }

    MemoryFileUpload fileUpload = new MemoryFileUpload(name, filename, contentType,

            contentTransferEncoding, charset, size);

    fileUpload.setMaxSize(maxSize);

    checkHttpDataSize(fileUpload);

    return fileUpload;

}

httpData

httpData 可以理解为 netty 对 body 里的数据做的一个抽象，并且抽象出了两个维度

• 从数据类型来看，可以分为普通属性和文件属性
• 从存储方式来看，可以分为磁盘存储，内存存储，混合存储

类型/存储方式	磁盘存储	内存存储	混合存储
普通属性	DiskAttribute	MemoryAttribute	MixedAttribute
文件属性	DiskFileUpload	MemoryFileUpload	MixedFileUpload

可以看到，根据数据属性不同和存储方式不同一共有六种方式

但需要注意的是， 磁盘存储和内存存储才是真正的存储方式，混合存储只是对前两者的代理

• MixedAttribute 会根据设置的数据大小限制，决定自己真正使用  DiskAttribute 还是 MemoryAttribute
• MixedFileUpload 会根据设置的数据大小限制，决定自己真正使用 DiskFileUpload  还是 MemoryFileUpload

我们来看下 MixedFileUpload 对象构造方法

public MixedFileUpload(String name, String filename, String contentType,

        String contentTransferEncoding, Charset charset, long size,

        long limitSize) {

    this.limitSize = limitSize;

	// 如果大于 16kb(默认），用磁盘存储，否则用内存

    if (size > this.limitSize) {

        fileUpload = new DiskFileUpload(name, filename, contentType,

                contentTransferEncoding, charset, size);

    } else {

        fileUpload = new MemoryFileUpload(name, filename, contentType,

                contentTransferEncoding, charset, size);

    }

    definedSize = size;

}

后续在往 MixedFileUpload 添加内容时，会判断内容如果大于 16kb，仍旧用磁盘存储

@Override

public void addContent(ByteBuf buffer, boolean last)

        throws IOException {

	// 如果现在是用内存存储

    if (fileUpload instanceof MemoryFileUpload) {

        checkSize(fileUpload.length() + buffer.readableBytes());

		// 判断内容如果大于16kb(默认），换成磁盘存储

        if (fileUpload.length() + buffer.readableBytes() > limitSize) {

            DiskFileUpload diskFileUpload = new DiskFileUpload(fileUpload

                    .getName(), fileUpload.getFilename(), fileUpload

                    .getContentType(), fileUpload

                    .getContentTransferEncoding(), fileUpload.getCharset(),

                    definedSize);

            diskFileUpload.setMaxSize(maxSize);

            ByteBuf data = fileUpload.getByteBuf();

            if (data != null && data.isReadable()) {

                diskFileUpload.addContent(data.retain(), false);

            }

            // release old upload

            fileUpload.release();

            fileUpload = diskFileUpload;

        }

    }

    fileUpload.addContent(buffer, last);

}

如果上面的解释还没有让你理解 httpData 的设计，我相信看完下面这张类图你一定会明白

httpData 磁盘存储的问题

我们通过上面的分析可以看到，使用磁盘存储的 httpData 实现一共有两个，分别是 DiskAttribute 和 DiskFileUpload

从上面的类图可以看到，这两个类都继承于抽象类 AbstractDiskHttpData，使用磁盘存储会创建临时文件，如果使用磁盘存储，在添加内容时会调用   tempFile 方法创建临时文件

private File tempFile() throws IOException {

    String newpostfix;

    String diskFilename = getDiskFilename();

    if (diskFilename != null) {

        newpostfix = '_' + diskFilename;

    } else {

        newpostfix = getPostfix();

    }

    File tmpFile;

    if (getBaseDirectory() == null) {

        // create a temporary file

        tmpFile = File.createTempFile(getPrefix(), newpostfix);

    } else {

        tmpFile = File.createTempFile(getPrefix(), newpostfix, new File(

                getBaseDirectory()));

    }

	// deleteOnExit 方法默认返回 ture,这个参数可配置，也就是这个参数导致了内存泄露

    if (deleteOnExit()) {

        tmpFile.deleteOnExit();

    }

    return tmpFile;

}

这里可以看到如果 deleteOnExit 方法默认返回 ture，就会执行 deleteOnExit 方法，就是这个方法导致了内存泄露

我们看下 deleteOnExit 源码，该方法会把文件路径添加到 DeleteOnExitHook 类中，等 java 虚拟机停止时删除文件

至于 DeleteOnExitHook 为什么会导致内存泄露，文章开始的时候已经解释，这里不再赘述

// 在java 虚拟机停止时删除文件

public void deleteOnExit() {

    SecurityManager security = System.getSecurityManager();

    if (security != null) {

        security.checkDelete(path);

    }

    if (isInvalid()) {

        return;

    }

	// 文件路径会一直保存到一个linkedHashSet里面

    DeleteOnExitHook.add(path);

}

到这里，我相信你也一定明白问题所在了

在请求内容大于 16kb（默认值，可设置）的时候，netty 会使用磁盘存储请求内容，同时在默认情况下，会调用 file 的   deleteOnExit 方法，导致文件路径不断的被保存到 DeleteOnExitHook ，不能被 jvm 回收，造成内存泄露

解决方案

DiskAttribute 中 deleteOnExit 方法 返回的是静态变量 DiskAttribute.deleteOnExitTemporaryFile 的值，默认 true

DiskFileUpload 中 deleteOnExit 方法 返回的是静态变量 DiskFileUpload.deleteOnExitTemporaryFile 的值，默认 true

只需把这两个静态变量设为 false 即可

static {

  DiskFileUpload.deleteOnExitTemporaryFile = false;

  DiskAttribute.deleteOnExitTemporaryFile = false;

}

至于临时文件的删除我们也不用担心，HttpPostRequestDecoder 最后调用了 destroy 方法，就能保证后续的临时文件删除和资源回收，因此，上述默认情况下没必要通过 deleteOnExit 方法在 jvm 关闭时再清理资源

HttpPostRequestDecoder 解析数据的时序图如下

官方修复

上面的解决方案其实只是避开问题，并没有真正的解决这个 bug

我看了下官方的 issues，该问题已经被多次反馈，最终在 4.1.53.Final 版本里修复，修复逻辑也很简单，重写 DeleteOnExitHook 类为 DeleteFileOnExitHook ，并提供 remove 方法

在 AbstractDiskHttpData 类的删除文件时，同时删除 DeleteFileOnExitHook 类中存储的路径

有兴趣的可以看下官方的 issuers 和 pr了解更多信息