swift指针&内存管理-引用

i_erlich
489 阅读2分钟

引用探究

首先看一个例子

image.png

那么这个 0x0000000000000003 是什么意思呢

回到swift源码

找到关键核心类型

image.png

HeapObject 就是 swift 分配内存获取到的结构类型

image.png

HeapObject 第一个8字节为 metadata, 接下来是宏

image.png

image.png

InlineRefCounts 其实 就是泛型真正类型 InlineRefCountBits

image.png

image.png

image.png

至此，通过源码，最终找到了 uint64 64位的位信息, 这64位位信息里，存储了当前运行声明周期相关的引用计数

alloc - 引用计数

当swift 创建一个object，引用计数究竟是多少呢

继续回到源码，探索底层原理本身就是枯燥乏味的

image.png

image.png

image.png

image.png

此时，就与上面开始探究的 类型 RefCountBits 关联上了

image.png

根据 RefCountBits(0, 1) 找到 相对应的RefCountBits 构造函数

strongExtracount :: 0

unownedCount:: 1

这几个左移就比较有意思了，出现了 宏拼接参数，需要有点耐心

image.png

image.png

整理一下 StrongExtraRefCountShift = shiftAfterField(IsDeiniting)

define shiftAfterField(name) (name##Shift + name##BitCount)

StrongExtraRefCountShift = IsDeinitingShift + IsDeinitingBitCount

PureSwiftDeallocShift = 0

UnownedRefCountShift = shiftAfterField(PureSwiftDealloc)

UnownedRefCountShift = PureSwiftDeallocShift + PureSwiftDeallocBitCount

UnownedRefCountShift = 1

const size_t IsDeinitingShift = shiftAfterField(UnownedRefCount)

IsDeinitingShift = UnownedRefCountShift + UnownedRefCountBitcount

UnownedRefCountBitCount = 31

IsDeinitingShift = 1 + 31 = 32

IsDeinitingBitCount = 1

StrongExtraRefCountShift = 32 + 1 = 33

最终

StrongExtraRefCountShift = 33

PureSwiftDeallocShift = 0

UnownedRefCountShift = 1

0 << 33 = 0 强引用计数

1 << 0 = 1

1 << 1 = 2 无主引用计数

这样 bit 64位就是 0x0000000000000003, 与开始我们打印的obj1实例内存第二个 8字节存储的内容是一致的

增加实例引用

image.png

在obj1开辟内存创建之后，增加了 obj2 obj3 两个对象对 obj1的引用之后

obj1实例指针 指向的内存空间 第二个8字节中的 高32位 存储了 4

此时就是 两个强引用计数 2 << 33. 就是高32位的4

如果 只增加一个 引用 去掉obj3 的引用，结果就是 1 << 33. 高32位存储 2

image.png

此时， 把obj1变成可选类型，obj1 赋值为nil的时候，实例指针指向的内存空间引用计数的变化如何

image.png

强引用计数 0<< 33 = 0, 高32位显示为0

低位 无主引用为 1<<1 = 2. 加上 1<<0 = 1, 低32位显示为3

此时 obj1 = nil

image.png

32位的1标识此时，obj1正在释放

image.png

源码中查看 强引用计数逻辑

image.png

image.png

image.png

image.png

也就是每增加一次引用， 就在原有计数的基础上 加上 (1<<33)

循环引用

跟OC一样，强引用必然可能造成循环引用的问题

swift 中采用两种方式解决循环引用的问题，弱引用 与 无主引用

由于弱引用不会强持有对实例的引用，所以说实例被释放了，弱引用仍旧引用着这个实例也是有可能的。因此，ARC会在被引用的实例被释放时，自动设置弱引用为nil

由于弱引用需要允许它们的值为nil，所以一定是可选类型

image.png

查看下汇编

image.png

继续查看源码

image.png

weak 修饰的变量，相当于一个 WeakReference 对象

image.png

image.png

其实就是创建了一个sidetable， 本质上与OC ios-弱引用是差不多的

image.png

image.png

image.png

HeapObjectSideTableEntry 结构

image.png

swift中弱引用逻辑

如果当前是强引用，就采用 strong RC + unowned RC + flags， 也就是 强引用 + 无主引用 + flags

如果是弱引用，就是 HeapObjectSideTableEntry结构

而 HeapObjectSideTableEntry 就是 strong RC + unowned RC + weak RC + flags

也就是原64位 强引用信息 + 32位弱引用信息

image.png

image.png

image.png

SideTableRefCounts 与 InlineRefCounts 都是相同的模板

image.png

弱引用之后，存储变化

image.png

0xC00000002040C84E 读取

image.png

62位 63位 为1

回看前面的逻辑

image.png

散列表的存储 >> 3 , 右移了3位

62 63 变0，恢复结果

image.png

然后再左移3位

image.png

最终读取还原后的 散列表地址 0x102064270

image.png

从这个结果上看， 使用弱引用之后， 强引用计数 与 弱引用计数 均存在了散列表里，与OC有着区别

OC里 从StripedMap 结构里拿到 table数组，table数组通过object地址hash 计算table 索引，取得 SideTable

SideTable 里包含两个结构，RefcountMap 与 weak_table

其中 weak_table 存储 弱引用， RefcountMap 只有在 nonpointisa 结构里 强引用计数 超过存储上限之后，折半，把一般存储到 这个 RefcountMap结构里, 当 nonpointisa 结构里 引用计数减为0时， 从 RefcountMap结构里 取出 nonpointisa存储容量上限的一半 到 nonpointisa结构里

而并不想 swift这样， 直接把 无主引用 强引用计数 弱引用计数 全部存储在了 散列表里

avatar
文章
阅读
粉丝