不管什么语言，内存管理始终是重中之重，所以Swift也不例外
Swift采用了和Objective - C相同的ARC机制来管理内存，大部分时候内存问题不需要我们关心，基本上做到内存自动管理。基本规则是这样的：当一个对象的引用计数为0的时候，这个对象就会被释放/自动回收。所以在我们编码的过程中如果需要手动释放一个对象，只需要将对象置为nil即可。但是Swift和Objective - C一样，会遇到循环引用(retaincycle)和block导致的内存问题。
关于Objective - C的内存管理，你可以出门左转，看我以前的一篇文章，详细的讲解了OC的内存管理.
什么是循环引用?
先看一段代码:
import UIKit
class A {
let b: B
init() {
b = B()
b.a = self
}
deinit {
print("A is deinited")
}
}
class B {
var a: A? = nil
deinit {
print("B is deinited")
}
}
var test: A? = A()
test = nil
我们把test置为nil以后，上面的两句print应该会被执，然而上面的代码并没有执行。也就是说，test并没有被释放。因为在即使你把test置为nil，而A里面的b还继续持有A，导致无法被释放，造成内存泄露...
那么我们来仔细的分析以下上面的循环引用的关系，在test对象初始化的时候，生成了一个B实例，并存储在b中。然后我们又将A赋值给了b.a。这样a.b和b.a形成了一个循环引用。所以就算你将test置为nil，b仍然持有A，导致无法被释放，并且以后再不会被访问到，除非你杀掉进程,那么如何解决呢 ？
防止循环引用
在Objective - C中使用weak关键修饰可能会引起循环引用的属性，就能打破循环引用。在Swift中同样也有一个weak，也能打破循环引用，所以我们把上面的代码修改成如下代码就能打破循环引用:
class B {
weak var a: A? = nil
deinit {
print("B is deinited")
}
}
这样一来，当test被置为nil的时候，A实例就不再被持有了，那么该实例被释放，紧接着a.b被释放，那么b.a也同样得到释放，所以就可以输出:
A is deinited
B is deinited
在Swift中还有一个unowned, unowned和weak是有区别的，看看官方的解释:
“If the captured reference will never become nil, it should always be captured as an unowned reference, rather than a weak reference.”
很简单的解释：如果该引用不会变成nil,那么你应该使用unowned引用，而不是weak。所以unowned其实有点儿像Objective - C里面的unsafe_unretained。而且这里有一点需要注意:不要使用weak去修饰一个let,因为该引用之后会变，所以只能是var，这一点在官方文档里面也有提示:
“Weak references must be declared as variables, to indicate that their value can change at runtime. A weak reference cannot be declared as a constant.”
上述情况最常见的出现场景就是使用delegate的时候，我们通常会把delegate属性用weak修饰
weak var delegate: TestDelegate
闭包引起的循环引用
在Swift中的闭包(closure)和Objective - C中的block一样，会引起循环引用，从而导致内存泄露。
原因是凡是被闭包或者block所引用，那么闭包和block会自动持有它。这是一个比较隐蔽的陷阱，很多新手会犯这样的错误而不自知。看一段官方的示例代码：
“class HTMLElement {
let name: String
let text: String?
lazy var asHTML: () -> String = {
if let text = self.text {
return "<\(self.name)>\(text)</\(self.name)>"
} else {
return "<\(self.name) />"
}
}
init(name: String, text: String? = nil) {
self.name = name
self.text = text
}
deinit {
print("\(name) is being deinitialized")
}
}”
上面代码的持有关系很明显，HTMLElement持有asHTML属性，而在后面的闭包中有使用了self关键字，那么asHTML又反向持有HTMLElement，这样就形成了循环引用，同样的可以使用weak来打破这个循环引用：
lazy var asHTML: () -> String = {
[weak self] in
if let strongSelf = self { // 这个一定要加
if let text = self.text {
return "<\(self.name)>\(text)</\(self.name)>"
} else {
return "<\(self.name) />"
}
}
}
这里可能很多人会有疑问，可不可以用unowned？为何还要加一个strongSelf判断？我在上一篇的OC内存管理面已经讲过为何要加strongSelf的判断，这里也是差不多一个意思，为了防止提前释放。
如果我们可以确保整个初始化的过程中self，不会被释放掉，那么我们可以放心的时候用unowned，同时也可以去掉strongSelf的判断。如果不能保保证的话，还是老实的使用weak吧，不然会崩的让你各种疼...
到这里就会引出另一个很有意思的问题，那就是是不是所有的闭包都得加上[weak self]？我曾维护过一份蛋疼的代码，那个家伙在所有的block外面都加上了弱引用，也就是但凡遇到block你都能看到这句话，包括系统的各种block:
__weak typdef(self) weakSelf = self;
好吧，你赢了。真的不累么？
其实，如果你能搞清楚，对象间的持有关系，就不会这么干了。有很多block/closure里面不需要加[weak self],所以不要干这么低级的事情
生命不息，折腾不止...
I'm not a real coder,but i love it so much!
