内存管理方案（续）

3、散列表 SideTables()

SideTables是一个hash数组，里面存储的是SideTable结构，在非嵌入式系统中，SideTables中有64个SideTable表。

static objc::ExplicitInit<StripedMap<SideTable>> SideTablesMap;

static StripedMap<SideTable>& SideTables() {
    return SideTablesMap.get();
}

StripedMap定义：

template<typename T>
class StripedMap {
#if TARGET_OS_IPHONE && !TARGET_OS_SIMULATOR
    enum { StripeCount = 8 };
#else
    enum { StripeCount = 64 };
#endif

    struct PaddedT {
        T value alignas(CacheLineSize);
    };

    PaddedT array[StripeCount];

    static unsigned int indexForPointer(const void *p) {
        uintptr_t addr = reinterpret_cast<uintptr_t>(p);
        return ((addr >> 4) ^ (addr >> 9)) % StripeCount;
    }

 public:
    T& operator[] (const void *p) { 
        return array[indexForPointer(p)].value; 
    }
    const T& operator[] (const void *p) const { 
        return const_cast<StripedMap<T>>(this)[p]; 
    }

    // Shortcuts for StripedMaps of locks.
    
    // 此处省略锁相关的代码
    
#if DEBUG
    StripedMap() {
        // Verify alignment expectations.
        uintptr_t base = (uintptr_t)&array[0].value;
        uintptr_t delta = (uintptr_t)&array[1].value - base;
        ASSERT(delta % CacheLineSize == 0);
        ASSERT(base % CacheLineSize == 0);
    }
#else
    constexpr StripedMap() {}
#endif
};

SideTables的hash键值是对象的内存地址，把对象的内存地址进行函数处理，就可以找到对象所在的SideTable。

SideTable& table = SideTables()[this];

上述查找的过程采用的是散列函数，通过上述的源码可以看到array[indexForPointer(p)].value取值的时候，下标是indexForPointer函数返回的。

在这个函数的源码中：

将对象的内存地址addr右移4位得到结果1
将对象的内存地址addr右移9位得到结果2
将结果1和结果2做按位异或得到结果3
对结果3和StripeCount做模运算得到真正的hash值。

模运算的结果范围是 0 ~ StripeCount，此处可以看出来SideTables的个数是StripeCount。
这就是通过哈希函数来获取到了SideTable的下标，然后再根据value取到所需的sideTable。

SideTables中多张表是为了多个对象进行引用操作的时候，可以并发操作，当不同对象在不同的表中进行引用计数的时候，各自没有影响，可以提高效率。

延伸问题：为什么不是一个SideTable

如果只有一个SideTable表，我们的引用计数和弱引用都放在一个表中，如果要对某一个引用计数值进行修改，由于所有的对象可能在不同的线程中创建的，在不同线程进行操作，此时需要对表进行加锁，保证数据安全。

如果有很多对象需要进行引用计数修改，都需要操作这张表，此时就会有效率问题。系统为此采用了分离锁的技术方案。

使用了分离锁后，当不同的对象同时进行引用计数时，如果它们存在不同的SideTable表中，则可以对各自的表进行加锁操作，达到并行的效果，提高效率。

SideTable结构

SideTable结构是由自旋锁、引用技术表、弱引用表组成。定义如下：

// NSObject.mm
  struct SideTable {
    spinlock_t slock;
    RefcountMap refcnts;
    weak_table_t weak_table;
    // 省略构造函数、析构函数和其他函数
    // 从析构函数中可以看出SideTable不希望被析构，否则会引起fatal错误
};

1、 spinlock_t(自旋锁)

自旋锁适用于锁使用者保持锁时间比较短的情况。由于锁的事件非常短，所以采用了自旋锁而不是睡眠
自旋锁被称为“盲等”的锁，如果当前锁被占用，则进程不断探索锁，直到锁被释放之后获取锁。
引用计数是加一减一的操作，比较简单迅速，所以采用了自旋锁。

2、RefcountMap()

对象的引用计数存储在这里。

引用技术表是一个以DisguisedPtr<objc_object>为key的hash表，是一个Map。通过hash函数可以找到对象所在的引用计数位置。

此处也是一个哈希查找，这个哈希查找的哈希算法是对传入对象的指针做一个伪装的操作，然后获取对应的引用计数。

此处再明确一下关于哈希查找的过程，之所以使用哈希查找是为了提高查找效率，查找效率的提高源于我们存储一个对象的引用计数是通过这个函数来计算存储位置的，而我们获取对象所代表的的引用计数值的时候也是通过这个函数来计算索引位置，所以插入和获取都是使用同一个函数计算位置的，也就避免了一些循环遍历的操作，所以说用哈希查找可以提高查找效率。

定义如下：

// RefcountMap disguises its pointers because we 
// don't want the table to act as a root for `leaks`.
typedef objc::DenseMap<DisguisedPtr<objc_object>,size_t,RefcountMapValuePurgeable> RefcountMap;

模版类型：objc::DenseMap
参数：

DisguisedPtr<objc_object> ：hash的key值，
size_t：Value
RefcountMapValuePurgeable：是否需要在value=0的时候自动释放响应的hash节点。此处是true。

关于size_t

size_t表达的就是对应对象的引用计数值，实际上它就是一个unsign long型的变量。

size_t的每个byte位代表的含义：
第一位表示的是对象是否有弱引用（weakly_referenced），0代表无，1代表有
第二位表示当前对象是否正在进行dealloc（deallocating）
其他位置存储对象实际的引用计数值。

所以我们在计算对象的引用计数值时，需要对这个值向右偏移2位。（如同源码中定义的宏：SIDE_TABLE_RC_SHIFT 2）

3、weak_table_t()

对象的弱引用数据存储在这里。

weak_table_t的定义如下：

/**
 * The global weak references table. Stores object ids as keys,
 * and weak_entry_t structs as their values.
 */
struct weak_table_t {
    weak_entry_t *weak_entries;
    size_t    num_entries;
    uintptr_t mask;
    uintptr_t max_hash_displacement;
};

weak_table_t也是一张hash表。可以根据key通过hash函数得到弱引用对象（weak_entry_t）。

此处后续再开一章节单独讲解。

附：
参考：
https://www.jianshu.com/p/ab65f8b3e19d
https://blog.csdn.net/Horson19/article/details/82593484
https://juejin.im/post/5d22f34d51882521660ea4f5
https://www.jianshu.com/p/34625a722699

iOS备战之内存管理（二）续

iOS备战之内存管理（二）续

内存管理方案（续）

3、散列表 SideTables()

延伸问题：为什么不是一个SideTable

SideTable结构

关于size_t

iOS备战之内存管理（二）续

内存管理方案（续）

3、散列表 SideTables()

延伸问题： 为什么不是一个SideTable

SideTable结构

关于size_t

延伸问题：为什么不是一个SideTable