在程序开发中，内存管理是极其重要的一部分。虽然ARC的引入极大的简化了objective-c开发过程中的内存管理工作，但ARC并不是万能的，仍然会存在循环引用、内存泄露等问题。因此，系统的理解内存管理机制还是非常有必要的。
本文先从最基础内存区域划分入手，围绕变量在内存中的生命周期来探讨ios开发中的内存管理问题。
首先来分析一个可执行文件的加载命令。随便找一个ipa包，解压后找到可执行文件，用“otool -lv 二进制文件”来打印加载命令，可以看到segname后面标识的各种段名。不同的段名可以理解为不同的内存区域，一般有以下几种：
__PAGEZERO: 操作系统预留的内存，用来解决空指针问题或捕捉将整数当作指针引用的问题
__TEXT:程序代码段
__DATA:程序数据段
__LLVM:和bitcode机制相关的区域
__LINKEDIT:二进制加载器dyld机制使用的字符串表、符号表等数据
以及：
栈区域：程序运行中存放局部变量、函数实参等数据，由系统维护
堆区域：程序运行中调用alloc生成的对象，由编程人员维护
对于以上区域，其实只有堆区域是由程序员来维护的，其余区域都由系统负责分配和回收。只需要注意不要造成栈溢出，如递归调用的边界条件没有写对等，一般不会有其他的问题。所以最需要留意的内存管理问题，主要是发生在堆区上的。一般常见的问题有空指针、野指针、循环引用问题。由于objective-c的语言特性对空指针问题做了保护，所以其实只需重点关注循环引用和野指针。
在MacOS/iOS系统中，给应用分配的栈和堆区域空间实际都是有限的，并非全部的可用内存。在应用使用的堆内存达到报警阈值后，会通过didReceiveMemoryWarning消息发送给程序，如果不作处理而使应用使用了超过操作系统分配的堆内存，操作系统会直接杀掉该应用。
下面通过一段简单的代码，来说明在程序运行过程中的内存分配和使用：
// 先定义两个类
@class ObjectB;
@interface ObjectA : NSObject
@property (strong, nonatomic, readwrite) ObjectB *b;
@end
@interface ObjectB : NSObject
@property (strong, nonatomic, readwrite) ObjectA *a;
@end
// 内存使用示例代码
- (void)memoryTest {
ObjectA *a = [[ObjectA alloc] init];
ObjectB *b = [[ObjectB alloc] init];
a.b = b;
b.a = a;
}
分析上面代码的执行过程，首先，在程序开始运行后，上面的代码会被加载程序加载到__TEXT代码段中。当memoryTest函数被调用时，从代码段找到这段函数体地址，压入栈中，开始执行这段代码。
在结束的花括号打断点，观察这段代码运行的中间状态值，如下：
(lldb) po a
<ObjectA: 0x60800001e890>
(lldb) po &a
0x00007fff52288ba8
(lldb) po b
<ObjectB: 0x60800001e810>
(lldb) po &b
0x00007fff52288ba0
函数体第一行代码，先在堆0x60800001e890处分配一块内存区域（此次的内存地址是虚拟地址，并非实际地址），大小由ObjectA的类声明确定，然后调用ObjectA的init方法初始化这块内存区域，之后生成局部变量a，即在栈顶0x00007fff52288ba8处压入一个指针，指向0x60800001e890。局部变量a默认设置了__strong属性，所以会持有0x60800001e890这块内存区域，这块内存区域的引用计数加1，从0变成1。注意，引用计数的对象是堆上的内存区域，而不是栈上的局部变量。
同理，执行第二句后，在堆上开辟了ObjectB对象区域，在栈上压入局部变量，并且引用计数加1。
执行第三句，局部变量a指向的内存区域中，有个ObjectB类型的指针，该指针的值设置为了0x60800001e810，在第3行前后设置断点，用memory read命令可以验证这个过程：
// 赋值前
(lldb) memory read 0x60800001e890
0x60800001e890: 88 ff 7b 0c 01 00 00 00 00 00 00 00 00 00 00 00 ..{.............
0x60800001e8a0: 28 03 56 10 01 00 00 00 80 9f 0f 00 00 60 00 00 (.V..........`..
// 赋值后
(lldb) memory read 0x60800001e890
0x60800001e890: 88 ff 7b 0c 01 00 00 00 10 e8 01 00 80 60 00 00 ..{..........`..
0x60800001e8a0: 28 03 56 10 01 00 00 00 80 9f 0f 00 00 60 00 00 (.V..........`..
由于ObjectA的b属性定义为strong类型，所以0x60800001e810堆区域的引用计数加1，变为2。同理，第四行执行过后，堆区域0x60800001e890的引用计数为2。
此时，对象在内存中的状态如下图：
显然，这段代码造成了循环引用。循环引用到底是怎么回事？为什么会造成内存泄露？具体的细节涉及到对象的销毁过程，在下一篇再进行详细解释。
