介绍:
在Objective-C的开发中循环引用(retain cycle)是指两个（或多个）对象之间产生了互相强引用而导致这些对象因为引用计数(reference count)始终大于等于1而不会释放，最后导致内存泄漏(memory leak)的状况，可以用下图描述。
情况一:delegate
delegate 是iOS中开发中最常遇到的循环引用，一般在声明delegate的时候都要使用弱引用 weak
或者assign
当然怎么选择使用assign还是weak，MRC的话只能用assign，在ARC的情况下最好使用weak，因为
weak修饰的变量在释放后自动指向nil，防止野指针存在
情况二:block
在OC的开发使用块(block)编程因为简便快捷而越来越常见，而使用block时需要注意的一个重点是避免产生循环引用，原因主要在于：
block常常作为delegate的替代方案使用，声明为一个对象（举例命名为BlockObject）的属性时默认为copy策略，即BlockObject会copy并强引用传入的block
block的特性会对其内部引用的所有对象进行一次强引用
那么如果在controller中引入了BlockObject属性并强引用，而在设置其block属性时传入了controller自身，循环引用也就产生了，这种情况下Xcode编译器会提示警告，如下图。
对于block使用产生的循环引用，解决的办法通常是在block外部创建一个weak指针后再传入block内部，这样循环引用就被断开了。
__weak typeof(self) weakSelf =self;
self.blockObject = [[BlockObject alloc] init];
self.blockObject.block= ^(){
[weakSelflog];
};
Cell使用block潜在的循环引用
回到标题说的情况，使用UITableViewCell或者UICollectionViewCell的子类定制cell时，会遇到cell上有个独立的按钮事件需要回调，当使用block来实现这个回调的设计时就会发生一个容易忽略的循环引用，Xcode编译器无法发现这类隐形循环引用，没有警告提醒，如下图没有警告，但循环引用已经产生，当该控制器被pop出去时不会销毁dealloc。
分析其原因在于cell实际是tableView的子视图，每个子视图都是会被其父视图的subviews（NSArray *）属性所强引用，即tableView~>subviews~>cell，而cell因为使用block作为回调强引用了block内部的对象，形成了这样的循环引用链条，即controller~>tableView~>cell~>controller，解决的方法同样是使用弱引用传入block，如下图所示。
__weaktypeof(self) weakSelf =self;
cell.cellBlock = ^(id cell) {
[weakSelf iLog];
};
returncell;
值得注意的是，在这个例子中，即使tableView属性的声明为weak，循环引用仍然会产生，原因在于tableView还是controller的view属性的子视图，强引用链接同样存在，因此最好是在block内部切开强引用链条。
情况三:NSTimer
当你创建使用NSTimer的时候，NSTimer会默认对当前self有个强引用，所以在self使用完成打算
释放的时候，一定要先使用NSTimer的invalidate来停止,释放时间控制对self的引用
[_timer invalidate];
小结
使用block比起使用协议+代理的方式因为可以直接捕获上下文中的变量而简洁方便，但潜在的隐患不能忽视，每次使用block时除了留意编译器的警告外，也要对可能的循环引用进行一番推敲，类似于UITablerHeaderFooterView的 回调 block，以及一些控制器直接/简洁地强引用的对象所持有的 block 处理，都需要保持谨慎。
此外，对于工程内的内存泄漏，Xcode本身提供了检查工具(Leak)，也有第三方的内存泄漏检查工具值得体验。
Tip：一行代码安全调用block
一般调用block调用时都要对其是否为nil进行判断，是处于安全的考虑，如下
if(block) {
block();
}
推荐一个优雅的等效写法
!block ?: block();
