背景
最近生产环境一个基于 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 类中存储的路径