Tech

理解 CRaC 背后的 Linux 系统编程

# CRaC 的性能飞跃与 Linux 内核的基石

Java 应用的启动速度，尤其是在微服务和 Serverless 场景下的“冷启动”，一直是其性能优化的重点。传统的启动过程涉及 JVM 初始化、类加载和 JIT 预热，耗时较长。CRaC (Coordinated Restore at Checkpoint) 技术为此提供了一种创新方案：它在应用达到理想状态时捕获其完整运行时快照（Checkpoint），并在需要时快速恢复（Restore），从而实现毫秒级启动和即时峰值性能。

这种强大的进程“冻结”与“复苏”能力并非凭空而来，它深度依赖于 Linux 操作系统提供的底层机制，并通过 CRIU (Checkpoint/Restore In Userspace) 这个工具集得以实现。因此，要真正理解 CRaC 的工作原理，探究其背后的 Linux 系统编程知识至关重要。本文将为熟悉编程但可能不熟悉 Linux 底层的开发者，解析 CRaC 实现所依赖的关键 Linux 概念（如进程/线程、/proc 文件系统、ptrace 系统调用等），揭示 CRaC 性能飞跃背后的 Linux“魔法”。

# 进程与线程及其生命周期

要理解 CRaC 如何操作运行中的 Java 应用，我们首先需要了解 Linux 是如何组织和管理程序执行的。其核心概念是进程 (Process)。你可以将进程看作是一个正在运行的程序的实例，它是操作系统分配资源（如内存、文件句柄）和进行调度的基本单位。每个进程都仿佛生活在自己的独立世界里，拥有独立的地址空间，这保证了进程间的隔离性。

然而，在一个进程内部，往往需要同时执行多个任务流。这时线程 (Thread) 就登场了。线程是进程内部的实际执行单元，有时也被称为轻量级进程（LWP）。与进程不同，同一进程内的所有线程共享该进程的地址空间和大部分资源，这使得线程间的通信和切换更为高效。但每个线程仍然保有自己独立的执行上下文，如程序计数器、寄存器和栈。

有趣的是，从 Linux 内核的视角来看，它并不严格区分进程和线程。两者都被视为可调度的“任务 (Task)”，并由统一的数据结构 task_struct 来描述。线程仅仅是与其他任务共享了更多资源（特别是内存地址空间）的任务而已。因此，内核调度器可以对它们一视同仁。为了管理这些任务，系统为它们分配了唯一的身份标识：PID (Process ID) 用于标识整个进程（一组共享资源的线程），而 TID (Thread ID) 则用于标识每一个单独的线程（任务）。对于单线程进程，PID 和 TID 是相同的。

新进程的诞生，最经典的方式是通过 fork() 系统调用。当一个进程调用 fork()，内核会创建出它的一个几乎完全相同的副本——子进程。子进程继承了父进程大部分状态，包括内存内容的副本（通过写时复制优化）、文件描述符等。fork() 的奇妙之处在于它在父进程中返回子进程的 PID，而在子进程中返回 0，使得程序可以根据返回值区分父子，执行不同的逻辑。CRIU 在恢复进程状态时，正是利用 fork() 来重建 Checkpoint 时刻的进程树结构。

fork() 示例代码 (fork_example.c):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#include <stdio.h>  
#include <stdlib.h>  
#include <unistd.h>  
#include <sys/types.h>  
#include <sys/wait.h>

int main() {  
    pid_t pid = fork(); // 创建子进程

    if (pid < 0) { // fork 失败  
        perror("fork failed");  
        exit(EXIT_FAILURE);  
    } else if (pid == 0) { // 子进程执行的代码  
        printf("I am the child process, PID: %d\n", getpid());  
        sleep(2); // 模拟工作  
        printf("Child process exiting.\n");  
        exit(EXIT\_SUCCESS); // 子进程正常退出  
    } else { // 父进程执行的代码  
        printf("I am the parent process, PID: %d, Child PID: %d\n", getpid(), pid);  
        printf("Parent waiting for child...\n");  
        wait(NULL); // 简单等待任意子进程  
        printf("Parent process: Child finished.\n");  
    }
    
    printf("Process %d exiting.\n", getpid());  
    return 0;  
}  
// 编译运行：gcc fork_example.c -o fork_example && ./fork_example

除了 fork()，还有一个更底层的系统调用 clone()，它提供了更细粒度的控制，允许指定新创建的任务与父任务共享哪些资源，因此 clone() 既可以用来创建进程，也可以用来创建线程。

fork() 创建的子进程默认执行的是和父进程相同的代码。如果希望子进程去执行一个全新的程序，就需要 exec 系列系统调用（如 execv(), execlp() 等）的帮助。exec 调用会用新程序的映像完全替换当前进程的内存空间（代码、数据、堆栈），然后从新程序的入口点开始执行。一旦 exec 成功，原来的程序就不复存在了，这个调用本身也不会返回。CRaC 在恢复过程中，criuengine 这个辅助程序就利用了一连串的 execv 调用，不断“变身”，最终成为负责等待恢复后 JVM 退出的 restorewait 进程。

execv() 示例代码 (exec_example.c):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

#include <stdio.h>  
#include <stdlib.h>  
#include <unistd.h>  
#include <sys/types.h>  
#include <sys/wait.h>

int main() {  
    pid_t pid = fork();

    if (pid < 0) {  
        perror("fork failed");  
        exit(EXIT_FAILURE);  
    } else if (pid == 0) { // 子进程  
        printf("Child process (PID: %d) will execute 'ls -l'\n", getpid());  
        char *args[] = {"/bin/ls", "-l", NULL}; // 准备参数列表  
        execv(args[0], args); // 执行新程序  
        // 如果 execv 返回，说明出错了  
        perror("execv failed");  
        exit(EXIT_FAILURE);  
    } else { // 父进程  
        printf("Parent process (PID: %d) waiting for child (PID: %d)...\n", getpid(), pid);  
        wait(NULL); // 等待子进程结束  
        printf("Parent process: Child finished executing 'ls -l'.\n");  
    }  
    return 0;  
}  
// 编译运行：gcc exec_example.c -o exec_example && ./exec_example

进程有生就有灭。当子进程结束时，它并不会立即消失。内核会保留它的退出状态等信息，等待父进程来“认领”。父进程通过调用 wait() 或 waitpid() 系统调用来获取子进程的终止信息，并告知内核可以彻底清理该子进程了。waitpid() 提供了更多控制，比如可以等待指定的子进程，或者以非阻塞的方式检查子进程状态。

waitpid() 示例代码 (waitpid_example.c):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

#include <stdio.h>  
#include <stdlib.h>  
#include <unistd.h>  
#include <sys/types.h>  
#include <sys/wait.h>

int main() {  
    pid_t pid1, pid2;  
    int status;

    pid1 = fork(); // 创建第一个子进程  
    if (pid1 == 0) { /* Child 1 */ printf("Child 1 (PID: %d) running...\n", getpid()); sleep(2); printf("Child 1 exiting.\n"); exit(5); }
    
    pid2 = fork(); // 创建第二个子进程  
    if (pid2 == 0) { /* Child 2 */ printf("Child 2 (PID: %d) running...\n", getpid()); sleep(4); printf("Child 2 exiting.\n"); exit(10); }
    
    // 父进程等待特定的子进程 pid1  
    printf("Parent waiting for Child 1 (PID: %d)...\n", pid1);  
    pid_t terminated_pid = waitpid(pid1, &status, 0); // 阻塞等待 pid1
    
    if (terminated_pid == pid1 && WIFEXITED(status)) {  
        printf("Parent: Child 1 terminated normally with status: %d\n", WEXITSTATUS(status));  
    } else { /* Handle error or abnormal termination */ }
    
    // 父进程等待另一个子进程 pid2  
    printf("Parent waiting for Child 2 (PID: %d)...\n", pid2);  
    terminated_pid = waitpid(pid2, &status, 0); // 阻塞等待 pid2  
     if (terminated_pid == pid2 && WIFEXITED(status)) {  
        printf("Parent: Child 2 terminated normally with status: %d\n", WEXITSTATUS(status));  
    } else { /* Handle error or abnormal termination */ }
    
    printf("Parent exiting.\n");  
    return 0;  
}  
// 编译运行：gcc waitpid_example.c -o waitpid_example && ./waitpid_example

如果在子进程终止后，父进程没有及时调用 wait() 或 waitpid()，那么这个子进程就会变成僵尸进程 (Zombie Process)。它虽然不再运行，但仍在进程表中占据一个位置，等待父进程回收。如果父进程先于子进程退出，子进程就成了孤儿进程 (Orphan Process)。为了避免孤儿进程变成无人认领的僵尸，Linux 会自动将它们的父进程设置为 init 进程（PID 1），由 init 进程负责回收它们。

理解了孤儿进程和父进程回收机制后，就能明白一种常见的编程技巧——Double Fork。它的目的是创建一个与原始父进程完全脱离关系的后台进程（守护进程）。其步骤是：进程 A fork 出子进程 B，然后进程 A 立刻 waitpid() 等待 B 结束并退出；子进程 B 再次 fork 出孙子进程 C，然后 B 自己立刻退出；此时，孙子进程 C 成为孤儿，被 init 进程接管，从而与 A 彻底解耦。CRIU 在执行 Checkpoint 时，就运用了类似 double fork 的方法，让执行 criu dump 命令的进程脱离被操作的 JVM 进程树，避免了“自己冻结自己”的尴尬局面。

double_fork 示例代码 (double_fork_example.c):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

#include <stdio.h>  
#include <stdlib.h>  
#include <unistd.h>  
#include <sys/types.h>  
#include <sys/wait.h>

int main() {  
    pid_t pid1 = fork(); // 第一次 fork

    if (pid1 < 0) { perror("First fork failed"); exit(EXIT_FAILURE); }  
    else if (pid1 == 0) { // 第一个子进程 (进程 B)  
        pid_t pid2 = fork(); // 第二次 fork  
        if (pid2 < 0) { perror("Second fork failed"); exit(EXIT_FAILURE); }  
        else if (pid2 == 0) { // 孙子进程 (进程 C)  
            printf("Grandchild process (PID: %d, Parent PID: %d) starting.\n", getpid(), getppid());  
            // 通常在这里执行 setsid() 等守护进程化操作  
            sleep(10); // 模拟后台任务  
            printf("Grandchild process finished.\n");  
            exit(EXIT_SUCCESS);  
        } else { // 第一个子进程 (进程 B) 立即退出  
            printf("First child process (PID: %d) exiting immediately.\n", getpid());  
            exit(EXIT_SUCCESS);  
        }  
    } else { // 原始父进程 (进程 A)  
        printf("Original parent process (PID: %d) waiting for first child (PID: %d).\n", getpid(), pid1);  
        waitpid(pid1, NULL, 0); // 等待第一个子进程退出  
        printf("Original parent exiting.\n");  
        // 孙子进程已成为孤儿并由 init 接管  
    }  
    return 0;  
}  
// 编译运行：gcc double_fork_example.c -o double_fork_example && ./double_fork_example

掌握了 Linux 进程和线程的生命周期管理，我们就能更好地理解 CRaC 是如何在这些基础上进行精确的状态捕获与恢复。接下来，我们将目光投向 Linux 提供的一个强大工具——/proc 文件系统，看看它如何帮助我们“透视”运行中进程的内部状态。

# /proc 文件系统：内核状态的“透视镜”

我们已经了解了 Linux 如何创建和管理进程，但要实现像 CRaC 那样的“冻结”与“复苏”，就必须有办法深入探查一个正在运行的进程内部的详细状态。Linux 提供了一个非常强大的机制来做到这一点，那就是 /proc 文件系统。

初看起来，/proc 像是一个普通的目录，你可以用 cd 进入，用 ls 查看。但它实际上是一个虚拟文件系统。这意味着它里面的文件和目录并不真正存储在磁盘上，而是由 Linux 内核在运行时动态生成的。/proc 是内核向用户空间（运行中的程序和用户）暴露其内部数据结构和系统信息的主要接口之一。你可以把它想象成一扇窗户，透过它，我们可以直接观察到内核管理下的系统状态，特别是运行中进程的实时信息。

这对于 CRIU 和 CRaC 来说简直是无价之宝。当 CRIU 需要对一个进程执行 Checkpoint 时，它的大部分信息来源就是 /proc 文件系统。通过读取 /proc 下的特定文件，CRIU 能够获取到目标进程几乎所有的关键状态数据，从而构建出完整的进程快照。

让我们来看看 /proc 下与进程相关的几个关键“情报站”，它们通常位于以进程 PID 命名的目录下，即 /proc/<pid>/：

  • 内存布局图 (/proc/<pid>/maps 和 smaps): 这两个文件揭示了进程的虚拟内存是如何组织的。maps 文件列出了进程的所有内存区域（称为 VMA，Virtual Memory Area），包括代码段、数据段、堆、栈以及内存映射的文件和共享库，标明了每个区域的起止地址和权限。smaps 文件则提供了更详细的信息，包括每个 VMA 实际占用的物理内存（RSS - Resident Set Size）、共享/私有内存量、脏页（Dirty pages）数量等。CRIU 通过解析它们来精确了解进程的内存结构，这是 Checkpoint 和 Restore 内存状态的基础。
  • 打开的文件和连接 (/proc/<pid>/fd/ 和 fdinfo/): fd 是一个目录，里面包含了指向该进程当前打开的所有文件描述符的符号链接。链接的名称就是文件描述符的数字（如 0, 1, 2 分别代表标准输入、输出、错误），链接的目标则指明了它实际代表的文件、管道或套接字。而 fdinfo 目录下则包含了与 fd 中每个描述符对应的文件，记录了更详细的状态信息，比如文件的当前读写位置（offset）、打开时的标志位（flags）等。CRIU 需要读取这些信息来保存和恢复进程打开的文件状态。
  • 进程状态报告 (/proc/<pid>/stat): 这个文件以一行文本的形式，提供了关于进程的大量状态信息，由空格分隔。包括进程名、状态（运行、睡眠、僵尸等）、父进程 PID、进程组 ID、使用的内存量、CPU 时间统计等等。CRIU 用它来获取进程的基本属性和运行统计。
  • 线程成员列表 (/proc/<pid>/task/): 对于多线程进程，这个目录非常重要。它下面包含了以该进程下所有线程的 TID 命名的子目录。通过遍历这个目录，CRIU 可以识别出一个进程包含的所有线程（任务），并对每个线程进行单独的状态捕获。
  • 子进程记录 (/proc/<pid>/task/<tid>/children): 这个文件（位于特定线程目录下）记录了由该线程直接创建的所有子进程的 PID 列表。通过递归地读取这个文件，CRIU 能够准确地构建出完整的进程树或进程家族。
  • 内存映射文件访问 (/proc/<pid>/map_files/): 这个目录包含了指向进程内存中通过文件映射（mmap）方式加载的实际文件的符号链接。链接的名称对应 maps 文件中的地址范围。这为 CRIU 提供了一种可靠的方式来访问和读取这些映射文件的内容。

通过组合利用 /proc 文件系统提供的这些（以及其他未列出的）信息源，CRIU 能够像侦探一样，细致入微地收集目标进程及其所有线程、子进程在 Checkpoint 时刻的完整状态。没有 /proc 这个强大的“透视镜”，实现用户空间的 Checkpoint/Restore 将会困难得多。

了解了如何通过 /proc 获取进程状态后，我们接下来将关注进程运行的“舞台”——内存管理，以及进程如何与外部世界交互的“管道”——文件描述符。

# ptrace 系统调用：掌控进程的“遥控器”

通过 /proc 文件系统，我们获得了观察运行中进程内部状态的强大能力，就像有了一副“透视镜”。但这还不够，要实现像 CRaC/CRIU 的 Checkpoint/Restore，我们不仅需要观察，还需要能够控制和操纵目标进程——在合适的时机让它暂停，读取甚至修改它的内存和寄存器状态，甚至强制它执行某些操作。这时，Linux 提供了一个终极武器，也是一个颇具争议但极其强大的系统调用：ptrace (process trace)。

ptrace 提供了一种机制，允许一个进程（称为 tracer，追踪者）去观察和控制另一个进程（称为 tracee，被追踪者）的执行，检查和改变 tracee 的内存和寄存器。你可以把它想象成一个赋予 tracer 进程的“远程控制器”，可以用来遥控 tracee 进程的一举一动。

这个系统调用是许多底层工具的基石：

  • 调试器 (Debuggers)：像 GDB 这样的调试器，其核心功能（设置断点、单步执行、检查变量值、查看调用栈等）几乎完全依赖于 ptrace。调试器就是一个 tracer 进程，而被调试的程序就是 tracee。
  • 系统调用追踪工具 (System Call Tracers)：strace 命令能够显示一个进程执行的所有系统调用及其参数和返回值，这也是通过 ptrace 实现的。
  • CRIU (Checkpoint/Restore In Userspace)：正如我们之前提到的，CRIU 大量使用 ptrace 来完成那些仅靠 /proc 无法完成的任务，比如精确地暂停进程、获取和恢复寄存器状态、注入“寄生代码”等。

ptrace 本身是一个非常复杂的系统调用，它的行为由传递给它的第一个参数 request 决定。下面我们介绍一些它提供的关键能力，这些能力对于理解 CRIU 的工作至关重要：

  1. 建立追踪关系 (Attaching)：
    • PTRACE_ATTACH 或 PTRACE_SEIZE：这是 tracer 控制 tracee 的第一步。Tracer 使用这两个请求之一来“附着”到目标 tracee 进程上。一旦附着成功，tracee 就会暂停下来，并且其状态变化（如收到信号、执行系统调用）都会通知 tracer。PTRACE_SEIZE 是一个较新的、更推荐的方式，它避免了 PTRACE_ATTACH 中使用 SIGSTOP 信号可能带来的副作用，控制更为精确。
  2. 读写寄存器 (Reading/Writing Registers)：
    • PTRACE_GETREGS, PTRACE_GETFPREGS 等：允许 tracer 读取 tracee 当前的通用寄存器（如指令指针 EIP/RIP、栈指针 ESP/RSP 等）、浮点寄存器等 CPU 状态。
    • PTRACE_SETREGS, PTRACE_SETFPREGS 等：允许 tracer 修改 tracee 的寄存器状态。这对于恢复进程到某个精确的执行点至关重要，CRIU 在 Restore 阶段就需要用它来设置好恢复后进程的 CPU 上下文。
  3. 读写内存 (Reading/Writing Memory)：
    • PTRACE_PEEKDATA, PTRACE_PEEKTEXT：允许 tracer 读取 tracee 进程地址空间中任意位置的数据（通常以字长为单位）。
    • PTRACE_POKEDATA, PTRACE_POKETEXT：允许 tracer 向 tracee 进程地址空间中任意位置写入数据。CRIU 正是利用这个能力，在 Checkpoint 阶段向目标进程注入“寄生代码”（一段帮助收集内部信息的二进制代码），并在 Restore 阶段将快照中的内存数据写回进程空间。
  4. 控制执行 (Controlling Execution)：
    • PTRACE_CONT：让暂停的 tracee 继续执行。可以选择是否传递一个信号给 tracee。
    • PTRACE_SYSCALL：让 tracee 继续执行，直到它进入或退出下一个系统调用时再次暂停，并通知 tracer。strace 就是基于此工作的。CRIU 也用它来精确控制目标进程执行特定的系统调用（如 mmap, munmap）来辅助内存的 Checkpoint 和 Restore。
    • PTRACE_SINGLESTEP：让 tracee 执行一条机器指令，然后再次暂停。这是调试器实现单步执行的基础。
  5. 解除追踪关系 (Detaching)：
    • PTRACE_DETACH：Tracer 结束对 tracee 的追踪。Tracee 会恢复正常执行，就像从未被追踪过一样（除非 tracer 修改了它的状态）。

通过这些强大的（甚至可以说是危险的）能力，ptrace 赋予了 CRIU 超越普通进程权限的操作能力。它不仅能通过 /proc 看到进程的状态，更能像外科医生一样，精确地暂停进程、检查和修改其内部状态（内存和寄存器），甚至“借用”目标进程的上下文来执行特定操作（如注入代码、强制执行系统调用）。正是 ptrace 的存在，使得在用户空间实现复杂且精确的进程 Checkpoint/Restore 成为可能，也间接支撑了 CRaC 技术的实现。

当然，ptrace 的强大也意味着潜在的风险，操作系统通常会对其使用施加一些安全限制（例如，一个普通用户进程不能随意 ptrace 其他用户的进程或特权进程）。

理解了 ptrace 的核心能力后，我们对 CRIU 如何完成那些看似不可能的任务，应该有了更深的体会。接下来，我们将把前面介绍的知识点串联起来，看看 CRIU 具体是如何一步步实现 Checkpoint 和 Restore 的。

# CRIU 如何实现 Checkpoint 和 Restore？

现在，我们已经了解了 Linux 的进程线程模型、强大的 /proc 文件系统以及拥有“遥控”能力的 ptrace 系统调用。是时候将这些知识点串联起来，看看 CRIU (Checkpoint/Restore In Userspace) 是如何利用它们来施展“冻结” (Checkpoint) 和“复苏” (Restore) 进程的魔法了。

# Checkpoint (冻结过程)：为进程拍下精确快照

当 CRIU 被要求对一个进程（及其后代）进行 Checkpoint 时，它会执行一系列精心设计的步骤：

  1. 识别目标家族: 首先，CRIU 需要确定要冻结的完整目标。它从用户指定的根进程 PID 开始，通过递归地读取 /proc/<pid>/task/<tid>/children 文件，像剥洋葱一样，找出所有相关的子进程和线程，构建出完整的进程树。
  2. 全体“立正”: 接下来，CRIU 需要让这个庞大家族的所有成员都暂停下来。它使用 ptrace(PTRACE_SEIZE, …) 附着到进程树中的每一个任务（进程/线程）上。PTRACE_SEIZE 会让这些任务在下一次内核有机会介入时（比如系统调用或中断）进入暂停状态，并且这种暂停方式比老的 PTRACE_ATTACH 更为干净，不依赖 SIGSTOP 信号。
  3. 信息大搜集: 进程树被冻结后，CRIU 开始扮演“情报员”的角色，通过 /proc 文件系统和 ptrace 收集每个任务的详细状态：
    • 内存布局: 解析 /proc/<pid>/maps 和 smaps 获取虚拟内存区域（VMA）的地址、大小、权限、映射来源（文件或匿名）等信息。
    • 文件描述符: 读取 /proc/<pid>/fd/ 和 fdinfo/ 目录，记录下所有打开的文件、管道、套接字及其类型、路径、当前读写位置、标志位等状态。
    • 进程/线程核心状态: 通过 /proc/<pid>/stat 获取进程的基本属性，更重要的是，使用 ptrace(PTRACE_GETREGS, …) 和 PTRACE_GETFPREGS 等命令，直接读取每个任务暂停时的CPU 寄存器内容（包括指令指针、栈指针、通用寄存器等）。这是确保恢复后能从正确位置继续执行的关键。
    • 其他资源: 收集如信号处理器设置、定时器、凭证（UID/GID）、命名空间隶属关系等信息。
  4. 内存内容转储 (可能需要“寄生虫”帮忙): 获取内存布局只是第一步，还需要把这些内存区域里的实际数据保存下来。对于大部分内存区域，CRIU 可以通过 /proc/<pid>/mem 文件或者 process_vm_readv 系统调用来读取。但对于某些特殊或私有的内存区域，或者为了获取某些无法从外部探测的内部状态（如精确的文件描述符状态），直接读取可能受限或效率不高。这时，CRIU 会祭出它的“杀手锏”——寄生代码 (Parasite Code)。
    • CRIU 使用 ptrace 在目标进程的地址空间中分配一小块内存（通过强制目标进程执行 mmap 系统调用）。
    • 然后，使用 ptrace(PTRACE_POKEDATA, …) 将一段预先编译好的、与位置无关的（PIE）二进制代码（寄生代码）写入这块内存。
    • 最后，通过 ptrace 修改目标进程的指令指针，让它跳转执行这段寄生代码。
    • 寄生代码运行在目标进程的上下文中，拥有访问其所有资源的权限，可以高效地完成内存转储、收集内部信息等任务，并将结果传递给 CRIU。任务完成后，寄生代码通过 rt_sigreturn 系统调用恢复目标进程之前的寄存器状态，CRIU 再强制目标进程执行 munmap 清理掉寄生代码占用的内存，最后 ptrace(PTRACE_DETACH, …) 脱离，整个过程对目标进程来说几乎是“无痕”的。
  5. 写入镜像文件: CRIU 将收集到的所有状态信息（内存布局、寄存器、文件描述符状态、内存数据等）组织起来，写入到磁盘上的一系列镜像文件中。这些文件共同构成了进程在 Checkpoint 时刻的完整快照。
  6. (可选) 终止原进程: 在某些场景下（比如 CRaC 的默认行为），Checkpoint 完成后，原始的 JVM 进程会被 CRIU 终止。

# Restore (复苏过程)：从快照重建鲜活进程

Restore 过程可以看作是 Checkpoint 的逆操作，它更加复杂，需要精确地重建进程状态：

  1. 解析镜像，规划蓝图: CRIU 首先读取 Checkpoint 生成的镜像文件，分析进程间的关系（父子、共享资源等），制定恢复计划。
  2. 搭建骨架: CRIU 严格按照镜像中记录的进程树结构，通过多次调用 fork() 来创建新的进程。在这个阶段，通常只创建进程的主线程。
  3. 恢复基本资源: 对于每个新创建的进程，CRIU 开始恢复大部分状态：
    • 文件描述符: 根据镜像信息重新打开文件（可能需要验证路径有效性）、创建管道和套接字，并设置好它们的状态（如文件偏移量）。对于共享的文件描述符，需要确保它们指向同一个内核对象（可能用到 SCM_RIGHTS 等技术）。
    • 内存映射 (初步): 使用 mmap() 根据镜像中的 VMA 信息创建内存区域。对于私有内存，会先映射匿名内存，稍后再填充数据；对于文件映射，会重新映射相应的文件。此时映射的虚拟地址可能还不是最终的目标地址。
    • 命名空间: 如果进程使用了非默认的命名空间，CRIU 会负责创建或加入这些命名空间。
    • 其他: 恢复工作目录、根目录、信号处理器等。
  4. 关键步骤：切换上下文与精细恢复: 这是 Restore 中最精妙也最困难的部分。因为执行 Restore 操作的 CRIU 代码本身可能就位于需要被恢复内容覆盖的内存区域。为了解决这个问题：
    • CRIU 会找到一块临时的、安全的内存“空地”，加载一小段自包含的、位置无关的恢复器代码 (Restorer Context)。
    • 然后，通过一次跳转，将 CPU 的控制权交给这段恢复器代码。
    • 在恢复器代码的控制下，进行最后也是最关键的恢复步骤：
      • 精确内存布局: 使用 mremap() 将之前映射在临时地址的内存移动到镜像中记录的最终虚拟地址。使用 mmap() 在正确的位置创建文件映射和共享内存映射。至此，进程的内存布局与 Checkpoint 时完全一致。
      • 填充内存数据: 将镜像文件中保存的内存页数据，通过 read() 或类似方式写回到相应的内存区域。
      • 恢复线程: 在最终的内存布局中，根据保存的状态创建并恢复进程的所有其他线程。
      • 恢复寄存器: 使用 ptrace(PTRACE_SETREGS, …)（或者在恢复器代码内部通过特定机制）将每个线程的 CPU 寄存器（特别是指令指针 IP/PC 和栈指针 SP）精确地设置为 Checkpoint 时保存的值。
      • 恢复其他细节: 恢复定时器、凭证等。
  5. “点火”启动: 当所有状态都恢复完毕，恢复器代码会执行最后一步——通常是一个特殊的返回或跳转指令，将 CPU 的控制权彻底交还给恢复后的进程（主线程）。由于指令指针已经被精确设置，进程会从 Checkpoint 时被中断的那条指令无缝地继续执行，仿佛从未被打断过。
  6. 管理 Restore 流程 (execv 链): 前面提到，CRaC 的 java -XX:CRaCRestoreFrom=… 命令启动后，会通过 criuengine 这个辅助程序来协调 Restore。这个过程涉及多次 execv 调用：初始 Java 命令 execv 变成 criuengine restore，后者再 execv 变成 criu restore 来执行真正的恢复操作。当 criu restore 成功恢复目标 JVM 进程后，它会再次 execv 变成 criuengine restorewait，这个最终的进程负责等待恢复后的 JVM 进程结束，并将 JVM 的退出状态传递回去。

通过这一系列复杂而精密的步骤，结合对 /proc 的读取和对 ptrace 的深度运用，CRIU 实现了在用户空间对运行中进程进行快照和恢复的强大能力，为 CRaC 技术的实现奠定了坚实的基础。

理解了 CRIU 的基本工作原理后，我们就能更好地理解 CRaC 为何还需要一个“协调”层。接下来，我们将探讨 CRaC 的 Resource API 存在的意义。

# CRaC 如何指挥 CRIU

我们已经了解了 CRIU 如何利用 Linux 的底层机制来实现进程的 Checkpoint 和 Restore。但 CRaC (Coordinated Restore at Checkpoint) 本身并不直接执行这些复杂的底层操作。相反，CRaC 更像是一个指挥官，它通过协调 JVM 内部状态和外部资源，并在恰当的时机调用 CRIU 来完成实际的“冻结”与“复苏”工作。这种调用通常是通过一个辅助程序（在 OpenJDK CRaC 实现中称为 criuengine）来间接完成的。这个过程中，Linux 的进程创建、替换和管理技术，特别是 fork、execv 和 double fork，扮演了至关重要的角色。

# Checkpoint 流程中的进程之舞 (double fork)

当用户通过 jcmd <pid> JDK.checkpoint 命令触发 CRaC 的 Checkpoint 时，一场精心编排的进程交互就开始了：

  1. JVM 内部准备: JVM 接收到命令后，会执行一些准备工作，比如触发一次 Full GC 来减小镜像体积，然后进入一个全局安全点（Safepoint），暂停所有 Java 线程。
  2. 启动外部引擎: JVM 调用 fork() 创建一个子进程 (我们称之为 P1)，这个子进程 P1 的任务是执行 criuengine checkpoint 命令。JVM 主进程则会暂停，等待 P1 的某种形式的完成信号或退出。
  3. double fork 登场: 这里的关键在于 criuengine (P1) 如何调用 criu dump 来冻结原始的 JVM 进程。如果 P1 直接调用 criu dump，那么 criu 进程就会是 JVM 的孙子进程，仍然属于同一个进程组，这在某些情况下可能导致问题（比如尝试冻结自己所在的进程组）。为了彻底解耦，criuengine 使用了 double fork 技巧：
    • P1 (criuengine checkpoint) 调用 fork() 创建子进程 P2。然后 P1 会等待 P2 退出。
    • P2 再次调用 fork() 创建孙子进程 P3。
    • P2 立即退出 (exit())。
    • P1 检测到 P2 退出后，P1 也退出。
    • 此时，P3 成为了孤儿进程，其父进程被系统 init 进程（PID 1）接管。P3 现在与原始的 JVM 进程（它的“曾祖父”）在进程树上已经没有直接关系了。
  4. 执行冻结: 成为孤儿的 P3 进程现在可以安全地执行 criu dump -t <jvm_pid> … 命令，目标直指原始的、正在等待的 JVM 进程。criu 利用我们之前讨论的 /proc 和 ptrace 技术，将 JVM 的完整状态保存到镜像文件中。
  5. 终结与等待: criu dump 在成功创建镜像后，通常会杀死 (kill) 被冻结的原始 JVM 进程。而原始 JVM 进程在 fork 出 P1 后，实际上并没有完全阻塞，它会继续执行一小段代码，通常是进入一个 sigwaitinfo() 调用，等待一个特定的信号（RESTORE_SIGNAL），这个信号只有在未来的 Restore 过程中才会被发送。但在此之前，它就被 criu dump 结束了生命。

通过 double fork，CRaC 巧妙地确保了执行冻结操作的 criu 进程独立于被冻结的 JVM 进程树之外，保证了 Checkpoint 操作的干净和可靠。

# Restore 流程中的进程“变身” (execv 链)

Restore 过程则展示了 execv 系统调用的威力，它允许一个进程用一个全新的程序映像替换自己，实现“原地变身”：

  1. 启动 Restore 命令: 用户执行 java -XX:CRaCRestoreFrom=<checkpoint_dir>。
  2. JVM 的“改道”: 这个 Java 命令启动的 JVM 进程（我们称之为 P1）在非常早期的初始化阶段，就会检测到 -XX:CRaCRestoreFrom 参数。它不会继续执行标准的 JVM 启动流程，而是立即“改道”。
  3. 第一次变身 (execv): P1 调用 execv()，将其自身替换为 criuengine restore 程序。此时，原来的 java 进程 P1 不复存在，取而代之的是运行着 criuengine restore 代码的进程（我们称之为 P2，尽管 PID 可能与 P1 相同）。
  4. 第二次变身 (execv): P2 (criuengine restore) 负责解析参数，准备好调用 criu 所需的环境，然后再次调用 execv()，将自身替换为 criu restore 程序（我们称之为 P3）。
  5. CRIU 执行恢复: P3 (criu restore) 读取镜像文件，利用 fork、mmap、ptrace 等技术，在内存中逐步重建 JVM 进程的状态。这个恢复过程可能相当复杂，涉及创建新的进程（恢复后的 JVM），设置内存，恢复文件描述符，恢复线程等。
  6. 唤醒与交接: 在恢复的目标 JVM 进程状态基本就绪，但尚未开始执行用户代码时，P3 (criu restore) 会通过其配置的动作脚本（通常是 criuengine 自身）向恢复后的 JVM 进程发送一个特定的信号（如 RESTORE_SIGNAL），这个信号会唤醒 JVM 内部等待的代码（还记得 Checkpoint 最后 JVM 等待的 sigwaitinfo 吗？恢复后的 JVM 就从这里“醒来”）。
  7. 第三次变身 (execv): 在成功恢复 JVM 并发送唤醒信号后，P3 (criu restore) 进程的任务也即将结束。根据启动时通过 --exec-cmd 参数的指示，它会执行最后一次 execv()，将自身替换为 criuengine restorewait 程序（我们称之为 P4）。
  8. 守望者 (waitpid): P4 (criuengine restorewait) 的唯一使命就是扮演一个“守望者”。它知道刚刚恢复的 JVM 进程的 PID，然后调用 waitpid() 等待这个 JVM 进程结束。当 JVM 最终退出时，P4 会获取其退出状态，并以相同的状态退出。这样，最初启动 java -XX:CRaCRestoreFrom=… 命令的用户就能得到恢复后 JVM 的最终执行结果。

在这个 execv 调用链中，控制权被平滑地从初始的 Java 命令传递给 criuengine，再到 criu 本身，最后交接给负责等待的 criuengine restorewait。整个过程中，进程的身份（执行的程序）不断变化，但通常是在同一个进程 ID 下完成（除了 criu restore 内部重建 JVM 时会创建新进程），高效地利用了现有的进程上下文来执行不同的任务阶段。

总结来说，CRaC 并非魔法，而是建立在对 Linux 进程生命周期管理的深刻理解和巧妙运用之上。它通过辅助程序，精确地编排 fork、execv、waitpid 等系统调用，指挥 CRIU 这位“底层大师”完成复杂的 Checkpoint 和 Restore 操作，最终实现了 Java 应用启动性能的巨大飞跃。

# 总结：Linux 系统编程是 CRaC 的基石

回顾全文，我们一起探索了 CRaC 技术背后所依赖的关键 Linux 系统编程概念。从基本的进程与线程模型、生命周期管理（fork, execv, waitpid, double fork），到强大的进程状态“透视镜” /proc 文件系统，再到能够精细控制进程的“遥控器”ptrace 系统调用，这些都是 Linux 提供的底层能力。

我们看到，CRIU 正是巧妙地组合运用了这些机制，才得以在用户空间实现对运行中进程进行精确 Checkpoint 和 Restore 的复杂操作。而 CRaC 则更进一步，通过协调 JVM 内部状态和外部资源，并指挥 CRIU 完成核心的冻结与复苏任务，最终达成了大幅优化 Java 应用启动性能的目标。

因此，理解这些 Linux 系统编程的知识，不仅能帮助我们揭开 CRaC 实现原理的神秘面纱，更能让我们体会到现代软件技术创新往往是建立在对底层系统深刻理解和创造性应用的基础之上。希望本文能为您打开一扇通往 Linux 系统编程世界的小窗，激发您进一步探索的兴趣。

comments powered by Disqus