记一次 JNI 导致 Java fd 泄漏的排查过程原创
前几天接到反馈，线上某机器上的服务在进行后端调用的时候失败了。查看日志是端口分配失败。通过 netstat -nulp 看到大量端口占用，用户段端口49152 到 65535 全部被占满。于是通过 awk sort 和 uniq 统计出每个进程的端口占用情况，发现某些 Java 服务占用了 2w+ 端口，于是对该服务展开分析。
首先考虑的是应用有大量 Socket 对象没有关闭释放，于是将堆 dump 出来，使用 VisualVM 加载分析。由于泄漏的是 UDP 端口，于是考虑查找 Java 中 UDP socket 对应的对象 DatagramSocket 。可是一顿操作之后发现堆中并不存在该类对象，倒是找到了几个 DatagramSocketAdaptor 对象。查看了框架发现使用了 Netty 做 NIO，因此实际使用的是 NioDatagramChannel 和 DatagramSocketAdaptor 对象。经过对比，这些对象都是应用启动时创建 Netty channel 时创建的，数量完全正确，所以排除这方面的问题。
接着考虑 Netty 版本和 JVM 版本的问题。通过搜索发现 Netty 和 JVM 都出现过 fd 没有正确关闭的问题，于是进行升级。升级后发现问题依然存在，排除相关组件的问题。
在排除了几个可能之后，还是没有什么头绪，于是准备从 FD 本身入手。在 Java 中，所有的系统 FD 对应的都是一个 Java 中的 FileDescriptor 类，于是使用各种工具对该类的创建和删除进行了监控。结果通过排查发现，除了第一步中查到的 Netty Channel 持有的 fd 实例外，没有任何的有关网络 Socket 的 fd 实例。这下就很尴尬了，JVM 中的 fd 没有变化，按理说应该不会有 Socket 创建才对。仔细思考了一下，想到了最后一种可能，那就是 native 方法。
在 Java 中，为了支持调用其它语言所编写的方法，提供了 Java Native Interface 即 JNI 作为入口。当我们需要调用一个闭源的 C++ 编写的类库的时候，我们就可以使用 JNI 来进行调用。同时，由于 JNI 实际执行的是第三方类库中的代码，因此这部分代码进行的 fd 操作都不会被 JVM 管理，自然也就不会出现在 Dump 文件中。
既然猜到了可能的问题，接下来就需要排查了。可是由于一些原因，该服务中存在很多的 JNI 类库都会进行网络调用，无法最终确定。于是想了这么一个办法来进行排查：
1.在机器上起一个程序不断的对 lsof -a -n -P -i udp -p pid 进行采样对比，遇到两次采样期间有新增的 fd 就打印出来
2.同时使用 tcpdump -i any udp -w fd_leak.pcap 进行全量抓包，记录机器上所有的 UDP 网络流量，来对比分析流量发出的进程
经过排查，终于抓到了对应的包，找到了对端的 IP 端口，定位到了对应的组件。于是对这个组件编写复现代码进行测试，最终将代码简化为：
package com.maoxian.test;
import com.maoxian.xxx.NativeAPI;
/**
* 测试类
*/
public class Test {
public static void main(String[] args) {
Thread.sleep(10000);
int i = 0;
while (i < 10) {
i++;
System.out.println("Start loop " + j + " ...");
new Thread() {
@Override
public void run() {
try {
System.out.println("Thread " +
Thread.currentThread().getId() +
" is running...");
NativeAPI.doSomething();
} finally {
System.out.println("Thread " +
Thread.currentThread().getId() +
" finished.");
}
}
}.start();
System.out.println("Finish loop " + j + ".");
}
Thread.sleep(60000);
}
}
这段代码的作用非常简单，就是起 10 个线程去调用这个组件，每个线程调用一次就退出。Sleep 的作用是给 lsof 列出 fd 预留时间。在执行这段代码后可以明显的看到 fd 在 Native 方法调用时分配，但是在线程退出后没有释放。咨询了相关同事后得知，由于在 C++ 中，一般不会使用 Java 中的这种线程池模型，而是使用固定线程模型。当一个线程退出的时候通常意味着整个程序的退出。所以这个组件在制作的时候只考虑了线程安全的问题对每个线程独立分配了资源，但是没有考虑线程终止时候的资源释放。
在定位到 fd 泄漏与线程创建相关后，对相应的业务框架代码进行了分析。发现框架中创建线程池使用的是：
this.tasks = Executors.newCachedThreadPool(new ThreadFactory() {
final AtomicInteger TID = new AtomicInteger(0);
final String GROUP_NAME = "TPWS-" + GID.getAndIncrement();
@Override
public Thread newThread(Runnable r) {
return new Thread(r, GROUP_NAME + TID.getAndIncrement());
}
});
查看 Executors 的创建线程池的方法：
/**
* Creates a thread pool that creates new threads as needed, but
* will reuse previously constructed threads when they are
* available, and uses the provided
* ThreadFactory to create new threads when needed.
* @param threadFactory the factory to use when creating new threads
* @return the newly created thread pool
* @throws NullPointerException if threadFactory is null
*/
public static ExecutorService newCachedThreadPool(ThreadFactory threadFactory) {
return new ThreadPoolExecutor(0, Integer.MAX_VALUE,
60L, TimeUnit.SECONDS,
new SynchronousQueue(),
threadFactory);
}
可以看出，这个方法最终创建了一个最小 0 个线程，最大 Integer.MAX_VALUE 个线程，每个线程 60s 超时时间。于是，当一个业务请求到来时，线程池创建一个新线程处理这个请求，在请求中调用了 Native 方法。当请求处理完后，线程归还线程池。60s 内如果没有新的请求进入，则该线程被线程池销毁，但是 Native 申请的 fd 没有释放。当新的请求到来时，又重新创建线程，重新分配 fd，以此类推，导致 fd 泄漏。
这次排查的经理告诉我们，当 Java 调用 Native 方法的时候一定要格外小心。由于虚拟机无法对大多数 Native 方法占用的资源进行管理，因此编写质量差的 Native 类库会直接导致不可预知的奇怪问题。特别是由于 C++ 在多线程、多进程模型上与 Java 有诸多不同，很多库在设计时就没有考虑全面，直接在 Java 内调用的时候可能就会出现在 C++ 中不会遇到的问题。
