先来了解一下iOS中的内存布局。

Xnip2018-10-24_22-54-39.png

上面的图代表的是内存区域，最上方是内核区，最下面是保留的内存空间。中间位置是给程序加载使用的空间。程序被加载到内存，会分为三部分。

• 未初始化数据(.bss)，未初始化的静态变量，全局变量等
• 已初始化数据(.data)，已初始化的静态变量，全局变量等
• 代码段(.text)，程序代码就存在这个区域

iOS中定义的一些方法函数都是在栈上进行工作的，栈是从高地址到低地址扩展。而对象，或者是被copy的block都存在于堆中，推是由低地址向高地址扩展的。

栈(satck): 方法调用主要在这个内存区域中进行

堆(heap): 通过alloc等分配的对象存在于这个区域

未初始化数据(.bss): 未初始化的静态变量，全局变量等

已初始化数据(.data): 已初始化的静态变量，全局变量等

代码段(.text): 程序代码存放区域

内存管理方案

在iOS中，内存管理方案分为以下几种：

• TaggedPointer(小对象，如NSNumber等)
• NONPOINTER_ISA(64位架构下的内存管理方案，通常内存中表示地址只需要32-40位即可，多出的区域用来存储其他的数据，以节省内存)
• 散列表
  • 引用计数表
  • 弱引用表
  • ...

NONPOINTER_ISA

在arm64架构下，我们来看看NONPOINTER_ISA所表示的是怎样的结构

Xnip2018-10-25_13-17-37.png Xnip2018-10-25_13-26-10.png

1. 第1位。是一个叫indexed的标志位，如果为0，表示这个isa指针是一个纯的地址指针(保存的都是类对象的地址)。1则表示这个isa指针除去类对象地址外还保存着一些关于内存管理的其他的数据。
2. 第2位。has_assoc,表示当前对象是否有关联对象，0代表没有。
3. 第3位。has_cxx_dtor，代表当前对象是否有使用到C++相关的内容。0表示没有。
4. 第4-35位。shiftcls，这33位都保存着isa所指向的类对象的指针地址。
5. 第36-41位。magic，
6. 第42位。weakly_referenced，用来标识对象是否有相应的弱引用指针。
7. 第43位。deallocating，用来标识对象是否正在被销毁。
8. 第44位。has_sidetable_rc，表示当前isa指针当中存储的引用计数已经达到了上限，则需要外挂一个sidetable(散列表)的数据结构来存储相关的引用计数内容。
9. 第45-63位。extra_rc，存储的就是当前isa指针的引用计数(在引用计数不够大时，会使用这块区域，太大就外挂散列表)。

散列表

下面就来看看SideTables的结构

// 这是一个Hash表
static StripedMap<SideTable>& SideTables() {
    return *reinterpret_cast<StripedMap<SideTable>*>(SideTableBuf);
}

我们可以看到，这下面挂了很多SideTable结构体。

再来看看SideTable里面是什么

struct SideTable {
    spinlock_t slock;   // 自旋锁
    RefcountMap refcnts;    // 引用计数表
    weak_table_t weak_table;    // 弱引用表

    SideTable() {
        memset(&weak_table, 0, sizeof(weak_table));
    }

    ~SideTable() {
        _objc_fatal("Do not delete SideTable.");
    }

    void lock() { slock.lock(); }
    void unlock() { slock.unlock(); }
    void forceReset() { slock.forceReset(); }

    // Address-ordered lock discipline for a pair of side tables.

    template<HaveOld, HaveNew>
    static void lockTwo(SideTable *lock1, SideTable *lock2);
    template<HaveOld, HaveNew>
    static void unlockTwo(SideTable *lock1, SideTable *lock2);
};

先来思考一个问题，为什么要使用SideTables，而不是一个SideTable来表示呢？

如果说，将所有的引用计数，都放在一张大表中，那么我们对某个对象的引用计数进行操作时，会进行加锁的操作。同一时刻只有一个线程可以访问到这个表，这样其他的线程就会造成阻塞。等待持有这个锁的线程释放才可以进行引用计数表的操作。但是，如果说有多张表，就可以一定程度上解决这个问题。而这种解决方案叫做分离锁。也就是将一个大的共享资源，拆分成多个，并分别加锁。

那么，问题又来了，如何实现快速分流(如何快速的通过对象指针找到对象到底是属于哪个SideTable)？

首先，SideTables的本质是一张Hash表。对象指针通过Hash函数的计算，会计算出一个值。来决定对象锁对应的SideTable是哪张。

SideTable

现在我们来剖析一下SideTable的数据结构：

• spinlock_t
• RefcountMap
• weak_table_t

spinlock_t(自旋锁):

• spinlock_t是忙等(如果锁被其他线程获取，当前线程会不断的探测锁是否被释放)的锁
• 适用于轻量访问(简单的计算)

RefcountMap(引用计数表):

这也是一个Hash表，通过指针可以找到对象的引用计数

Xnip2018-10-25_14-34-24.png

这里说明一下为什么用Hash表，Hash表结构的本质，是将数据插入数组时，使用函数计算其位置，取出时也通过这个函数，取得位置，避免了大量的遍历操作，从而提升效率。

size_t

是一个unsign long型的变量。我们再来看看其内存的存储结构：

Xnip2018-10-25_14-38-30.png

第一位代表是否有弱引用。第二位表示当前对象是否在进行销毁。后面的才是引用技术计数值。因此，我们在获取对象的引用计数值的时候，需要向右偏移两位，才可以取得真实的引用计数值。

weak_table_t(弱引用表)

这也是一个Hash表，通过指针可以找到对象在表中的存储位置。

Xnip2018-10-25_14-43-25.png

weak_entry_t是一个结构体数组。其中存储的就是实际的弱引用指针。