谈到循环引用，可能是delegate为啥非得用weak修饰，可能是block为啥要被特殊对待，你也可能仅仅想到了一个weakSelf，因为它能解决99%的关于循环引用的事情。下面我以个人的理解谈谈循环引用，读完这篇文章，大约需要15-20分钟的时间。
一、循环引用的产生
当A对象里面强引用了B对象，B对象又强引用了A对象，这样两者的retainCount就一直都无法为0于是内存无法释放，导致内存泄露，所谓的内存泄露，本应该释放的对象，在生命周期结束之后依旧存在。换句话说：得说下内存中和变量有关的分区：堆、栈、静态区。其中，栈和静态区是操作系统自己管理的，对程序员来说相对透明，所以，一般我们只需要关注堆的内存分配，而循环引用的产生，也和其息息相关，即循环引用会导致堆里的内存无法正常回收。如下图：
此处：若想释放内存，需要A的引用计数为0，而B对象持有A，所以想要A dealloc，需要B发送release消息到A。而B只有dealloc的时候才会发送release消息到A，并且B dealloc也需要A发送release消息到B。这样A和B相互等待对方的release消息，造成循环引用，内存无法释放。
二、循环引用的情况
下面我们分析造成循环引用的几种情况：
1.delegate与环
@protocol ClssADelegate
－ (void)eat;
@end
@interface ClassA : UIViewController
@property (nonatomic, strong) id delegate;
@end
//ClassB:
@interface ClassB ()
@property (nonatomic, strong) ClassA *classA;
@end
@implementation ClassB
－ (void)viewDidLoad {
[super viewDidLoad];
self.classA = [[ClassA alloc] init];
self.classA.delegate = self;
}
如上代码，B强引用A，而A的delegate属性指向B，这里的delegate是用strong修饰的，所以A也会强引用B，这是一个比较典型的循环引用样例。所以要将代理delegate改为弱引用weak。
2.block与环
@interface ClassA ()
@property (nonatomic, copy) dispatch_block_t block;
@property (nonatomic, assign) NSInteger tem;
@end
@implementation ClassA
- (void)viewDidLoad {
[super viewDidLoad];
self.block = ^{
self.tem = ;
};
}
如上代码，self持有block，而堆上的block又会持有self，所以会导致循环引用，这个例子非常好，因为xcode都能检测出来，报出警告：[capturing self strongly in this block is likely to lead to a retain cycle]，当然大部分循环引用的情况xcode是不会报警告的。解决这种循环引用的常用方式如下：
@interface ClassA ()
@property (nonatomic, copy) dispatch_block_t block;
@property (nonatomic, assign) NSInteger tem;
@end
@implementation ClassA
- (void)viewDidLoad {
[super viewDidLoad];
__weak typeof(self) weakSelf = self
self.block = ^{
weakSelf.tem = ;
};
}
结论：
如上delegate和block引起的循环引用的处理方式，有一个共同的特点，就是使用weak（弱引用）来打破坏，使环消失了，所以得出结论，我们可以通过将Strong（强引用）用weak来代替来解决循环引用。
>>>>>>>拓展
（1）weakSelf与其缺陷
//ClassB是一个UIViewController，假设从ClassA pushViewController将ClassB展示出来
@interface ClassB ()
@property (nonatomic, copy) dispatch_block_t block;
@property (nonatomic, strong) NSString *str;
@end
@implementation ClassB
－ (void)dealloc {
}
－ (void)viewDidLoad {
[super viewDidLoad];
self.str = @"";
__weak typeof(self) weakSelf = self;
self.block = ^{
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)( * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
NSLog(@"%@", weakSelf.str);
});
};
self.block();
}
这里有两种情况：
（！）若从Apush到B，10s之内没有pop回到A的话，B中block会执行打印出来111.
（！！）若从Apush到B，10s之内pop回A的话（B控制器已经释放掉了），B会立即执行dealloc，从而导致B中block打印出（null），这种情况是使用weakSelf的缺陷，可能会内存被提前释放。
（2）weakSelf和strongSelf
@interface ClassB ()
@property (nonatomic, copy) dispatch_block_t block;
@property (nonatomic, strong) NSString *str;
@end
@implementation ClassB
－ (void)dealloc {
}
－ (void)viewDidLoad {
[super viewDidLoad];
self.str = @"";
__weak typeof(self) weakSelf = self;
self.block = ^{
__strong typeof(self) strongSelf = weakSelf;
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)( * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
NSLog(@"%@", strongSelf.str);
});
};
self.block();
}
这样做解决了上面的问题，但可能有一些问题不是很理解：
（！）这么做和直接用self有什么区别，为什么不会有循环引用；外部的weakSelf是为了打破环，从而没有循环引用，而内部的strongSelf仅仅是个局部变量，存在栈中，会在block执行结束之后回收，不会再造成循环引用。
（！！）这么做和weakSelf有什么区别：唯一的区别就是多了一个strongSelf，这么的strongSelf会使classB的对象引用计数+1，使用ClassB pop到A的时候，并不会执行dealloc，因为计数还不为0，strongSelf仍持有classB，而在block执行完，局部的strongSelf才会回收，此时ClassB dealloc。
这样做其实已经可以解决所有问题，但是强迫症的我们依然能找到它的缺陷：
3、@weakify和@strongify
查看github上开源的libextobjc库，可以发现，里面的EXTScope.h里面有两个关于weak和strong的宏定义。
// 宏定义
#define weakify(...) \
ext_keywordify \
metamacro_foreach_cxt(ext_weakify_,, __weak, __VA_ARGS__)
#define strongify(...) \
ext_keywordify \
_Pragma("clang diagnostic push") \
_Pragma("clang diagnostic ignored \"-Wshadow\"") \
metamacro_foreach(ext_strongify_,, __VA_ARGS__) \
_Pragma("clang diagnostic pop") // 用法
@interface ClassB ()
@property (nonatomic, copy) dispatch_block_t block;
@property (nonatomic, strong) NSString *str;
@end
@implementation ClassB
－ (void)dealloc {
}
－ (void)viewDidLoad {
[super viewDidLoad];
self.str = @"";
@weakify(self)
self.block = ^{
@strongify(self)
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)( * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
NSLog(@"%@", self.str);
});
};
self.block();
}
可以看出，这样就完美的解决了上述的缺陷，我们可以在block随意使用self。
3.NSTimer的循环引用
使用NSTimer可能会碰到循环引用的问题。特别是当类具有NSTimer类型的成员变量，并且需要反复执行计时任务时。例如：
_timer = [NSTimer scheduledTimerWithTimeInterval:5.0
target:self
selector:@selector(startCounting) userInfo:nil
repeats:YES];
类有一个成员变量_timer，给_timer设置的target为这个类本身。这样类保留_timer，_timer又保留了这个类，就会出现循环引用的问题，最后导致类无法正确释放。
解决这个问题的方式也很简单，当类的使用者能够确定不需要使用这个计时器时，就调用
[_timer invalidate];
_timer = nil;
这样就打破了保留环，类也可以正确释放。但是，这种依赖于开发者手动调用方法，才能让内存正确释放的方式不是一个非常好的处理方式。所以需要另外一种解决方案。如下所示：
@interface NSTimer (JQUsingBlock)
+ (NSTimer *)jq_scheduledTimerWithTimeInterval:(NSTimeInterval)ti
block:(void(^)())block
repeats:(BOOL)repeats;
@end @implementation NSTimer (JQUsingBlock) + (NSTimer *)jq_scheduledTimerWithTimeInterval:(NSTimeInterval)ti
block:(void(^)())block
repeats:(BOOL)repeats{ return [self scheduledTimerWithTimeInterval:ti
target:self
selector:@selector(jq_blockInvoke:)
userInfo:[block copy]
repeats:repeats];
} + (void)jq_blockInvoke:(NSTimer *)timer{ void(^block)() = timer.userInfo;
if (block) {
block();
}
} @end
定义一个NSTimer的类别，在类别中定义一个类方法。类方法有一个类型为块的参数（定义的块位于栈上，为了防止块被释放，需要调用copy方法，将块移到堆上）。使用这个类别的方式如下：
__weak ViewController *weakSelf = self;
_timer = [NSTimer jq_scheduledTimerWithTimeInterval:5.0
block:^{
__strong ViewController *strongSelf = weakSelf;
[strongSelf startCounting];
}
repeats:YES];
NSTimer对类的保留，从而打破了循环引用的产生。__strong ViewController *strongSelf = weakSelf主要是为了防止执行块的代码时，类被释放了。在类的dealloc方法中，记得调用[_timer invalidate]。今天先到此为止，改天继续讲解@property与Ivar等区别！！！