Java应用中io.vertx.core.impl.EventLoopContext内存泄漏排查求助

咱们先结合你的代码和遇到的问题，梳理下核心问题点和修复方案：

一、核心问题分析 #

1. WorkerExecutor未关闭导致的内存泄漏 #

你通过createSharedWorkerExecutor创建的WorkerExecutor是长期持有资源的线程池，而你的代码只负责创建并缓存到executorMap中，从未执行关闭操作。随着请求量增加，这些线程池会持续占用堆内存（线程对象、任务队列、相关上下文等），最终导致堆内存耗尽，GC频繁触发甚至应用无响应。

2. 双重检查锁定的锁对象错误 #

在getWorkerExecutor方法的同步块中，你用了Processors.class作为锁对象，但你的类实际名称是Processor——这个笔误会导致同步逻辑失效，可能重复创建多个同名的WorkerExecutor，进一步加剧内存占用。

3. 线程池资源未做限制 #

创建WorkerExecutor时你没有指定线程数和队列大小，Vert.x会使用默认值，如果请求量较大，线程池会无限制扩张（或队列堆积大量任务），占用更多内存。

二、具体修复方案 #

1. 修复锁对象，避免重复创建线程池 #

把同步块的锁对象改成正确的Processor.class，确保双重检查锁定逻辑生效：

public WorkerExecutor getWorkerExecutor(String threadName, Vertx vertxObj) {
    WorkerExecutor executor = executorMap.get(threadName);
    if (executor == null) {
        // 修复锁对象为当前类
        synchronized (Processor.class) {
            executor = executorMap.get(threadName);
            if(executor == null){
                // 指定线程池大小，避免无限制扩张
                executor = vertxObj.createSharedWorkerExecutor(threadName, 10);
                executorMap.putIfAbsent(threadName, executor);
            }
        }
    }
    return executor;
}

2. 添加WorkerExecutor的生命周期管理 #

在应用关闭时（比如Verticle的stop方法中），遍历executorMap关闭所有线程池，释放资源：

// 假设你的Processor类能拿到Vertx的关闭回调，或者在MainClass中添加关闭逻辑
public void shutdown() {
    for (WorkerExecutor executor : executorMap.values()) {
        executor.close();
    }
    executorMap.clear();
}

3. 考虑使用Vert.x默认线程池简化逻辑 #

如果你的业务场景不需要自定义命名的线程池，直接使用Vert.x内置的worker线程池即可，无需自己管理线程池：

@POST
@Path("/update_record")
@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_JSON })
public void processUpdateEvent(String data, @Suspended final AsyncResponse asyncResponse, @Context Vertx vertx) throws Exception{
    logger.info("update called");
    // 直接使用Vert.x默认worker线程池
    vertx.executeBlocking(future -> {
        MyProcessor processor = (MyProcessor) MainClass.context.getBean("myprocessorevent");
        try {
            processor.processMessage(data);
            future.complete();
        } catch (Exception e) {
            logger.error("consuming event failed: " + e.getMessage());
            future.fail(e);
        }
    }, res -> {
        Response response = res.succeeded() 
            ? Response.status(Response.Status.OK).build()
            : Response.status(Response.Status.INTERNAL_SERVER_ERROR).build();
        asyncResponse.resume(response);
    });
}

4. 检查MyProcessor的资源占用 #

结合MAT的内存快照，重点排查MyProcessor中是否持有大对象、未关闭的数据库连接、未释放的IO流或长期存活的集合对象，这些也可能是内存堆积的诱因。

三、额外建议 #

• 升级Vert.x版本：你当前使用的3.3.3是非常老旧的版本，后续版本修复了大量内存泄漏和线程池管理的bug，升级到较新的稳定版（比如4.x系列）能从根源减少这类问题。
• 配置JVM参数：添加内存监控参数（如-XX:+HeapDumpOnOutOfMemoryError），方便后续快速定位内存问题；调整GC参数（如使用G1GC）优化GC性能。

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