下列行为都会增加一个app的内存占用：
1、创建一个OC对象；
2、定义一个变量；
3、调用一个函数或者方法。
如果app占用内存过大，系统可能会强制关闭app，造成闪退现象，影响用户体验。如何让回收那些不再使用的对象呢？本文着重介绍OC中的内存管理。
所谓内存管理，就是对内存进行管理，涉及的操作有：
1、分配内存：比如创建一个对象，会增加内存占用；
2、清除内存：比如销毁一个对象，会减少内存占用。
内存管理的管理范围：
1、任何继承了NSObject的对象；
2、对其他非对象类型无效（int、char、float、double、struct、enum等）
只有OC对象才需要进行内存管理的本质原因：
1、OC对象存放于堆里；
2、非OC对象一般放在栈里面（栈内存会被系统自动回收）
系统是如何判断什么时候需要回收一个对象所占用的内存呢？在这里涉及到对象的“引用计数器”的概念。
引用计数器：
每个OC对象都有自己的引用计数器，它是一个整数；每个OC对象内部都有4个字节的存储空间来存放引用计数器。
从字面上看，引用计数器可以理解为“对象被引用的次数”。
简单来说，可以理解为：引用计数器表示有多少人正在使用这个对象。
当没有任何人使用这个对象时，系统才会回收这个对象；也就是说：
1、当对象的引用计数器为0时，对象占用的内存就会被系统回收；
2、如果对象的计数器不为0，那么在整个程序运行过程，它占用的内存就不可能被回收（除非整个程序已经退出）。
任何一个对象，刚生下来的时候，引用计数器都为1；当使用alloc、new或者copy创建一个对象时，对象的引用计数器默认就是1.
要想管理对象占用的内存，就得学会操作对象的引用计数器。
引用计数器的常见操作：
1、给对象发送一条retain消息，可以使引用计数器值+1（retain方法返回对象本身）；
2、给对象发送一条release消息，可以使引用计数器值-1；
3、给对象发送retainCount消息，可以获得当前的引用计数器值。
需要注意的是：release并不代表销毁\回收对象，仅仅是计数器值-1。
当一个对象的引用计数器值为0时：
1、这个对象即将被销毁，其占用的内存被系统回收；
2、系统会自动给对象发送一条dealloc消息（因此，从dealloc方法有没有被调用，就可以判断出对象是否被销毁）。
dealloc方法的重写；
1、一般会重写dealloc方法，在这里释放相关资源，dealloc就是相关的遗言；
2、一旦重写了dealloc方法，就必须调用[super dealloc]，并且放在最后面调用。
使用注意：
1、不能直接调用dealloc方法；
2、一旦对象被回收了，它占用的内存就不再可用，坚持使用会导致程序崩溃（野指针错误）。
野指针\空指针概念：
僵尸对象：已经被销毁的对象（不能再使用的对象）。
野指针：指向僵尸对象的指针；给野指针发消息会报“EXC_BAD_ACCESS”错误。
空指针：没有指向存储空间的指针（里面存的时nil，也就是0）；给空指针发消息是没有任何反应的。
为了避免野指针错误的常见方法是：在对象被销毁后，将指向对象的指针变为空指针。
多对象内存管理规律：
单个对象内存管理比较简单，如果对多个对象进行内存管理，并且对象之间是有联系的，那么管理就会变得比较复杂；总的来说，多对象内存管理有几点规律：
1、只要还有人在用某个对象，那么这个对象就不会被回收；
2、只要你想用这个对象，就让对象的计数器+1；
3、当你不再使用这个对象时，就让对象的计数器-1；
苹果官方规定的内存管理原则：
1、谁创建谁release：如果你通过alloc、new或[mutable]copy来创建一个对象，那么你必须调用调用release或autorrelease。
2、谁retain谁release：只要你调用了retain，就必须调用一次release。
总的来说就是：
1、有加就有减；
2、曾经让对象的计数器+1，就必须在最后让对象计数器-1.
set方法的内存管理如下：
- (void)setCar:(Car *)car
{
if (car != _car)
{
// 对当前正在使用的车（旧车）做一次release
[_car release];
// 对新车做一次retain操作
_car = [car retain];
}
} dealloc方法的内存管理
- (void)dealloc
{
// 当人不在了，代表不用车了
// 对车做一次release操作
[_car release];
[super dealloc];
}下面的代码都会引发内存泄漏：
p.dog = [[Dog alloc] init];
[[Dog alloc] init].weight = 20.8;来源：oschina
链接：https://my.oschina.net/u/1774273/blog/267082