block系列

在 ARC 下，当 block 获取到外部变量时，由于编译器无法预测获取到的变量何时会被突然释放，为了保证程序能够正确运行，让 block 持有获取到的变量，向系统显明：我要用它，你们千万别把它回收了！然而，也正因 block 持有了变量，容易导致变量和 block 的循环引用，造成内存泄露！

对于 block 中的循环引用通常有两种解决方法:

1、将对象置为 nil ，消除引用，打破循环引用；

（这种做法有个很明显的缺点，即开发者必须保证 _networkFetecher = nil; 运行过。若不如此，就无法打破循环引用。

但这种做法的使用场景也很明显，由于 block 的内存必须等待持有它的对象被置为 nil 后才会释放。所以如果开发者希望自己控制 block 对象的生命周期时，就可以使用这种方法。）

2、将强引用转换成弱引用，打破循环引用；

（__weak __typeof(self) weakSelf = self;如果想防止 weakSelf 被释放，可以再次强引用 __typeof(&weakSelf) strongSelf = weakSelf;代码 __typeof(&weakSelf) strongSelf 括号内为什么要加 &* 呢？主要是为了兼容早期的 LLVM

block 的内存泄露问题包括自定义的 block，系统框架的 block 如 GCD 等，都需要注意循环引用的问题。

有个值得一提的细节是，在种类众多的 block 当中，方法名带有 usingBlock 的 Cocoa Framework 方法或 GCD 的 API ，如

- enumerateObjectsUsingBlock:
- sortUsingComparator:

这一类 API 同样会有循环引用的隐患，但原因并非编译器做了保留，而是 API 本身会对传入的 block 做一个复制的操作。

delegate系列

@property (nonatomic, weak) id  delegate;

说白了就是循环使用的问题，假如我们是写的strong,那么 两个类之间调用代理就是这样的啦

BViewController *bViewController = [[BViewController alloc] init];
bViewController.delegate = self; //假设 self 是AViewController
[self.navigationController pushViewController:bViewController animated:YES];

/**
 假如是 strong 的情况
    bViewController.delegate ===> AViewController (也就是 A 的引用计数 + 1)
    AViewController 本身又是引用了  ===> delegate 引用计数 + 1
 导致： AViewController  Delegate ，也就循环引用啦
 */

Delegate创建并强引用了 AViewController；(strong ==> A 强引用、weak ==> 引用计数不变)
所以用 strong的情况下，相当于 Delegate 和 A 两个互相引用啦，A 永远会有一个引用计数 1 不会被释放，所以造成了永远不能被内存释放，因此weak是必须的。

performSelector 系列

performSelector 顾名思义即在运行时执行一个 selector，最简单的方法如下

- (id)performSelector:(SEL)selector;

这种调用 selector 的方法和直接调用 selector 基本等效，执行效果相同

[object methodName];
[object performSelector:@selector(methodName)];

但 performSelector 相比直接调用更加灵活

SEL selector;
if (/* some condition */) {
    selector = @selector(newObject);
} else if (/* some other condition */) {
    selector = @selector(copy);
} else {
    selector = @selector(someProperty);
}
id ret = [object performSelector:selector];

这段代码就相当于在动态之上再动态绑定。在 ARC 下编译这段代码，编译器会发出警告

warning: performSelector may cause a leak because its selector is unknow [-Warc-performSelector-leak]

正是由于动态，编译器不知道即将调用的 selector 是什么，不了解方法签名和返回值，甚至是否有返回值都不懂，所以编译器无法用 ARC 的内存管理规则来判断返回值是否应该释放。因此，ARC 采用了比较谨慎的做法，不添加释放操作，即在方法返回对象时就可能将其持有，从而可能导致内存泄露。

以本段代码为例，前两种情况（newObject, copy）都需要再次释放，而第三种情况不需要。这种泄露隐藏得如此之深，以至于使用 static analyzer 都很难检测到。如果把代码的最后一行改成

    [object performSelector:selector];

不创建一个返回值变量测试分析，简直难以想象这里居然会出现内存问题。所以如果你使用的 selector 有返回值，一定要处理掉。

还有一种情况就是performSelector的延时调用[self performSelector:@selector(method1:) withObject:self.myView afterDelay:5];，performSelector关于内存管理的执行原理是这样的，当执行[self performSelector:@selector(method1:) withObject:self.myView afterDelay:5];的时候，系统将myView的引用计数加1，执行完这个方法之后将myView的引用计数减1，而在延迟调用的过程中很可能就会出现，这个方法被调用了，但是没有执行，此时myView的引用计数并没有减少到0，也就导致了切换场景的dealloc方法没有被调用，这也就引起了内存泄漏。

NSTimer

NSTimer会造成循环引用，timer会强引用target即self，在加入runloop的操作中，又引用了timer，所以在timer被invalidate之前，self也就不会被释放。
所以我们要注意，不仅仅是把timer当作实例变量的时候会造成循环引用，只要申请了timer，加入了runloop，并且target是self，虽然不是循环引用，但是self却没有释放的时机。如下方式申请的定时器，self已经无法释放了。

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

解决这种问题有几个实现方式，大家可以根据具体场景去选择：

增加startTimer和stopTimer方法，在合适的时机去调用，比如可以在viewDidDisappear时stopTimer，或者由这个类的调用者去设置。

每次任务结束时使用dispatch_after方法做延时操作。注意使用weakself，否则也会强引用self。

- (void)startAnimation
{
    WS(weakSelf);
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(5 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
        [weakSelf commentAnimation];
    });
}

使用GCD的定时器，同样注意使用weakself。

WS(weakSelf);
timer = dispatch_source_create(DISPATCH_SOURCE_TYPE_TIMER, 0, 0, dispatch_get_main_queue());
dispatch_source_set_timer(timer, DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC, 1 * NSEC_PER_SEC);
dispatch_source_set_event_handler(timer, ^{
  [weakSelf commentAnimation];
});
dispatch_resume(timer);