JVM 线程转储

JVM 线程转储（Thread Dump）是 Java 虚拟机在某一时刻对所有线程运行状态的快照记录。它详细记录了每个线程的调用栈、状态（如运行、等待或阻塞）、锁的持有与竞争情况等信息，是开发者剖析系统运行状况的得力工具。通过线程转储，测试工程师能够深入了解程序的行为，快速定位性能瓶颈或异常问题。

在故障测试中的作用与意义

在故障测试领域，如混沌工程或稳定性测试，测试工程师通过主动制造异常场景（如网络延迟、服务崩溃、资源瓶颈）来评估系统在极端环境下的表现。这些测试旨在暴露系统潜在的弱点，确保其在生产环境中具备高可用性和韧性。在这一过程中，JVM 线程转储（Thread Dump）作为捕捉线程状态的快照工具，发挥着至关重要的作用。它不仅能帮助定位问题，还能为优化系统设计提供数据支持。

线程转储在多种复杂场景中发挥着不可替代的作用，以下从实际应用角度展开说明：

系统响应迟缓，排查死锁或阻塞：当用户反馈系统变慢，线程转储能帮助快速定位问题根源。例如，分析调用栈可能发现两个线程互相持有对方需要的锁，导致死锁。结合日志，还能识别线程是否因数据库查询超时而被阻塞。实际案例中，某电商系统在促销活动时响应变慢，通过线程转储发现订单处理线程因锁竞争卡住，优化锁粒度后问题得以解决。
线程数异常增长，警惕资源泄漏：如果线程池配置不当或异步任务未正确回收，可能导致线程数激增。线程转储能揭示哪些线程未被销毁，进而定位代码中的问题。例如，某服务因定时任务未正确关闭导致线程泄漏，分析转储后发现大量重复的任务线程，修复代码后系统恢复稳定。
CPU 使用率异常，揪出 “忙等” 元凶：当服务器 CPU 使用率飙高，线程转储可帮助定位是否存在死循环或高计算任务。例如，某线程的调用栈显示反复执行某段逻辑，可能是算法效率低下。实际中，某日志处理系统因正则表达式复杂度过高导致 CPU 占用过载，通过转储定位问题后优化了匹配规则。
洞察系统负载与并发行为：在高并发场景下，线程转储能反映系统在特定时刻的线程分布和任务执行情况。例如，分析转储可发现线程池是否饱和，或者某些任务因 I/O 操作而长时间占用线程。这为优化线程池大小或调整任务调度提供了数据依据。例如，某支付系统在高峰期通过转储发现线程池配置不足，调整后显著提升了吞吐量。

常见线程转储获取方式解析

在软件测试中，特别是在性能测试和故障诊断场景下，获取线程转储是排查问题的关键手段。线程转储能够清晰展示 Java 应用中所有线程的状态和堆栈信息，帮助测试工程师快速定位死锁、线程阻塞或资源竞争等问题。以下介绍几种常见的获取线程转储方式，结合实际场景和注意事项，助力测试工程师更高效地开展工作。

1. 使用 jstack 命令

jstack 是 JDK 自带的命令行工具，简单高效，广泛应用于本地调试或容器化环境中。通过 jstack 可以快速生成指定 Java 进程的线程转储，常用于开发和测试阶段的故障排查。命令格式如下：

# 获取指定进程的线程转储并保存到文件
jstack <pid> > fun_tester_thread_dump.txt

其中，<pid> 是 Java 进程的 ID，可通过 jps 命令查看运行中的 Java 进程列表。例如，运行 jps 后可能看到类似输出：

12345 FunTesterApplication

将 12345 代入 jstack 命令即可。对于 Kubernetes 环境，需先通过 kubectl exec 进入容器内部执行命令。值得注意的是，频繁执行 jstack 可能对性能敏感的应用造成轻微影响，因此建议在非高峰时段操作。此外，确保输出文件路径可写，避免权限问题导致失败。

2. 通过 kill -3 信号触发

在类 Unix 系统（如 Linux 或 macOS）中，向 Java 进程发送 SIGQUIT 信号是一种轻量级的线程转储方式，适合快速获取信息而无需额外工具。命令如下：

# 向指定进程发送 SIGQUIT 信号
kill -3 <pid>

执行后，线程转储信息会输出到 JVM 的标准输出或其配置文件（如 catalina.out）指定的日志文件中。例如，在测试 Tomcat 应用时，线程转储可能出现在日志目录下的输出文件中。这种方式的优势在于操作简单，尤其适用于生产环境中快速诊断问题。但需要注意，如果 JVM 的标准输出被重定向到 /dev/null 或日志文件不可访问，可能会导致信息丢失。因此，测试工程师应提前确认 JVM 的输出配置。

3. 借助 JConsole 或 VisualVM 等图形化工具

对于需要远程调试或更直观分析的场景，JConsole 和 VisualVM 是强大的辅助工具。这类工具通过 JMX 连接到 Java 进程，提供图形化界面展示线程状态、堆内存使用情况等信息。测试工程师可以通过以下步骤操作：

• 启动 VisualVM，连接到目标 Java 进程。
• 进入 “线程” 选项卡，查看线程状态或直接导出线程转储。

这些工具特别适合性能测试中分析线程瓶颈。例如，在一次负载测试中，若发现响应时间异常延长，可通过 VisualVM 观察是否存在大量线程处于 WAITING 状态，从而定位问题根因。不过，这类工具对网络连接和权限要求较高，远程调试时需确保目标 JVM 开启了 JMX 端口。

4. 程序内调用 Thread.getAllStackTraces()

在某些测试场景中，测试工程师可能需要在代码中主动记录线程转储，例如在自动化测试中模拟故障场景或记录特定时刻的线程状态。Java 提供了 Thread.getAllStackTraces() 方法，允许程序直接获取所有线程的堆栈信息。示例代码如下：

// 获取当前所有线程的堆栈信息
Map<Thread, StackTraceElement[]> traces = Thread.getAllStackTraces();
// 遍历并记录线程信息到 FunTester 日志
for (Map.Entry<Thread, StackTraceElement[]> entry : traces.entrySet()) {
    Thread thread = entry.getKey();
    StackTraceElement[] stack = entry.getValue();
    System.out.println("Thread: " + thread.getName() + " in FunTester");
    for (StackTraceElement element : stack) {
        System.out.println("\t" + element);
    }
}

这种方式灵活性高，适合嵌入到测试框架或业务逻辑中。例如，在混沌工程实验中，可以通过定时调用该方法记录线程状态，分析系统在故障注入后的表现。但需要注意，该方法可能因线程数量过多而影响性能，建议在高并发场景下限制调用频率。

Kubernetes 环境中的实践

在 Kubernetes 环境中，jstack 和 kill -3 是最常用的线程转储方式，但操作上稍显复杂。测试工程师需要通过 kubectl exec 进入容器内部执行命令，例如：

kubectl exec -it <pod-name> -- jstack <pid> > /tmp/fun_tester_thread_dump.txt

由于容器环境的动态性，手动操作效率较低，建议结合自动化脚本或监控工具（如 Prometheus 和 Grafana）实现线程转储的定时采集。例如，可以编写脚本定期检查 Java 进程的 CPU 占用，若超过阈值则自动触发线程转储并上传到日志系统。这种方式在性能测试和混沌工程中尤为实用，能够大幅减少人工干预。

通过以上方式，测试工程师可以根据场景灵活选择合适的线程转储方法。无论是本地调试还是生产环境排查，熟练掌握这些工具和技巧，都将为高效定位问题、提升测试质量打下坚实基础。

Kubernetes API 远程执行 Shell 命令

在 Kubernetes 环境中，测试工程师常常需要远程操作容器以进行故障诊断或性能分析。Fabric8 是一个功能强大的 Java 客户端库，通过编程方式与 Kubernetes API 交互，极大简化了容器管理任务。借助 Fabric8，测试工程师可以轻松实现自动化操作，例如获取 Pod 信息、执行远程命令以及捕获命令输出。这对于自动化测试、性能测试和混沌工程场景尤为重要，能够显著提升效率。以下详细介绍 Fabric8 的核心能力及其在线程转储中的应用，结合实用示例帮助测试工程师快速上手。

Fabric8 提供了一系列便捷的 API，支持测试工程师以编程方式管理 Kubernetes 资源。以下是几种与测试工作密切相关的能力，结合实际场景加以说明：

• 查找特定 Namespace 下的 Pod：在 Kubernetes 集群中，Pod 通常分布在不同 Namespace 下。Fabric8 允许通过指定 Namespace 快速筛选 Pod，例如在性能测试中定位运行测试应用的 Pod。相比手动使用 kubectl 命令，Fabric8 的优势在于可以通过代码实现批量操作或动态筛选。例如，可以编写脚本定期检查某 Namespace 下所有 Pod 的状态，判断是否存在异常。
• 获取容器名称：一个 Pod 可能包含多个容器，获取容器名称是执行命令的前提。Fabric8 提供 API 直接获取 Pod 内的容器列表，方便测试工程师指定目标容器执行操作。例如，在混沌工程实验中，可以通过 Fabric8 获取容器名称，进而注入故障或收集日志。
• 远程执行 Shell 命令：Fabric8 支持在指定容器内执行 Shell 命令，例如运行 jstack 获取线程转储或 top 监控资源使用。这对于自动化测试场景尤其有用，测试工程师无需手动登录容器即可完成复杂操作。例如，在压力测试中，可以通过 Fabric8 定期执行 jstack，分析线程状态是否正常。
• 捕获命令输出结果：执行命令后，Fabric8 能够捕获输出结果并将其重定向到指定位置（如文件或日志系统）。这在故障诊断中非常实用，例如将 jstack 的输出保存为文件后，通过自动化脚本分析是否存在死锁或阻塞问题。

这些能力为测试工程师提供了灵活的工具，尤其在需要频繁操作 Kubernetes 环境的场景下，能够大幅减少手动操作的时间成本。

import io.fabric8.kubernetes.client.DefaultKubernetesClient;
import io.fabric8.kubernetes.client.KubernetesClient;
import io.fabric8.kubernetes.client.dsl.ExecWatch;

// 创建 Kubernetes 客户端，自动加载默认配置（如 ~/.kube/config）
KubernetesClient client = new DefaultKubernetesClient();

try {
    // 定义目标 Pod 和容器信息
String namespace = "default"; 【】// 目标 Namespace
    String podName = "fun-tester-java-app-pod"; // Pod 名称，包含 FunTester 标识
    String containerName = "fun-tester-java-container"; // 容器名称，包含 FunTester 标识
    // 构造 jstack 命令，获取 Java 进程的线程转储
    String command = "jstack $(pgrep java) > /tmp/fun_tester_thread_dump.txt";

    // 在指定 Pod 和容器内执行 Shell 命令
    ExecWatch execWatch = client.pods()
        .inNamespace(namespace)
        .withName(podName)
        .inContainer(containerName)
        .writingOutput(System.out) // 将命令输出重定向到标准输出，可改为文件
        .exec("sh", "-c", command);

    // 等待命令执行完成（视实际情况可添加超时机制）
    Thread.sleep(1000);

    // 可选：读取输出文件内容（需额外命令）
    String catCommand = "cat /tmp/fun_tester_thread_dump.txt";
    ExecWatch catWatch = client.pods()
        .inNamespace(namespace)
        .withName(podName)
        .inContainer(containerName)
        .writingOutput(System.out)
        .exec("sh", "-c", catCommand);

} finally {
    // 释放客户端资源
    client.close();
}

Show You Code

下面是一个方法的封装，增强了兼容性，思路是有限执行 JVM 命令，生成线程转储，然后在通过文件下载功能 download 本地。方法如下：

/**
 * Executes a command in a Kubernetes pod and waits for its completion.
 * 在 Kubernetes Pod 中执行命令并等待其完成。
 *
 * @param namespace The namespace of the pod. Pod 的命名空间。
 * @param podName The name of the pod. Pod 的名称。
 * @param command The command to execute. 要执行的命令。
 * @return void
 */
static def exec(def namespace, podName, command) {
    def phaser = new FunPhaser() // Synchronization mechanism for waiting. 用于等待的同步机制。
    phaser.register() // Register the phaser. 注册 phaser。
    try (ExecWatch execWatch = ChaosFault.getClient().pods()
            .inNamespace(namespace) // Specify the namespace. 指定命名空间。
            .withName(podName) // Specify the pod name. 指定 Pod 名称。
            .writingOutput(System.out) // Redirect standard output. 重定向标准输出。
            .writingError(System.err) // Redirect error output. 重定向错误输出。
            .usingListener(new ExecListener() { // Add an execution listener. 添加执行监听器。

                @Override
                void onOpen() {
                    log.info("open") // Log when the connection opens. 记录连接打开时的日志。
                }

                @Override
                void onFailure(Throwable t, ExecListener.Response failureResponse) {
                    log.error("failure", t) // Log on failure. 记录失败时的日志。
                    phaser.done() // Mark the phaser as done. 标记 phaser 完成。
                }

                @Override
                void onClose(int code, String reason) {
                    log.info("close code {} , reason {}", code, reason) // Log when the connection closes. 记录连接关闭时的日志。
                    phaser.done() // Mark the phaser as done. 标记 phaser 完成。
                }

                @Override
                void onExit(int code, Status status) {
                    log.info("exit code {} , status {}", code, status) // Log when the command exits. 记录命令退出时的日志。
                    phaser.done() // Mark the phaser as done. 标记 phaser 完成。
                }
            })
            .exec("/bin/sh", "-c", command)) { // Execute the command in a shell. 在 Shell 中执行命令。
        phaser.await(30) // Wait for up to 30 seconds. 最多等待 30 秒。
    }
}

/**
 * Creates a thread dump file in the specified pod and downloads it to the local machine.
 * 在指定的 Pod 中创建线程转储文件并下载到本地。
 *
 * @param namespace The namespace of the pod. Pod 的命名空间。
 * @param serviceName The name of the service to locate the pod. 用于定位 Pod 的服务名称。
 * @return void
 */
static def createAndDownloadThreadDump(String namespace, serviceName) {
    def pods = findPods(namespace, serviceName) // Find pods based on namespace and service name. 根据命名空间和服务名称查找 Pod。
    def podName = pods.get(0).getName() // Get the name of the first pod. 获取第一个 Pod 的名称。
    exec(namespace, podName, "jstack 1 > theaddump.txt") // Execute the jstack command to generate a thread dump file. 执行 jstack 命令生成线程转储文件。
    String podFilePath = "/app/theaddump.txt" // Path of the thread dump file inside the pod. Pod 内线程转储文件的路径。
    File localFile = new File("${serviceName}_theaddump${Time.getNow()}.txt") // Local file path to save the downloaded thread dump. 下载到本地的线程转储文件路径。
    downFileFromPod(namespace, podName, podFilePath, localFile) // Download the thread dump file from the pod to the local machine. 从 Pod 下载线程转储文件到本地。
}

FunTester 原创精华

从 Java 开始性能测试

故障测试与 Web 前端

服务端功能测试

性能测试专题

Java、Groovy、Go

测试开发、自动化、白盒

测试理论、FunTester 风采

视频专题