使用kill -3捕获Java线程dump时栈输出不全、_java_thread_list长度与打印数不匹配问题

针对OpenJDK 11.0.7版本观测到的_java_thread_list标记总长度97、但仅输出43个线程栈的现象，触发原因分为两类：

• 版本固有缺陷：11.0.7版本的线程dump遍历逻辑存在两处设计问题：一是遍历全局线程列表的循环中，一旦遇到处于过渡状态的线程节点（含已加入全局列表未完成Java栈初始化、已触发栈回收流程但尚未从列表移除的节点），遍历逻辑会直接中断整个输出流程，不会跳过无效节点继续处理；二是栈输出过程中遇到写流阻塞、写操作返回错误时，没有内置重试机制，会直接终止剩余栈内容的输出。
• 输出链路截断：kill -3 <pid>触发的线程dump默认输出到JVM进程的stderr流，若该stderr被管道、日志采集Agent转发而非直接写入本地磁盘，当管道默认的4KB~64KB缓冲区被写满、下游消费端未及时拉取内容时，JVM侧的写操作会直接触发中断，导致后续线程栈无法正常输出。观测到的输出片段末尾被截断为单个0、仅输出43个栈的特征，完全匹配写流被管道截断的表现。

• 优先使用JDK内置的jstack <pid>命令捕获：通过JVM Attach API的通信通道传输全量线程数据，完全不依赖stderr写流，不会出现管道阻塞、遍历提前中断的问题，可直接获取全部线程的栈内容。容器环境下需确保jstack的运行用户与JVM进程的运行用户一致，避免权限校验失败。
• 必须使用kill -3触发捕获时，提前将JVM的stderr输出定向到本地磁盘文件：启动JVM时增加参数-Xlog:threadprint=info:file=/var/log/jvm_full_threads.log，线程dump内容会直接写入本地磁盘文件，不受管道缓冲区大小、网络转发链路的限制，不会出现中途截断。
• 临时应急处理：如果不允许修改JVM启动参数，可在触发dump前执行ulimit -p 65536将Linux管道缓冲区从默认值调整为系统最大上限，同时确保dump输出的落盘路径是本地磁盘而非远端网络挂载存储。
• 长期修复：将OpenJDK 11.0.7升级到11.0.11及以上的补丁版本，该版本已修复线程遍历遇到无效节点提前终止、写流失败无重试的两处固有缺陷。

内容的提问来源于stack exchange，提问作者silent-box