26、setjmp/longjmp与内存管理：非局部跳转、清理资源的挑战

说实话，setjmp和longjmp这对组合，在C语言里算是比较冷门的知识点。很多C程序员写了三五年代码，都没碰过它们。但我个人觉得，理解它们对深入掌握C的内存管理很有帮助。说白了，它们提供了一种「非局部跳转」的能力——你可以从一个函数深处，直接跳回到调用链上某个更早的位置。

听起来很强大？确实。但用起来也很危险。尤其是跟动态内存管理搅在一起的时候，稍不留神就会出大问题。

setjmp/longjmp的基本用法

先看个最简单的例子，感受一下它们是怎么工作的：

#include <stdio.h>
#include <setjmp.h>

jmp_buf buf;

void func() {
    printf("进入func\n");
    longjmp(buf, 42);  // 跳回setjmp的位置，返回值是42
    printf("这行不会执行\n");
}

int main() {
    int val = setjmp(buf);
    if (val == 0) {
        printf("第一次执行，val=%d\n", val);
        func();
    } else {
        printf("从longjmp跳回来了，val=%d\n", val);
    }
    return 0;
}

运行结果：

第一次执行，val=0
进入func
从longjmp跳回来了，val=42

嗯，这里要注意：setjmp第一次调用时返回0，之后如果longjmp被触发，它会带着你指定的值（这里是42）再次从setjmp「返回」。这就是非局部跳转的核心机制。

内存管理的噩梦：谁清理资源？

我在项目中遇到过这样一个场景：一个深度嵌套的解析函数，中间可能因为各种格式错误需要提前退出。用longjmp确实方便，但问题来了——中间已经分配的内存怎么办？

看这个例子：

#include <stdio.h>
#include <stdlib.h>
#include <setjmp.h>

jmp_buf buf;

void level2() {
    char *p2 = (char*)malloc(64);
    printf("level2: 分配了内存\n");
    // 出错了，直接跳回
    longjmp(buf, 1);
    free(p2);  // 这行永远不会执行！
    printf("level2: 释放了内存\n");
}

void level1() {
    char *p1 = (char*)malloc(128);
    printf("level1: 分配了内存\n");
    level2();
    free(p1);  // 也不会执行！
    printf("level1: 释放了内存\n");
}

int main() {
    if (setjmp(buf) == 0) {
        level1();
    } else {
        printf("跳回来了，但内存泄漏了！\n");
    }
    return 0;
}

运行结果：

level1: 分配了内存
level2: 分配了内存
跳回来了，但内存泄漏了！

看到了吗？level1和level2里分配的内存全泄漏了。因为longjmp直接跳过了所有free调用。这就是非局部跳转跟内存管理最大的冲突——栈展开时不会自动调用清理代码。

为什么不用goto？

你可能会问：这不就是加强版的goto吗？其实不一样。goto只能在同一个函数内部跳转，而longjmp可以跨函数跳转。它本质上是在操纵调用栈——把栈指针直接恢复到setjmp时的位置。

我个人习惯把longjmp看作「时间机器」：它能把程序的执行状态「回滚」到之前某个时刻。但注意，它只回滚了栈帧和寄存器状态，堆上的数据不会回滚，已经分配的内存也不会自动释放。

清理资源的几种策略

既然longjmp不帮忙清理，那我们就得自己想办法。我在实际项目中用过几种方案，各有优劣。

策略一：跳转前手动清理

最直接的办法——在调用longjmp之前，把当前函数分配的资源都释放掉。

void level2() {
    char *p2 = (char*)malloc(64);
    // ... 出错了
    free(p2);  // 先释放
    longjmp(buf, 1);  // 再跳转
}

这种做法的问题很明显：如果嵌套很深，每一层都要写清理代码，非常容易遗漏。而且如果多个地方都可能触发longjmp，你得在每个出口都加上清理逻辑。

策略二：使用资源链表统一管理

我比较推荐的做法是：维护一个全局的资源链表，把所有分配的内存都注册进去。跳转时统一清理。

#include <stdio.h>
#include <stdlib.h>
#include <setjmp.h>

typedef struct MemNode {
    void *ptr;
    struct MemNode *next;
} MemNode;

MemNode *head = NULL;
jmp_buf buf;

void register_mem(void *ptr) {
    MemNode *node = (MemNode*)malloc(sizeof(MemNode));
    node->ptr = ptr;
    node->next = head;
    head = node;
}

void cleanup_all() {
    while (head) {
        MemNode *tmp = head;
        free(head->ptr);
        head = head->next;
        free(tmp);
    }
}

void level2() {
    char *p2 = (char*)malloc(64);
    register_mem(p2);
    printf("level2: 分配了内存\n");
    longjmp(buf, 1);  // 直接跳，不担心泄漏
}

void level1() {
    char *p1 = (char*)malloc(128);
    register_mem(p1);
    printf("level1: 分配了内存\n");
    level2();
}

int main() {
    if (setjmp(buf) == 0) {
        level1();
    } else {
        cleanup_all();  // 统一清理
        printf("跳回来了，所有内存已释放\n");
    }
    return 0;
}

这种做法把资源管理的责任集中到了一处，代码清晰很多。我曾经在一个嵌入式项目里用过类似方案，处理网络连接和内存池的清理，效果不错。

策略三：避免使用longjmp

嗯，说实话，最稳妥的方案就是——尽量别用。很多场景下，用返回值传递错误码、用状态机、或者用回调函数，都能达到同样的效果，而且更安全。

setjmp/longjmp与栈内存

还有一个容易踩的坑：局部变量的值在longjmp之后可能是不确定的。C标准规定，如果局部变量是volatile的，或者是在setjmp之后被修改的，那么longjmp之后它们的值是不保证的。

jmp_buf buf;

void test() {
    int a = 10;
    volatile int b = 20;
    
    if (setjmp(buf) == 0) {
        a = 100;
        b = 200;
        longjmp(buf, 1);
    } else {
        printf("a = %d (可能不是100)\n", a);
        printf("b = %d (肯定是200)\n", b);
    }
}

为什么会这样？因为longjmp恢复的是setjmp时的栈帧状态。非volatile变量可能被优化到寄存器里，跳转后寄存器的值被恢复，但内存里的值可能已经变了。而volatile变量强制从内存读写，所以行为是确定的。

SVG：setjmp/longjmp与内存管理核心逻辑

实际项目中的避坑指南

我曾经在一个协议栈项目里接手过一段代码，里面用了longjmp做错误处理。代码跑起来没问题，但运行几天后内存就爆了。排查了很久才发现，某个深层函数在longjmp之前分配了一个缓冲区，但没释放。因为那个函数平时很少出错，所以问题一直没暴露。

从那以后，我给自己定了几条规矩：

• 能用返回值就别用longjmp。错误码传递虽然啰嗦，但安全。
• 如果非要用，必须配套资源管理机制。比如我前面说的资源链表。
• 所有在setjmp之后修改的局部变量，都加上volatile。避免未定义行为。
• longjmp的目标位置，最好在main函数或顶层错误处理函数里。不要跳来跳去，增加复杂度。

说白了，setjmp/longjmp是C语言里一把锋利的刀。用好了能解决一些棘手的问题，但稍有不慎就会割伤自己。我个人建议：除非你遇到的情况真的需要跨函数跳转，而且你已经想好了完整的资源清理方案，否则还是老老实实用常规的错误处理方式吧。