使用kafka-clients 3.0.0获取Topic时出现Java堆内存溢出问题求助

问题背景 #

使用 org.apache.kafka:kafka-clients:3.0.0 调用AdminClient获取Topic列表时，多数场景正常，但偶发抛出堆内存异常。堆转储分析结果显示：

• java.lang.ThreadGroup 实例占用202869120字节（占堆内存93.21%），被 kafka-admin-client-thread | adminclient-664 线程引用
• 内存集中在该ThreadGroup关联的 java.lang.Thread[] 数组中，占用202867568字节（同占比93.21%）
• 集群环境为Confluent Kafka，安全配置为 SASL_SSL + PLAIN 机制，已尝试增加堆内存200MB，问题未解决

核心原因分析 #

1. AdminClient线程泄漏（3.0.0版本已知bug）
   Kafka Clients 3.0.0版本的AdminClient存在线程池资源未正确回收的问题，当频繁创建和销毁AdminClient实例时，对应的线程会持续累积到ThreadGroup中，无法被GC回收，最终导致堆内存耗尽。

2. 未正确关闭AdminClient实例
   若代码中每次请求都新建AdminClient，且未在使用完成后显式调用 close() 方法（尤其是异常分支中遗漏关闭操作），会导致线程、连接等资源长期驻留内存。

3. SASL_SSL连接的线程资源未释放
   PLAIN机制下的SASL握手流程会创建额外线程，若AdminClient未正常关闭，这些线程会被ThreadGroup持有，无法被回收。

解决方案 #

1. 复用AdminClient实例（优先推荐） #

AdminClient是线程安全的，官方明确建议单例复用，避免频繁创建/销毁实例。示例代码：

// 全局单例初始化AdminClient
private static AdminClient adminClient;

static {
    Properties props = new Properties();
    props.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, "your-broker-list");
    props.put(AdminClientConfig.SECURITY_PROTOCOL_CONFIG, "SASL_SSL");
    props.put(SaslConfigs.SASL_MECHANISM, "PLAIN");
    // 其他配置...
    adminClient = AdminClient.create(props);
}

// 业务方法中直接复用
public List<String> listTopics() throws ExecutionException, InterruptedException {
    return adminClient.listTopics().names().get();
}

// 应用关闭时关闭AdminClient
public void shutdown() {
    if (adminClient != null) {
        adminClient.close();
    }
}

2. 升级kafka-clients版本 #

3.0.0版本的线程泄漏问题已在后续版本中修复，建议升级到3.1.0及以上稳定版（优先选择3.3.x或3.4.x系列，兼容性和稳定性更好）。

3. 显式关闭AdminClient（若无法复用） #

如果必须创建多个AdminClient实例，确保在使用完成后（包括异常场景）调用 close() 方法：

try (AdminClient adminClient = AdminClient.create(props)) {
    // 执行Topic操作
    adminClient.listTopics().names().get();
} catch (Exception e) {
    // 异常处理
}
// try-with-resources会自动调用close()

4. 优化AdminClient配置 #

调整以下参数，加速闲置资源回收：

• admin.client.idle.connection.timeout: 缩短空闲连接超时时间（默认30000ms，可调整为10000ms）
• connections.max.idle.ms: 控制连接池中空闲连接的存活时间（默认540000ms，可调整为60000ms）

验证方法 #

• 升级或调整代码后，监控JVM堆内存变化，观察是否再出现突增情况
• 定期生成堆转储，对比ThreadGroup中Thread[]的大小是否稳定

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