前兩天在Instrument掃到了一處內存泄露，和常見的Block、NSTimer、Target-Action之類循環(huán)引用無關，泄漏的call tree指向了一個屬性的set的位置，在ARC下這種提示還真奇怪。

非常費解，在Demo里簡單還原下事故現場：

@interface ExceptionViewController : BaseViewController
@property (nonatomic, strong) DataModel *dataModel;//包含name屬性的簡單Model
@end

@implementation ExceptionViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    
    [self loadDataModel];
}

- (void)dealloc {
    [self unloadDataModel];
    NSLog(@"Dealloc VC:%@", self);
}

- (void)loadDataModel {
    [self setDataModel:[DataModel new]];
    [self.dataModel addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew context:nil];
}

- (void)unloadDataModel {
    @try {
        [self.dataModel removeObserver:self forKeyPath:@"name"];
    } @catch (NSException *exception) {
        NSLog(@"Exception:%@",exception);
    }
}
@end

Leaks-Leaks by Backtrace內可以看到泄露的是DataModel對象，這頁說明上圖定位的set代碼行正確指出了泄露的對象。
在unloadDataModel內嘗試做如下修改，泄露竟然就消失了：

- (void)unloadDataModel {
    @try {
        [self.dataModel removeObserver:self forKeyPath:@"name"];
    } @catch (NSException *exception) {
        NSLog(@"Exception:%@",exception);
    } @finally {
        [self setDataModel:nil];
    }
}

然而unloadDataModel里為什么有個try-catch？因為有可能拋出NSException異常，那為什么簡單的KVO removeObserver:forKeyPath:會拋出異常？
打斷點在unloadDataModel里跟了一下，發(fā)現在這個ViewController生命周期里，unloadDataModel執(zhí)行了兩次，第二次執(zhí)行必定拋出異常：

Cannot remove an observer <ExceptionViewController 0x7f8b17d1e8b0> for the key path "name" from <DataModel 0x7f8b17f1d380> because it is not registered as an observer

好吧，可能就是NSException的鍋。搜索一番，發(fā)現了這個：

By default in Objective C, ARC is not exception-safe for normal releases:

• It does not end the lifetime of __strong variables when their scopes are abnormally terminated by an exception.
• It does not perform releases which would occur at the end of a full-expression if that full-expression throws an exception.

ARC下發(fā)生了異常，對象的沒有正常走出其作用域，ARC沒能自動添加上release，不保證正常釋放對象的。在上面這種情況，self指代的ExceptionViewController能正常dealloc，而self.dataModel就不能釋放。
另外注意第一條描述的情況，像這樣下面這樣在@try{}里聲明使用的局部變量，也是有泄露隱患的：

正確的姿勢應該是：

- (void)test {
    DataModel *dataModel = [DataModel new];
    NSLog(@"Empty Model:%@", dataModel);
    @try {
        //某些拋出異常的代碼
        @throw [NSException exceptionWithName:@"Exc" reason:@"Test" userInfo:nil];
    } @catch (NSException *exception) {
        NSLog(@"Exception:%@",exception);
    }
}

對了，回到上文，為什么unloadDataModel烏龍地調用了兩次？因為ExceptionViewController的基類BaseViewController的dealloc中，也調用了unloadDataModel：

@implementation BaseViewController
- (void)dealloc {
    [self unloadDataModel];
}
@end

所以這個問題最準確的改法不是在@finally中[self setDataModel:nil]，而是修改邏輯保證unloadDataModel只調用一次。

另外，如果一個類中不得不使用NSException，邏輯又不能梳理清保證盡可能不拋出異常，那還有一個避免內存泄露的方法，在項目的Target-Build Phases中，雙擊該類文件，添加-fobjc-arc-exceptions描述符，當然不建議采用該方法，因為編譯器為了保證此處發(fā)生NSException還能正常釋放內存添加了需要不必要的保護代碼，降低性能。其討論參考Why does “try catch” in Objective-C cause memory leak?

總結：
避免NSException產生內存泄露，需要注意：

• 優(yōu)先考慮使用NSError機制而非NSException機制
• 減少@try{}包裹的代碼范圍
• 不在@try{}內部聲明使用局變量
• 整理代碼邏輯，梳理異常原因，盡量避免NSException的拋出
• 在@finally中做好清理工作，有可能可以避免類似問題
• 使用-fobjc-arc-exceptions標記可能發(fā)出異常造成內存泄露的文件

參考文章：
《Objective-C, ARC and Exceptions》
《Why does “try catch” in Objective-C cause memory leak?》