欢迎访问我的博客原文

内存泄漏指的是程序中已动态分配的堆内存（程序员自己管理的空间）由于某些原因未能释放或无法释放，造成系统内存的浪费，导致程序运行速度变慢甚至系统崩溃。

在 iOS 开发中会遇到的内存泄漏场景可以分为几类：

循环引用

当对象 A 强引用对象 B，而对象 B 又强引用对象 A，或者多个对象互相强引用形成一个闭环，这就是循环引用。

Block

Block 会对其内部的对象强引用，因此使用的时候需要确保不会形成循环引用。

举个例子，看下面这段代码：

self.block = ^{
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@"%@", self.name);
    });
};
self.block();

block 是 self 的属性，因此 self 强引用了 block，而 block 内部又调用了 self，因此 block 也强引用了 self。要解决这个循环引用的问题，有两种思路。

使用 Weak-Strong Dance

先用 __weak 将 self 置为弱引用，打破“循环”关系，但是 weakSelf 在 block 中可能被提前释放，因此还需要在 block 内部，用 __strong 对 weakSelf 进行强引用，这样可以确保 strongSelf 在 block 结束后才会被释放。

__weak typeof(self) weakSelf = self;
self.block = ^{
    __strong typeof(self) strongSelf = weakSelf;
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@"%@", strongSelf.name);
    });
};
self.block();

断开持有关系

使用 __block 关键字设置一个指针 vc 指向 self，重新形成一个 self → block → vc → self 的循环持有链。在调用结束后，将 vc 置为 nil，就能断开循环持有链，从而令 self 正常释放。

__block UIViewController *vc = self;
self.block = ^{
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@"%@", vc.name);
        vc = nil;
    });
};
self.block();

这里还要补充一个问题，为什么要用 __block 修饰 vc？

首先，block 本身不允许修改外部变量的值。但被 __block 修饰的变量会被存在了一个栈的结构体当中，成为结构体指针。当这个对象被 block 持有，就将“外部变量”在栈中的内存地址放到堆中，进而可以在 block 内部修改外部变量的值。

还有一种方式可以断开持有关系。就是将 self 以传参的形式传入 block 内部，这样 self 就不会被 block 持用，也就不会形成循环持有链。

self.block = ^(UIViewController *vc){
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(2 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        NSLog(@"%@", vc.name);
    });
};
self.block(self);

NSTimer

我们知道 NSTimer 对象是采用 target-action 方式创建的，通常 target 就是类本身，而我们为了方便又常把 NSTimer 声明为属性，像这样：

// 第一种创建方式，timer 默认添加进 runloop
self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0f target:self selector:@selector(timeFire) userInfo:nil repeats:YES];
// 第二种创建方式，需要手动将 timer 添加进 runloop
self.timer = [NSTimer timerWithTimeInterval:1.0f target:self selector:@selector(timeFire) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:self.timer forMode:NSRunLoopCommonModes];

这就形成了 self → timer → self(target) 的循环持有链。只要 self 不释放，dealloc 就不会执行，timer 就无法在 dealloc 中销毁，self 始终被强引用，永远得不到释放，循环矛盾，最终造成内存泄漏。

那么如果只把 timer 作为局部变量，而不是属性呢？

NSTimer *timer = [NSTimer timerWithTimeInterval:1.0f target:self selector:@selector(timeFire) userInfo:nil repeats:YES];
[[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];

self 同样释放不了。

因为在加入 runloop 的操作中，timer 被强引用，这就形成了一条 runloop → timer → self(target) 的持有链。而 timer 作为局部变量，无法执行 invalidate，所以在 timer 被销毁之前，self 也不会被释放。

所以只要申请了 timer，加入了 runloop，并且 target 是 self，就算不是循环引用，也会造成内存泄漏，因为 self 没有释放的时机。

解决这个问题有好几种方式，开发者可以自行选择。

在合适的时机销毁 NSTimer

当 NSTimer 初始化之后，加入 runloop 会导致被当前的页面强引用，因此不会执行 dealloc。所以需要在合适的时机销毁 _timer，断开 _timer、runloop 和当前页面之间的强引用关系。

[_timer invalidate];
_timer = nil;

ViewController 中的时机可以选择 didMoveToParentViewController、viewDidDisappear，View 中可以选择 removeFromSuperview 等，但这种方案并一定是正确可行的。

比如在注册页面中加了一个倒计时，如果在 viewDidDisappear 中销毁了 _timer，当用户点击跳转到用户协议页面时，倒计时就会被提前销毁，这是不合逻辑的。因此需要结合具体业务的需求场景来考虑。

使用 GCD 的定时器

GCD 不基于 runloop，可以用 GCD 的计时器代替 NSTimer 实现计时任务。但需要注意的是，GCD 内部 block 中的循环引用问题还是需要解决的。

__weak typeof(self) weakSelf = self;
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
self.timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, queue);
dispatch_source_set_timer(_timer, DISPATCH_TIME_NOW, 1.0 * NSEC_PER_SEC, 0);
dispatch_source_set_event_handler(_timer, ^{
    [weakSelf timeFire];
});
// 开启计时器
dispatch_resume(_timer);
// 销毁计时器
// dispatch_source_cancel(_timer);

借助中介者销毁

中介者指的是用别的对象代替 target 里的 self，中介者绑定 selector 之后，再在 dealloc 中释放 timer。

这里介绍两种中介者，一种是 NSObject 对象，一种是 NSProxy 的子类。它们的存在是为了断开对 self 的强引用，使之可以被释放。

以一个 NSObject 对象作为中介者

新建一个 NSObject 对象 _target，为它动态添加一个方法，方法的地址指向 self 方法列表中的 timeFire 的 IMP。这样 _target 与 self 之间没有直接的引用关系，又能引用 self 里的方法，就不会出现循环引用。

_target = [NSObject new];
class_addMethod([_target class], @selector(timeFire), class_getMethodImplementation([self class], @selector(timeFire)), "v@:");
self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0f target:_target selector:@selector(timeFire) userInfo:nil repeats:YES];

以 NSProxy 的子类作为中介者

创建一个继承自 NSProxy 的子类 WeakProxy，将 timer 的 target 设置为 WeakProxy 实例，利用完整的消息转发机制实现执行 self 中的计时方法，解决循环引用。

// WeakProxy.h
@property (nonatomic, weak, readonly) id weakTarget;

+ (instancetype)proxyWithTarget:(id)target;
- (instancetype)initWithTarget:(id)target;

// WeakProxy.m
@implementation WeakProxy

+ (instancetype)proxyWithTarget:(id)target {
    return [[self alloc] initWithTarget:target];
}

- (instancetype)initWithTarget:(id)target {
    _weakTarget = target;
    return self;
}

- (void)forwardInvocation:(NSInvocation *)invocation {
    SEL sel = [invocation selector];
    if ([self.weakTarget respondsToSelector:sel]) {
        [invocation invokeWithTarget:self.weakTarget];
    }
}

- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    return [self.weakTarget methodSignatureForSelector:sel];
}

- (BOOL)respondsToSelector:(SEL)aSelector {
    return [self.weakTarget respondsToSelector:aSelector];
}
@end

然后这样创建 timer：

self.timer = [NSTimer scheduledTimerWithTimeInterval:1.0f target:[WeakProxy proxyWithTarget:self] selector:@selector(timeFire) userInfo:nil repeats:YES];

这时候的循环持有链是这样的：

由于 WeakProxy 与 self 之间是弱引用关系，self 最终是可以被销毁的。

带 block 的 timer

iOS 10 之后，Apple 提供了一种 block 的方式来解决循环引用的问题。

+ (NSTimer *)timerWithTimeInterval:(NSTimeInterval)interval repeats:(BOOL)repeats block:(void (^)(NSTimer *timer))block API_AVAILABLE(macosx(10.12), ios(10.0), watchos(3.0), tvos(10.0));

为了兼容 iOS 10 之前的方法，可以写成 NSTimer 分类的形式，将 block 作为 SEL 传入初始化方法中，统一以 block 的形式处理回调。

// NSTimer+WeakTimer.m
#import "NSTimer+WeakTimer.h"
 
@implementation NSTimer (WeakTimer)
 
+ (NSTimer *)ht_scheduledTimerWithTimeInterval:(NSTimeInterval)interval
                                       repeats:(BOOL)repeats
                                         block:(void(^)(void))block {
    return [self scheduledTimerWithTimeInterval:interval
                                         target:self
                                       selector:@selector(ht_blockInvoke:)
                                       userInfo:[block copy]
                                        repeats:repeats];
}
 
+ (void)ht_blockInvoke:(NSTimer *)timer {
    void (^block)(void) = timer.userInfo;
    if(block) {
        block();
    }
}

@end

然后在需要的类中创建 timer。

__weak typeof(self) weakSelf = self;
self.timer = [NSTimer ht_scheduledTimerWithTimeInterval:1.0f repeats:YES block:^{
    [weakSelf timeFire];
}];

委托模式

委托模式，是对象之间通信的一种设计模式。该模式的主旨是：定义一套接口，某对象若想接受另一个对象的委托，则需遵从此接口，以便成为其“委托对象”。

UITableView 的 delegate

我们常用的 tableView 与 ViewController 就是委托方和代理方的关系。

需要在控制器中加入列表时，通常我们会将 tableView 设为 ViewController 中 view 的子视图，UIViewController 的源码是这样定义 view 的：

@property(null_resettable, nonatomic, strong) UIView *view;

因此 ViewController 强引用了 tableView。而 tableView 又要委托 ViewController 帮它实现几个代理方法和数据源方法。如果此时 dataSource 和 delegate 属性用 strong 来修饰，就会出现 UITableView 与 ViewController 互相强引用，形成循环引用。

那么看一下 UITableView 的实现源码，我们会发现其中定义 dataSource 和 delegate 属性时是用 weak 修饰的。

@property (nonatomic, weak, nullable) id <UITableViewDataSource> dataSource;
@property (nonatomic, weak, nullable) id <UITableViewDelegate> delegate;

所以 tableView 的 dataSource 和 delegate 只是 weak 指针，指向了 ViewController，它们之间的关系是这样的：

这也就避免了循环引用的发生。

NSURLSession 的 delegate

那么 delegate 一定被 weak 修饰吗？

也不一定，需要看具体的场景。比如 NSURLSession 类中的 delegate 就是用 retain 修饰的。

@property (nullable, readonly, retain) id <NSURLSessionDelegate> delegate;

它这么做，是因为了确保网络请求回调之前，delegate 不被释放。

这也间接引起了 AFNetworking 中循环引用的出现。我们看 AFURLSessionManager 类中声明的 session 是 strong 类型的。

/**
 The managed session.
 */
@property (readonly, nonatomic, strong) NSURLSession *session;

在构造 session 对象时，也将 delegate 设为了 self，也就是 AFURLSessionManager 类。

- (NSURLSession *)session {
    @synchronized (self) {
        if (!_session) {
            _session = [NSURLSession sessionWithConfiguration:self.sessionConfiguration delegate:self delegateQueue:self.operationQueue];
        }
    }
    return _session;
}

如此三者就形成了这样循环持有关系。

要解决这个问题，有两种解决思路：

方式一：将 AFHTTPSessionManager 对象设为单例

对于客户端来说，大多数情况下都是对应同一个后台服务，所以可以将 AFHTTPSessionManager 对象设为单例来处理。

- (AFHTTPSessionManager *)sharedManager {
    static dispatch_once_t onceToken;
    static AFHTTPSessionManager *_manager = nil;
    dispatch_once(&onceToken, ^{
        _manager = [AFHTTPSessionManager manager];
        _manager.requestSerializer = [AFHTTPRequestSerializer serializer];
        _manager.responseSerializer.acceptableContentTypes = [NSSet setWithObjects:@"application/json", @"text/html",@"text/json", @"text/plain", @"text/javascript",@"text/xml", nil];
        _manager.responseSerializer = [AFHTTPResponseSerializer serializer];
    });
    return _manager;
}

如果要设定固定请求头，以这种 key-value 形式加入到 dispatch_once 中。

[_manager.requestSerializer setValue:@"application/json;charset=utf-8" forHTTPHeaderField:@"Content-Type"];

缺点：因为请求的 header 是由 AFHTTPSessionManager的 requestSerializer.mutableHTTPRequestHeaders 字典持有的，所以这种单例模式会导致全局共享一个 header，如果要处理不同自定义 header 的请求就会变得很麻烦。

方式二：在请求结束时，手动销毁 session 对象

由于 session 对象对 delegate 强持有，要打破循环引用，需要在请求结束后手动调用 AFHTTPSessionManager 对象销毁的方法。

- (AFHTTPSessionManager *)getSessionManager{
    AFHTTPSessionManager *manager = [AFHTTPSessionManager manager];
    manager.requestSerializer = [AFHTTPRequestSerializer serializer];
    manager.responseSerializer.acceptableContentTypes = [NSSet setWithObjects:@"application/json", @"text/html",@"text/json", @"text/plain", @"text/javascript",@"text/xml", nil];
    manager.responseSerializer = [AFHTTPResponseSerializer serializer];
    return manager;
}

- (void)sendRequest{
    AFHTTPSessionManager *manager = [self getSessionManager];
    __weak typeof(manager)weakManager = manager;
    [manager GET:@"https://blog.fiteen.top" parameters:nil progress:nil success:^(NSURLSessionDataTask * _Nonnull task, id  _Nullable responseObject) {
         __strong typeof (weakManager)strongManager = weakManager;
        NSLog(@"success 回调");
        [strongManager invalidateSessionCancelingTasks:YES];
    } failure:^(NSURLSessionDataTask * _Nullable task, NSError * _Nonnull error) {
        __strong typeof (weakManager)strongManager = weakManager;
        NSLog(@"error 回调");
        [strongManager invalidateSessionCancelingTasks:YES];
    }];
}

非 OC 对象内存处理

虽然现在已经普及了 ARC 模式，但它仅对 OC 对象进行自动内存管理。对于非 OC 对象，比如 CoreFoundation 框架下的 CI、CG、CF 等开头的类的对象，在使用完毕后仍需我们手动释放。

比如这段获取 UUID 的代码：

CFUUIDRef puuid = CFUUIDCreate( kCFAllocatorDefault );
CFStringRef uuidString = CFUUIDCreateString( kCFAllocatorDefault, puuid );
NSString *uuid = [(NSString *)CFBridgingRelease(CFStringCreateCopy(NULL, uuidString)) uppercaseString];
// 使用完后释放 puuid 和 uuidString 对象
CFRelease(puuid);
CFRelease(uuidString);

还有 C 语言中，如果用 malloc 动态分配内存后，需要用 free 去释放，否则会出现内存泄漏。比如：

person *p = (person *)malloc(sizeof(person));
strcpy(p->name,"fiteen");
p->age = 18;
// 使用完释放内存
free(p);
// 防止野指针
p = NULL;

循环加载引起内存峰值

先看下面这段代码，看似没有内存泄漏的问题，但是在实际运行时，for 循环内部产生了大量的临时对象，会出现 CPU 暴增。

for (int i = 0; i < 1000000; i++) {
    NSString *str = @"Abc";
    str = [str lowercaseString];
    str = [str stringByAppendingString:@"xyz"];
    NSLog(@"%@", str);
}

这是因为循环内产生大量的临时对象，直至循环结束才释放，可能导致内存泄漏。

解决方案：

在循环中创建自己的 autoreleasepool，及时释放占用内存大的临时变量，减少内存占用峰值。

for (int i = 0; i < 100000; i++) {
    @autoreleasepool {
        NSString *str = @"Abc";
        str = [str lowercaseString];
        str = [str stringByAppendingString:@"xyz"];
        NSLog(@"%@", str);
    }
}

在没有手加自动释放池的情况下，autorelease 对象是在当前的 runloop 迭代结束时释放的，而它能够释放的原因是系统在每个 runloop 迭代中都会先销毁并重新创建自动释放池。

下面举个特殊的例子，使用容器 block 版本的枚举器时，内部会自动添加一个自动释放池，比如：

[array enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) {
    // 这里被一个局部 @autoreleasepool 包围着
}];

野指针与僵尸对象

指针指向的对象已经被释放/回收，这个指针就叫做野指针。这个被释放的对象就是僵尸对象。

如果用野指针去访问僵尸对象，或者说向野指针发送消息，会发生 EXC_BAD_ACCESS 崩溃，出现内存泄漏。

// MRC 下
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        Student *stu = [[Student alloc] init];
        [stu setAge:18];
        [stu release];      // stu 在 release 之后，内存空间被释放并回收，stu 变成野指针
        // [stu setAge:20]; // set 再调用 setAge 就会崩溃
    }
    return 0;
}

解决方案：当对象释放后，应该将其置为 nil。

内存泄漏检查工具

Instruments

Instruments 是 Xcode 自带的工具集合，为开发者提供强大的程序性能分析和测试能力。

它打开方式为：Xcode → Open Developer Tool → Instruments。其中的 Allocations、Leaks 和 Zombies 功能可以协助我们进行内存泄漏检查。

Leaks：动态检查泄漏的内存，如果检查过程时出现了红色叉叉，就说明存在内存泄漏，可以定位到泄漏的位置，去解决问题。此外，Xcode 中还提供静态监测方法 Analyze，可以直接通过 Product → Analyze 打开，如果出现泄漏，会出现“蓝色分支图标”提示。
Allocations：用来检查内存使用/分配情况。比如出现“循环加载引起内存峰值”的情况，就可以通过这个工具检查出来。
Zombies：检查是否访问了僵尸对象。

Instruments 的使用相对来说比较复杂，你也可以通过在工程中引入一些第三方框架进行检测。

MLeaksFinder

MLeaksFinder 是 WeRead 团队开源的 iOS 内存泄漏检测工具。

它的使用非常简单，只要在工程引入框架，就可以在 App 运行过程中监测到内存泄漏的对象并立即提醒。MLeaksFinder 也不具备侵入性，使用时无需在 release 版本移除，因为它只会在 debug 版本生效。

不过 MLeaksFinder 的只能定位到内存泄漏的对象，如果你想要检查该对象是否存在循环引用。就结合 FBRetainCycleDetector 一起使用。

FBRetainCycleDetector

FBRetainCycleDetector 是 Facebook 开源的一个循环引用检测工具。它会递归遍历传入内存的 OC 对象的所有强引用的对象，检测以该对象为根结点的强引用树有没有出现循环引用。