初步swift语言学习笔记6(ARC-自己主动引用计数,内存管理)
Swift使用自己主动引用计数（ARC）来管理应用程序的内存使用。这表示内存管理已经是Swift的一部分，在大多数情况下，你并不须要考虑内存的管理。
当实例并不再被须要时。ARC会自己主动释放这些实例所使用的内存。
另外须要注意的：
引用计数仅仅作用于类实例上。结构和枚举是值类型，而非引用类型。所以不能被引用存储和传递。
swift的ARC工作过程
每当创建一个类的实例。ARC分配一个内存块来存储这个实例的信息，包括了类型信息和实例的属性值信息。
另外当实例不再被使用时，ARC会释放实例所占用的内存，这些内存能够再次被使用。
可是，假设ARC释放了正在被使用的实例，就不能再訪问实例属性。或者调用实例的方法了。直接訪问这个实例可能造成应用程序的崩溃。
就像空实例或游离实例一样。
为了保证须要实例时实例是存在的。ARC对每一个类实例，都追踪有多少属性、常量、变量指向这些实例。当有活动引用指向它时，ARC是不会释放这个实例的。
为实现这点。当你将类实例赋值给属性、常量或变量时。指向实例的一个强引用（strong reference）将会被构造出来。被称为强引用是由于它稳定地持有这个实例，当这个强引用存在时，实例就不能够被自己主动释放，因此能够安全地使用。
样例：
class Teacher
{
var tName : String
init(name:String)
{
tName = name
println("老师 \(tName) 实例初始化完毕.")
}
func getName() -> String
{
return tName
}
func classing()
{
println("老师 \(tName) 正在给学生讲课.")
}
deinit
{
println("老师 \(tName) 实例析构完毕.")
}
}
測试ARC:func testArc()
{
var teacher:Teacher? = Teacher(name:"张三") //实例化一个Teacher对象将指向一个变量，此时产生了一个强引用(就好像OC中的引用计数+1)
var refteacher:Teacher? = teacher //再次产生强引用即(引用计数再+1)
var refteacher2:Teacher? = teacher //再次产生强引用即(引用计数再+1)
refteacher = nil //第一个引用对象为nil并没有使实例释放,(引用计数-1)
teacher?.classing() //正常
teacher = nil //第二个引用对象为nil并没有使实例释放,(引用计数-1)
refteacher2!.classing() //正常
refteacher2 = nil //第三个引用对象为nil此时已没有作何引用了，因此ARC回收，实例释放.(引用计数-1)最后引用计数为0。则自己主动调用析构
refteacher2?.classing() //不再有输出
}
输出结果:
老师 张三 实例初始化完毕. 老师 张三 正在给学生讲课. 老师 张三 正在给学生讲课. 老师 张三 实例析构完毕.
从上面的样例来看，确实swift给我们自己主动管理了内存，非常多时侯开发人员都不须要考虑太多的内存管理。但真的是这样吗？真的安全吗？作为开发人员要怎样用好ARC？
虽然ARC降低了非常多内存管理工作，但ARC并非绝对安全的。以下来看一下循环强引用导至的内存泄漏。
样例：
class Teacher
{
var tName : String
var student : Student? //加入学生对象,初始时为nil
init(name:String)
{
tName = name
println("老师 \(tName) 实例初始化完毕.")
}
func getName() -> String
{
return tName
}
func classing()
{
println("老师 \(tName) 正在给学生 \(student?
.getName()) 讲课.")
}
deinit
{
println("老师 \(tName) 实例析构完毕.")
}
}
class Student
{
var tName : String
var teacher : Teacher? //加入老师对象,初始时为nil
init(name:String)
{
tName = name
println("学生 \(tName) 实例初始化完毕.")
}
func getName() -> String
{
return tName
}
func listening()
{
println("学生 \(tName) 正在听 \(teacher?.getName()) 老师讲的课")
}
deinit
{
println("学生 \(tName) 实例析构化完毕.")
}
}
測试泄漏：
func testMemoryLeak()
{
var teacher :Teacher?
var student :Student?
teacher = Teacher(name:"陈峰") //(引用计数为1)
student = Student(name:"徐鸽") //(引用计数为1)
teacher!.student = student //赋值后将产生"学生"对象的强引用 (引用计数+1)
student!.teacher = teacher //赋值后将产生"老师"对象的强引用 (引用计数+1)
teacher!.classing() //由于我清楚地知道teacher对象不可能为空,所以我用!解包
student!.listening()
//以下的代码。写与不写都不能使对象释放
teacher = nil //引用计数－1 但还不能＝0,所以不会析构
student = nil //引用计数－1 但还不能＝0,所以也不会析构
println("释放后输出")
teacher?.classing() //由于我不能确定teacher对象是否为空，所以必须用?来訪问。
student?.listening()
}
输出结果：
老师 陈峰 实例初始化完毕. 学生 徐鸽 实例初始化完毕. 老师 陈峰 正在给学生 徐鸽 讲课. 学生 徐鸽 正在听 陈峰 老师讲的课 释放后输出
自始至终都没有调用deinit。因此就会泄漏，此时已经不能採取不论什么措拖来释放这两个对象了，仅仅有等APP的生命周期结束
实例之间的相互引用，在日常开发中是非经常见的一种，哪么怎样避免这样的循环强引用导致的内存泄漏呢？
能够通过在类之间定义为弱引用（weak）或无宿主引用的（unowned）变量能够解决强引用循环这个问题
弱引用方式：
弱引用并不保持对所指对象的强烈持有。因此并不阻止ARC对引用实例的回收。这个特性保证了引用不成为强引用循环的一部分。指明引用为弱引用是在生命属性或变量时在其前面加上keywordweak。
注意
弱引用必须声明为变量，指明它们的值在运行期能够改变。
弱引用不能被声明为常量。
由于弱引用能够不含有值，所以必须声明弱引用为可选类型。由于可选类型使得Swift中的不含有值成为可能。
因此仅仅须要将上述的样例随意一个实例变量前加上weak关键词就可以,如：
weak var student : Student?
或
weak var teacher : Teacher?以下来測试一下weak var student : Student?设为弱引用后，測试释放的时间点(情况一)
var teacher :Teacher?var student :Student? teacher = Teacher(name:"陈峰") student = Student(name:"徐鸽") teacher!.student = student //赋值后将产生"学生"对象的强引用 student!.teacher = teacher //赋值后将产生"老师"对象的强引用 teacher!.classing() student!.listening() teacher = nil //此时将没有立即调用析构，要等student释放后才会释放 //student = nil println("释放后输出") teacher?
.classing() //前面已设为nil,所以没有输出 student?.listening()
经測试输出：
老师 陈峰 实例初始化完毕. //运行teacher = Teacher(name:"陈峰")
学生 徐鸽 实例初始化完毕. //运行student = Student(name:"徐鸽")
老师 陈峰 正在给学生 徐鸽 讲课. //运行teacher!.classing()
学生 徐鸽 正在听 陈峰 老师讲的课 //运行student!.listening()
释放后输出 //运行println("释放后输出")
学生 徐鸽 正在听 陈峰 老师讲的课 //运行student?.listening()
学生 徐鸽 实例析构化完毕. //学生对象先释放
老师 陈峰 实例析构完毕. //此时由于学生对象释放了,此时没有了引用，也能够进行析构了假设 weak var teacher : Teacher?
再来进行測试：(情况二)
var teacher :Teacher?
var student :Student?
teacher = Teacher(name:"陈峰")
student = Student(name:"徐鸽")
teacher!.student = student //赋值后将产生"学生"对象的强引用
student!.teacher = teacher //赋值后将产生"老师"对象的强引用
teacher!.classing()
student!.listening()
teacher = nil //此时将没有立即调用析构，要等student释放后才会释放
//student = nil
println("释放后输出")
teacher?.classing()
student?.listening() //此时并不由于
输出结果：老师 陈峰 实例初始化完毕. 学生 徐鸽 实例初始化完毕. 老师 陈峰 正在给学生 徐鸽 讲课. 学生 徐鸽 正在听 陈峰 老师讲的课 老师 陈峰 实例析构完毕. 释放后输出 学生 徐鸽 正在听 nil 老师讲的课 学生 徐鸽 实例析构化完毕.
经測试得出结论：
当Ａ类中包函有Ｂ类的弱引用的实例，同一时候，Ｂ类中存在Ａ的强引用实例时，假设Ａ释放，也不会影响Ｂ的析放。但Ａ的内存回收要等Ｂ的实例释放后才干够回收。（情况一的结果）
当Ａ类中包函有Ｂ类的强引用的实例时，假设Ａ释放，则不会影响Ｂ的析放。（情况二的结果）
和弱引用一样。无宿主引用也并不持有实例的强引用。
但和弱引用不同的是。无宿主引用通常都有一个值。因此。无宿主引用并不定义成可选类型。指明为无宿主引用是在属性或变量声明的时候在之前加上keywordunowned。
由于无宿主引用为非可选类型。所以每当使用无宿主引用时不必使用?
。无宿主引用通常能够直接訪问。可是当无宿主引用所指实例被释放时。ARC并不能将引用值设置为nil。由于非可选类型不能设置为nil。
注意
在无宿主引用指向实例被释放后，假设你想訪问这个无宿主引用，将会触发一个运行期错误（仅当能够确认一个引用一直指向一个实例时才使用无宿主引用）。
在Swift中这样的情况也会造成应用程序的崩溃，会有一些不可预知的行为发生。
因此使用时须要特别小心。
将前面样例改为无宿主引用：
class Teacher
{
var tName : String
var student : Student? //学生对象的强引用,实例能够为nil
init(name:String)
{
tName = name
println("老师 \(tName) 实例初始化完毕.")
}
func getName() -> String
{
return tName
}
func classing()
{
println("老师 \(tName) 正在给学生 \(student?.getName()) 讲课.")
}
deinit
{
println("老师 \(tName) 实例析构完毕.")
}
}
class Student
{
var tName : String
unowned var teacher : Teacher //无宿主引用,不能够设置为nil
init(name:String,tcher :Teacher)
{
tName = name
teacher = tcher //由于无宿主引用不能设为可选型。所在必须要初始化
println("学生 \(tName) 实例初始化完毕.")
}
func getName() -> String
{
return tName
}
func listening()
{
println("学生 \(tName) 正在听 \(teacher.getName()) 老师讲的课")
}
deinit
{
println("学生 \(tName) 实例析构化完毕.")
}
}測试无宿主引用：
func testNotOwner()
{
var teacher :Teacher? //声明可选型变量
teacher = Teacher(name:"陈峰")
var student = Student(name: "徐鸽",tcher: teacher!)
//进行相互引用
teacher!.student = student
student.teacher = teacher!
teacher!.classing()
student.listening()
teacher = nil
println("老师对象释放后")
teacher?.classing()
student.listening() //error 由于在前面的teacher设为nil时,隐式的将student对象给释放了。因此这里再訪问就会crash
}
输出结果：
老师 陈峰 实例初始化完毕. 学生 徐鸽 实例初始化完毕. 老师 陈峰 正在给学生 徐鸽 讲课. 学生 徐鸽 正在听 陈峰 老师讲的课 老师 陈峰 实例析构完毕. 老师对象释放后 Program ended with exit code: 9(lldb) //会crash,thead1:Exc_BREAKPOINT(code=EXC_i386_BPT,subcode=0x0)所以使用无宿主引用时，就须要特别小心。小心别人释放时，顺带释放了强引用对象。所以要想别人释放时不影响到原实例。能够使用弱引用这样就算nil，也不会影响。
上面介绍了，当某个类中的实例对象假设在整个生命周期中，有某个时间可能会被设为nil的实例，使用弱引用，假设整个生命周期中某一实例，一旦构造，过程中不可能再设为nil的实例变量。通常使用无宿主引用。但时有些时侯。在两个类中的相互引用属性都一直有值，而且都不能够被设置为nil。这样的情况下，通常设置一个类的实例为无宿主属性。而另一个类中的实例变量设为的隐式装箱可选属性(即!号属性)
如以下的样例。每位父亲都有孩子(没孩子能叫父亲么？)，每一个孩子都有一个亲生父亲
class Father
{
let children : Children! //声明为隐式可选类型
let fathername : String
init(name:String,childName:String)
{
self.fathername = name
self.children = Children(name: childName,fat:self) //初始化时产生相互引用
}
deinit
{
println("father deinited.")
}
}
class Children
{
unowned let father : Father //声明为无宿主类型
let name : String
init(name:String ,fat : Father)
{
self.name = name
self.father = fat
}
deinit
{
println("children deinited.")
}
}測试代码：
var fa = Father(name: "王五",childName: "王八")
println("\(fa.fathername) 有个小孩叫 \(fa.children.name)")输出结果：
王五 有个小孩叫 王八 father deinited. children deinited.相同能够看到，虽然是循环引用，但还是能正常回收。
另外，另一种情况，当自身的闭包对自身(self) 的强引用，也会导致内存泄漏。
样例：
class CpuFactory
{
let cpuName : String
let cpuRate : Double
init(cpuName:String,rate:Double)
{
self.cpuName = cpuName
self.cpuRate = rate
}
//声明一个闭包
@lazy var someClosure: (Int, String) -> String = {
//以下这句不能够凝视编译器会报Tuple types '(Int,String)'and'()'hava a different number of elements (2 vs. 0)
[unowned self] (index: Int, stringToProcess: String) -> String in
// closure body goes here
return "A \(self.cpuName)" //闭包中引用self
}
//声明一个闭包，相同闭包中引用self
@lazy var machining: () -> String = {
[unowned self] in //这句能够凝视(依照书上说。使用这句能够解释闭包的强引用，但个人实践。无论加不加这句，都不会释放。即这样写有内存泄漏)
// closure body goes here
if self.cpuRate > 10
{
return "\(self.cpuName) i7 2.5G"
}
else
{
return "\(self.cpuName) i3 2.0G"
}
}
//声明一个闭包，但闭包中将自身作为參数传进去(能够避去内存泄漏)
@lazy var machining2 : (CpuFactory) -> String = {
[unowned self] (cpu:CpuFactory) -> String in
if cpu.cpuRate > 10
{
return "\(cpu.cpuName) i7 2.5G"
}
else
{
return "\(cpu.cpuName) i3 2.0G"
}
}
deinit
{
println("Cpu Factroy is deinited.")
}
}
在这个样例中有三个闭包，各自是带參。和不带參，对于带參的 不能省略[unowned self] (paramers) in操作。否则会编译只是。另外。书中没有提到的，仅仅有声明为@lazy的闭包中才干够使用[unowned self] 否则在普通闭包中使用也会报错。
另一点书中讲到当自身闭包中使用self.时会产生强引用。导至内存泄漏，因此加上[unowned self ] in 这句能够破坏这样的强引用，从而使内存得到释放，但经本人亲自验证，就算加上了也没有释放。
測试：
func testClosure()
{
var cpu : CpuFactory? = CpuFactory(cpuName: "Core",rate: 5)
// println(cpu!.machining())
println(cpu!.machining2(cpu!))
// println(cpu!.someClosure(3,"hello"))
cpu = nil
}分别单独验证各句输出结果：func testClosure()
{
var cpu : CpuFactory? = CpuFactory(cpuName: "Core",rate: 5)
println(cpu!.machining())
cpu = nil
}
输出：Core i3 2.0G显然cpu = nil也不会释放内存。
再来看第二个。
func testClosure()
{
var cpu : CpuFactory? = CpuFactory(cpuName: "Core",rate: 5)
println(cpu!.machining2(cpu!))
cpu = nil
}输出Core i3 2.0G Cpu Factroy is deinited.可见使用自身作为參数传參时，能够释放内存。
相同再測试第三种：
func testClosure()
{
var cpu : CpuFactory? = CpuFactory(cpuName: "Core",rate: 5)
println(cpu!.someClosure(3,"hello"))
cpu = nil
}输出A Core事实上第三和第一种是一样的，都是引用了self.但第一种能够把［unowned self ］in 句凝视和不凝视的情况下进行測试，能够发现结果是一样的。并没有释放内存。
实在令人有点费解。。。。。
。
版权声明：本文博主原创文章，博客，未经同意不得转载。
