Block Copy 内存布局详解：从栈到堆的底层真相与工程实践

Block 是 Objective-C 里一个看似简单、实则很考功底的概念。日常写代码时，大家基本都把它当成“一段可以捕获变量的匿名函数”来用，但一旦涉及到 Block 的 copy、内存布局、捕获变量这些底层细节，很多人就开始含糊了。尤其是面试的时候，面试官特别喜欢从“Block 存哪里”“copy 之后发生了什么”这类问题一路追问下去。这篇文章我直接基于底层源码和实际调试经验，把 Block Copy 的内存布局这件事彻底讲透，顺便把我在实际工程里踩过的坑也一并放出来。

这篇文章适合三类人看：正在准备 iOS 面试、想深入理解 Block 底层原理的开发者，以及被 Block 循环引用、数组持有 Block 导致异常崩溃折磨过的同学。内容不会太长篇大论讲理论，而是直接对着结构体和拷贝流程逐步拆解，看完你就能自己在 Xcode 里验证。

1. 内容整体设计与思路拆解

1.1 为什么非要盯着 Block 的内存布局看

先抛一个很现实的问题：Block 在被定义、被赋值、被存储、被异步执行这几个环节里，内存位置其实一直在变化。很多人只知道“ARC 下 Block 会自动 copy”，但不知道为什么 copy、什么时候 copy、copy 前后捕获的变量发生了什么变化。这些问题的答案，全部藏在 Block 的内存布局里。

Block 本质上是一个结构体对象，只是它同时还携带了函数指针和捕获的上下文数据。它的内存布局决定了三件事：Block 是什么类型（全局、栈上还是堆上）、Block 捕获了哪些变量、这些变量是值拷贝还是引用拷贝。理解了布局，就相当于拿到了 Block 的解剖图，后面遇到任何诡异问题，都能对着图去定位。

所以这篇文章的整体思路就是：先把 Block 在底层的结构体定义啃下来，再对照三种 Block 类型的差异，最后重点拆解 copy 操作执行时布局发生了什么变化，以及这些变化在实际工程中的影响。

1.2 用一句大白话理解 Block 到底是什么

如果抛开官方定义，我会这样跟你描述 Block：它是一段代码 + 一份“当时的现场记录”。代码就是你要执行的逻辑，现场记录就是在 Block 定义那一刻，它要捕获的那些外部变量的值或引用。这份现场记录，就是通过结构体里的字段保存下来的。

为什么要用结构体而不是单纯的函数指针？因为函数指针只能指向一个确定的函数，但 Block 的执行结果依赖捕获的变量。比如你在循环里定义一个 Block 收集 i 的值，如果 Block 不把 i 保存下来，等循环结束再执行 Block 时，i 早变了。所以 Block 必须在定义时就把 i 的值或引用“冻结”到自己的结构体里，这就是所谓的“捕获”。

理解了这一点，就能明白为什么 Block 的底层结构体里既有 invoke 函数指针，又有保存捕获变量的空间。它们是 Block 这个“特殊对象”的两个核心组成。

2. Block 的底层结构：解剖内存布局的核心骨架

2.1 Block 结构体的标准字段解析

Block 在底层的结构体定义，可以从 Apple 开源代码里找到，我挑最核心的部分讲。Block 的实际结构如下：

c复制struct Block_layout {
    void *isa;           // 指向所属类的指针
    int flags;           // 标志位，记录 Block 类型、是否有签名等
    int reserved;        // 保留字段，暂时没用
    void (*invoke)(void *, ...);  // 函数指针，指向 Block 真正执行的代码
    struct Block_descriptor *descriptor;  // 描述信息，包括 copy/dispose 函数、签名等
    // 捕获的变量从这里开始依次排列
};

这里最值得关注的是 isa 和 descriptor。isa 说明 Block 确实是一个对象，它的类型可能是 _NSConcreteGlobalBlock、_NSConcreteStackBlock 或 _NSConcreteMallocBlock 之一。descriptor 则描述了 Block 的“附加信息”，包括 Block 的大小、可选函数指针 copy/dispose、签名等等。

再往下看，结构体末尾紧跟着的就是捕获的变量。怎么排列？按照捕获顺序依次排下来，每个变量的对齐方式遵循 C 语言的对齐规则。这个区域没有名字，但它在内存里的位置是固定的，可以通过首地址加上固定偏移量来访问。

2.2 descriptor 字段里的隐藏信息

Block_descriptor 本身也值得单独说一下，它有两种形态：基础版和扩展版。基础版是这样：

c复制struct Block_descriptor_1 {
    unsigned long reserved;      // 保留
    unsigned long size;          // Block 结构体的总大小
};

如果有辅助函数（copy/dispose），就会扩展出更多字段：

c复制struct Block_descriptor_2 {
    void (*copy)(void *dst, const void *src);
    void (*dispose)(const void *);
};

如果还要保存方法签名，还会有 Block_descriptor_3。为什么要区分这么多版本？因为 Block 不一定要捕获对象，也不一定要有签名，为了省内存，这些字段只有在 flags 里对应的位被置位时才会真正存在。比如 flags 里有 BLOCK_HAS_COPY_DISPOSE 这个位，才说明 descriptor 后面跟着 copy 和 dispose 函数指针。

这一点在实际调试时特别重要。你如果想用 LLDB 去手动解析一个 Block 的内存，必须看 flags 判断 descriptor 的准确大小，否则读出来全是错的。

2.3 捕获变量在布局里是如何排布的

捕获变量排布是 Block 内存布局里最容易出错的地方。简单说，外部基本类型的自动变量，在 Block 结构体里是值拷贝；对象类型的变量，在 MRC 下是引用拷贝且不持有，在 ARC 下会被 Block 持有（也就是会 retain）；__block 修饰的变量，则会被包装成一个结构体，通过指针来访问。

举个例子，如果有这段代码：

objc复制int a = 10;
__block int b = 20;
NSObject *obj = [[NSObject alloc] init];
void (^block)(void) = ^{
    NSLog(@"%d, %d, %@", a, b, obj);
};

在 Block 结构体里，a 的值 10 会被存进结构体，b 会被存成一个 __block 包装结构体的指针，obj 在 ARC 下会被 Block 持有。这里的关键是：a 的捕获发生在 Block 定义那一刻，之后外部再修改 a，Block 内部是感知不到的；而 b 因为是 __block 包装，Block 内部和外部操作的是同一份内存，所以能看到彼此的修改。

这个排布规则直接决定了 Block 的“抓值”行为，也是后面很多 bug 的根源。

3. 三种 Block 类型与 copy 的目的

3.1 全局 Block、栈 Block、堆 Block 的区别

OC 中 Block 根据内存位置分为三类，对应 isa 指针的不同指向：

全局 Block 好理解，它不依赖任何上下文，所以可以像 C 函数一样直接放在静态区。栈 Block 的生命周期绑定在定义的函数作用域内，一旦函数返回，这块内存就无效了。堆 Block 则是为了解决栈 Block 生命周期问题而存在的，它被拷贝到了堆上，生命周期由引用计数管理。

3.2 为什么栈 Block 必须被 copy 才能安全存储

这个问题是理解 Block copy 的关键。你定义一个 Block 并把它存到属性或者数组里，如果它还在栈上，等当前函数返回，那个 Block 的内存就“悬空”了，后面再调用就属于未定义行为，可能崩溃也可能表现出莫名其妙的行为。

我举个例子，这是非常经典的错误写法：

objc复制- (void)setup {
    int x = 42;
    // 这里的 block 是栈 Block
    void (^block)(void) = ^{
        NSLog(@"%d", x);
    };
    // 存起来，等以后用
    self.savedBlock = block;
}

如果 self.savedBlock 是用 assign 修饰的，或者没有执行 copy，那么 setup 执行完后，block 指向的栈内存已经被回收了。之后再调用 self.savedBlock()，你在控制台会看到随机值甚至直接崩在非法内存访问上。

解决办法就是执行 copy。ARC 下编译器会在合适的时机自动插入 copy，这也是为什么很多人觉得“好像从来不需要手动 copy”。但如果你写的是 MRC，或者写 Core Foundation / C 层面的代码，就必须自己手动 copy。

3.3 copy 后 Block 的 isa 如何转变

栈 Block 执行 copy 之后，它的 isa 会从 _NSConcreteStackBlock 变成 _NSConcreteMallocBlock。这个过程不是简单的标记切换，而是重新分配了一块堆内存，然后把原 Block 的内容整体拷贝过去，再调整 isa 指向。

这里还要注意一个细节：如果对一个堆 Block 再次 copy，并不会再创建一个新 Block。按照 Block 的拷贝规则，堆 Block copy 后返回自身，只是 retainCount 加一。这一点在优化性能时很重要，可以避免无畏的内存分配。全局 Block copy 之后也是返回自身，因为它本身就在静态区，生命周期永远不会结束。

所以你在 ARC 下看到 Block 相关崩溃时，先判断这个 Block 是什么类型。比如一些 C 函数回调里传入的 Block，可能根本没有走 OC 的 ARC 管理，类型还是栈 Block，拷贝时机不对就会出各种问题。

4. copy 执行时的细节：从栈到堆，发生了什么

4.1 copy 函数的调用链路

Block 从栈拷贝到堆，实际执行的是什么？核心是 _Block_copy 这个内部函数。它做的事情大致分三步：

1. 判断 Block 类型，如果是全局 Block 或已经在堆上，就直接返回原对象。
2. 根据 Block 结构体的 size 在堆上分配一块内存。
3. 把原 Block 的数据按位拷贝到新内存，再把 isa 改成 _NSConcreteMallocBlock，最后调用 descriptor 里的 copy 辅助函数，对捕获的对象做一次 retain。

这里最容易忽略的是第三步的“copy 辅助函数”。名字叫 copy，实际上对于捕获的 OC 对象来说，它做的就是 retain 操作。为什么不是深拷贝？因为 Block 捕获的语义是“持有”，不是“复制”。你在 Block 内部拿到那个对象，希望它和外部是同一个对象，并且生命周期被安全延长，所以 retain 就够了。

4.2 __block 变量在 copy 过程中的特殊处理

捕获的自动变量如果用了 __block 修饰，它在 Block 结构体里对应的是一个指向包装结构体的指针。这个包装结构体的布局长这样：

c复制struct Block_byref {
    void *isa;
    struct Block_byref *forwarding;
    int flags;
    int size;
    // 捕获的变量数据
};

forwarding 指针的作用非常关键。栈上的 __block 变量被拷贝到堆上后，原来的栈上包装结构体的 forwarding 指针会指向堆上的新结构体，而堆上结构体的 forwarding 指向自己。这样一来，不管是通过栈上的原变量还是 Block 内部的引用去访问 __block 变量，最终都会访问到堆上的那一份数据，保证读写一致。

这是 Block 设计里非常精妙的一点。它让 __block 变量的生命周期跟随 Block 走，Block 拷贝到堆，__block 变量也跟着上堆；Block 释放，__block 变量也跟着释放。如果忽略了 forwarding 的存在，你很难解释为什么 __block 变量能在不同作用域、不同线程里保持同一份内存。

4.3 拿 LLDB 实测 copy 前后的内存变化

光说不练假把式。我建议你写个小 Demo，在真机或模拟器上打断点验证一下。核心思路是打印 Block 的 isa、类型描述，以及捕获变量的地址。

objc复制int a = 10;
void (^stackBlock)(void) = ^{
    NSLog(@"a is %d", a);
};
NSLog(@"%@", [stackBlock class]);          // 看 isa
NSLog(@"stackBlock: %p", stackBlock);

void (^copiedBlock)(void) = [stackBlock copy];
NSLog(@"%@", [copiedBlock class]);         // 堆 Block
NSLog(@"copiedBlock: %p", copiedBlock);

在 MRC 环境下（或者把 ARC 关掉），你会清楚看到两个 Block 地址不一样，类型从 __NSStackBlock__ 或 __NSStackBlock 变成 __NSMallocBlock__。在 ARC 下，编译器帮你 copy 了，所以打印出来可能直接就是堆 Block。但如果你把 Block 放在函数参数里传递，没有做特殊优化的场景，还是能观察到栈 Block 的存在。

5. 实际工程中的常见问题与避坑经验

5.1 循环引用：Block 持有对象，对象持有 Block

循环引用算是典型的 Block 内存问题。原因其实从内存布局就能推断出来：Block copy 后会持有捕获的 OC 对象（在 ARC 下），如果这个 Block 被对象自身持有，就会形成对象 -> Block -> 对象的强引用环。

解决办法大家都知道用 weak 修饰：

objc复制__weak typeof(self) weakSelf = self;
self.block = ^{
    __strong typeof(weakSelf) strongSelf = weakSelf;
    [strongSelf doSomething];
};

但我想特别提一个容易被忽略的细节：如果你在 Block 里直接访问属性，编译器会隐式捕获 self。哪怕你写的是 _name，只要它来自 self->_name，self 也会被捕获。所以就算你用了 weakSelf，在 Block 内部也不能出现裸的 self 属性访问，否则 weakSelf 白做了。

5.2 栈 Block 逃逸导致崩溃的定位方法

如果你遇到一个随机崩溃，栈回溯里能看到一个函数指针指向一个奇怪的地址，且崩溃前有 Block 被调用，那大概率就是栈 Block 逃逸了。这种问题在低版本 iOS 或 MRC 代码里尤其常见。

一个快速定位技巧：在 Block 执行前打日志输出 _Block_copy 相关调用栈，或者直接通过 class 方法打印当前 Block 的 isa 类型。如果发现一个被保存在属性里的 Block 类型还是 __NSStackBlock__，说明这个 Block 在存储时没有被正确拷贝，ARC 的自动拷贝没有覆盖到这种情况，需要手动 copy。

常见场景包括：C 函数回调里的 Block、GCD 之外的自定义线程调用、将 Block 作为参数传给 C++ 函数等。这些场景不归 ARC 管，Block 的拷贝需要自己负责。

5.3 数组或字典持有 Block 的注意事项

把 Block 存进数组、字典是很多人喜欢用的做法，但这里有一个坑：NSArray 在添加元素时会 retain 对象，但 retain 对栈 Block 无效，因为栈 Block 并不是通过引用计数来管理生命的。如果你把一个栈 Block 放进数组，存储过程中可能没有触发 copy，后面取出来就是野指针。

在 ARC 下，系统会在把 Block 赋值给 id 类型或放入集合时自动复制。但如果你写的是 C 数组、CFArray 等底层结构，就必须自己手动调用 Block_copy 或者执行 [block copy]。这里最容易出问题的反而是在 NSArray 和 NSDictionary 之外的容器实现里。

顺带提一句跨模块传 Block 的问题：如果你的代码同时被 OC 和 C++ 使用，或者通过 C 函数指针传递 Block，尽量避免用裸的 Block 指针传参，而是封装成对象或用 Block_copy 手动管理。否则内存布局正确但生命周期失控，排查起来非常耗时。

5.4 实测案例：一次诡异的“变量值全部变成 0”

我去年处理过一个线上崩溃，用户反馈启动后某个页面随机出现空白数据。定位到最后，是因为一个网络回调 Block 在栈上被存进了全局字典，等请求回来再执行时，Block 捕获的一个字典对象已经释放，Block 内部读到的 count 全是 0。

复现步骤很简单：在 MRC 环境下，把栈 Block 放进一个 CFMutableDictionary，这个容器不会帮 Block 做 copy，Block 在函数返回后栈内存失效。解决方式是在放入之前先执行 Block_copy，用完之后 Block_release。

这个问题之所以难查，是因为它的表现不是崩溃，而是数据错误。如果你将来遇到类似“数据神秘丢失”的问题，先想想有没有哪些 Block 被存进了非 ARC 管理的容器。这往往比查业务逻辑更快。

6. 区块拷贝的延展思考与应用技巧

6.1 如何利用 Block_copy 手动管理生命周期

对于写底层库或与 C/C++ 混编的同学，手动管理 Block 生命周期是基本功。Block 的拷贝和释放对应两个函数：

c复制void *_Block_copy(const void *aBlock);
void _Block_release(const void *aBlock);

Block_copy 返回一个新的堆 Block 指针，使用时需要强转回 Block 类型。Block_release 则负责释放。一个标准的使用流程是这样的：

c复制void (^myBlock)(void) = ^{
    NSLog(@"hello");
};

void (^heapBlock)(void) = (void (^)(void))_Block_copy((__bridge const void *)myBlock);
// 使用 heapBlock
_Block_release((__bridge const void *)heapBlock);

这里的 __bridge 只是为了绕开 ARC 的编译检查。你现在看可能会觉得繁琐，但当你面对一个从 C 层回调上来的 Block，线程生命周期完全不可控时，这一套手动管理就是保命符。

6.2 和 Swift 闭包对比，理解 Block 设计的价值

Swift 的闭包和 OC 的 Block 在高层语义上很像，但底层实现有差异。Swift 闭包捕获变量时也会做类型擦除和堆分配，但编译器有更多优化机会，比如逃逸分析。OC 的 Block 则更多依赖运行时，把内存布局显式暴露出来，因此对开发者来说，反而更容易理解和调试。

我的一个体会是：理解 Block 的底层内存布局，不仅是为了面试，更是为了能在性能调优时做出正确决策。比如你发现某个 Block 被频繁创建和拷贝，就可以想想能不能改成全局 Block，减少堆分配；或者用 __block 变量替代每次都捕获大对象，避免不必要的 retain 和 release。

6.3 后续想深入的话，建议钻研哪些方向

如果你对 Block 的底层还有兴趣，建议按这几个方向继续钻研：

• Block 的方法签名在 runtime 中如何存储和转发（涉及 _Block_descriptor_3）。这在你做方法拦截、动态调用时很有用。
• Block 在 C++ 异常处理和 ObjC++ 场景下的特殊布局。这里涉及异常展开时的拷贝与释放，容易踩坑。
• 从汇编层面阅读 _Block_copy 的实现，理解栈到堆拷贝的具体指令流程。这比较硬核，但对理解整个机制帮助很大。

这几个方向踩坑概率大，但只要啃下来，你对整个 OC 运行时和内存管理机制的认知会上一个台阶。

我个人在实际使用中的体会是：Block 的内存布局最值得反复验证的点，永远是“我捕获了什么、我存储在哪里、生命周期由谁管理”这三件事。每当你写下一个 Block，心里过一遍这三个问题，大部分由 Block 引入的崩溃和诡异行为就都能提前避免。最后再分享一个小技巧：调试 Block 问题时，多用 class 方法确认 Block 类型，再配合 malloc_history 或 Address Sanitizer 定位释放时机，能省下大半天排查时间。