为何Java应用生成大量‘JMX client heartbeat’线程致高CPU及崩溃？

我来帮你理清这些线程的来头，以及定位问题的方向：

一、这些心跳线程是什么？ #

这些名为JMX client heartbeat的线程是JDK内置的JMX远程客户端心跳检测线程，由com.sun.jmx.remote.internal.ClientCommunicatorAdmin类负责管理。它们的核心作用是：定期向远程MBean服务器发送心跳请求，防止因为长时间无交互导致连接被防火墙、负载均衡器这类中间件主动断开。

从你提供的jstack片段来看，这些线程当前处于TIMED_WAITING (sleeping)状态——这意味着它们此刻并没有占用CPU资源，真正导致你应用CPU过高甚至崩溃的，应该是其他线程（你提供的日志里没包含这些高负载线程）。

二、为什么会出现这么多这类线程？ #

每创建一个JMX远程连接（即JMXConnector实例），JDK就会自动对应生成一个心跳检测线程。如果你的应用存在JMX连接泄漏问题——也就是频繁创建连接，但使用完毕后没有正确调用close()方法释放资源，就会导致大量心跳线程堆积。

虽然休眠状态的线程不占CPU，但每个线程都会消耗内存（比如线程栈空间），当线程数量积累到一定程度，可能会引发OOM或者系统线程数耗尽，最终导致应用崩溃。

三、排查与解决建议 #

1. 修复JMX连接泄漏问题 #

检查代码中创建JMXConnector的所有场景，确保在使用完毕（包括异常场景）都关闭连接：

JMXConnector connector = JMXConnectorFactory.connect(jmxServiceUrl);
try {
    // 执行MBean相关操作，比如获取MBeanServerConnection
    MBeanServerConnection connection = connector.getMBeanServerConnection();
    // ...业务逻辑
} catch (IOException e) {
    // 异常处理
} finally {
    // 必须在finally块中关闭连接，确保无论是否异常都能释放资源
    if (connector != null) {
        try {
            connector.close();
        } catch (IOException e) {
            // 关闭时的异常处理
        }
    }
}

2. 获取全量jstack日志定位高CPU线程 #

当前你只截取了心跳线程的信息，需要获取完整的jstack日志来找到真正的祸根：

• 先用top -H命令找到CPU占用最高的线程ID（注意是线程ID，不是进程PID）；
• 把线程ID转换成十六进制（比如用printf "%x\n" <线程ID>）；
• 在全量jstack日志中搜索这个十六进制值，找到对应的线程栈，就能定位到导致CPU过高的代码逻辑。

3. 临时优化（仅缓解，非根治） #

如果暂时无法修复连接泄漏，可以通过JVM参数调整心跳间隔，减少线程唤醒频率：

-Dcom.sun.jmx.remote.internal.ClientCommunicatorAdmin.checkInterval=60000

默认心跳间隔是10秒（10000ms），改成60秒可以降低线程活动频率，但这只是临时措施，核心还是要解决连接泄漏问题。

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