线上Kafka Broker服务JVM偶发无征兆挂起问题排查求助

问题现象 #

• 线上Kafka Broker服务低概率、无时间规律挂起，无崩溃、告警、错误日志输出
• 执行jstack [pid]无响应，使用jstack -m [pid]打印堆栈发现：
  • 所有线程（包括VM Thread）状态均为BLOCKED
  • 仅存在一个状态为IN_NATIVE的线程，对应JMX的Socket Accept逻辑

堆栈详情 #

VM Thread堆栈 #

ox0000ffff99f4da8c __pthread_cond_wait
ox0000ffff997c014c _ZN2os13PlatformEvent4parkEv
ox0000ffff9976f014 _ZN7Monitor5IWaitEP6Thread1
ox0000ffff9976faf0 _ZN7Monitor4waitEblb
ox0000ffff999355dc _ZN20SuspendibleThreadSet11synchronizeEv
ox0000ffff99858a68 _ZN20SafepointSynchronize5beginEv
ox0000ffff999d3124 _ZN8VMThread4loopEv
ox0000ffff999d3458 _ZN8VMThread3runEv
ox0000ffff997b8204 _ZL10java_startP6Thread
ox0000ffff99f47800 start_thread

唯一IN_NATIVE线程堆栈 #

ox0000ffff99de7dd8 __GI___poll
ox0000fffed7871a3c NET_Timeout0
ox0000fffe786ec40 Java_java_net_PlainSocketImpl_socketAccept
ox0000ffff8c015628 * java.net.PlainSocketImpl.socketAccept(java.net.SocketImpl) bci:0 (Interpreted frame)
ox0000ffff8c008498 * java.net.AbstractPlainSocketImpl.accept(java.net.SocketImpl) bci:7 line:409 (Interpreted frame)
ox0000ffff8c008498 * java.net.ServerSocket.implAccept(java.net.SocketImpl)
ox0000ffff8c008498 * java.net.ServerSocket.accept()
ox0000ffff8c008380 * sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept()
ox0000ffff8c008380 * sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop()

环境信息 #

• 架构：aarch64 Linux
• JDK版本：openjdk version "1.8.0_312" OpenJDK Runtime Environment (build 1.8.0_312-b07) OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode)

核心分析 #

VM Thread卡在SafepointSynchronize::begin() -> SuspendibleThreadSet::synchronize()流程，这是JVM进入安全点的必要步骤。安全点要求所有Java线程都到达指定状态，但唯一的IN_NATIVE线程（JMX的Socket accept线程）未响应安全点请求。

本质是旧版OpenJDK 8在aarch64架构下，PlainSocketImpl.socketAccept()的native实现存在安全点遗漏问题：当线程阻塞在poll()系统调用时，JVM无法中断该线程进入安全点，导致整个VM卡在安全点初始化阶段，所有线程被阻塞。

解决方案 #

1. 升级JDK版本：升级至OpenJDK 8u312之后的版本（如8u332及以上）或切换到JDK 11+，此类版本已修复aarch64架构下部分native方法的安全点遗漏问题
2. 禁用JMX本地监听：若无需JMX监控，通过JVM参数-Dcom.sun.management.jmxremote=false关闭JMX，避免生成该阻塞线程
3. 替换JMX监听实现：自定义RMIServerSocketFactory，改用带超时的监听逻辑，让线程定期回到Java层响应安全点请求
4. 临时应急方案：服务挂起时，执行kill -3 [pid]强制JVM生成堆转储和线程栈（部分场景下比jstack有效），同时重启服务恢复可用性

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