iOS底层探索之类的结构—cache分析(下)

作者: 俊而不逊 | 来源:发表于2021-06-27 10:30 被阅读0次

iOS底层探索之类的结构—cache分析(下)
OC底层原理06-cache_t探究
iOS底层探索之类的结构—cache分析(上)
iOS底层探索之类的结构(下)
iOS底层探索之类结构
iOS 底层探索文章汇总
iOS底层之类结构分析
iOS 底层探索：类中方法的举例分析
iOS底层探索之类结构下篇
iOS底层之cache_t探究

在上一篇博客iOS底层探索之类的结构—cache分析(上)中，我们已经对cache的结构有了大致的认识，我们也脱离源码分析，从测试打印的结果来看，_occupied和_maybeMask的值有变化，那么_occupied 和_maybeMask这两个家伙到底和缓存有什么联系？OC底层又是如何进行缓存呢？带着这些疑问，我们就好好去探索探索，分析分析！

在这里插入图片描述

cache_t底层源码分析

insert

在查看源码的时候发现了，cache_t的insert方法，这不就是插入方法的函数吗？

void cache_t::insert(SEL sel, IMP imp, id receiver)

我们进入insert方法内部去看看

insert方法

其中，第一步，根据occupied的值计算出当前的缓存占用量的数量，当属性未赋值及无方法调用时，此时的occupied()为0，newOccupied的值是1

第二部分是if判断，非capacity也就是occupied() = 0时，就是没有方法缓存的时候，capacity的容量赋值为4(INIT_CACHE_SIZE = (1 << INIT_CACHE_SIZE_LOG2))，其中INIT_CACHE_SIZE_LOG2 = 2，意思就是2 左移1位也就变成100，也就是4

 if (slowpath(isConstantEmptyCache())) {
        // Cache is read-only. Replace it.
        if (!capacity) capacity = INIT_CACHE_SIZE;// 4
        reallocate(oldCapacity, capacity, /* freeOld */false);
    }

如果缓存的数量小于等于3/4，则不作任何处理

 else if (fastpath(newOccupied + CACHE_END_MARKER <= cache_fill_ratio(capacity))) {
        // Cache is less than 3/4 or 7/8 full. Use it as-is.
    }

如果缓存占用量超过3/4，则需要进行扩容以及重新开辟空间，新的空间是原来的2倍

#endif
    else {// 4*2 = 8
        capacity = capacity ? capacity * 2 : INIT_CACHE_SIZE;
        if (capacity > MAX_CACHE_SIZE) {
            capacity = MAX_CACHE_SIZE;
        }
        reallocate(oldCapacity, capacity, true);
    }

reallocate

void cache_t::reallocate(mask_t oldCapacity, mask_t newCapacity, bool freeOld)
{
    bucket_t *oldBuckets = buckets();
    bucket_t *newBuckets = allocateBuckets(newCapacity);

    // Cache's old contents are not propagated. 
    // This is thought to save cache memory at the cost of extra cache fills.
    // fixme re-measure this

    ASSERT(newCapacity > 0);
    ASSERT((uintptr_t)(mask_t)(newCapacity-1) == newCapacity-1);

    setBucketsAndMask(newBuckets, newCapacity - 1);
    
    if (freeOld) {
        collect_free(oldBuckets, oldCapacity);
    }
}

第三部分对bucket_t进行操作，bucket里面存的是sel和imp，根据传入的sel和m(capacity - 1)，通过cache_hash哈希方法计算得到一个下标，再进入do-while循环判断

cache_hash

static inline mask_t cache_hash(SEL sel, mask_t mask) 
{
    uintptr_t value = (uintptr_t)sel;
#if CONFIG_USE_PREOPT_CACHES
    value ^= value >> 7;
#endif
    return (mask_t)(value & mask);
}

如果下标的位置未存储sel，即该下标位置sel等于0，将sel和imp存储进去，并将occupied通过incrementOccupied()方法自增加1，

void cache_t::incrementOccupied() 
{
    _occupied++;
}

如果当前位置已经存储了sel则直接返回

if (b[i].sel() == sel) {
            // The entry was added to the cache by some other thread
            // before we grabbed the cacheUpdateLock.
            return;
 }

如果当前位置存储的sel不等于我们要插入的sel，则需要cache_next方法重新进行哈希计算，得到新的下标，再去对比进行存储

while (fastpath((i = cache_next(i, m)) != begin));

哈希冲突

解决哈希冲突，

将当前的哈希下标 +1 & mask，重新进行哈希计算，得到一个新的下标。
如果当前位置已经存在sel，但并不是我们之前缓存的方法，就i-1，往前一个位置插入，如何一直到第一个位置，也就是i-1为0的情况，就直接赋值为mask，从散列表的末端开始往前查找，直到找到合适的位置进行插入

#if CACHE_END_MARKER
static inline mask_t cache_next(mask_t i, mask_t mask) {
    return (i+1) & mask;
}
#elif __arm64__
static inline mask_t cache_next(mask_t i, mask_t mask) {
    return i ? i-1 : mask;
}

到此，cache_t的原理基本分析完成了

总结

在iOS底层探索之类的结构—cache分析(上)中，脱离源码分析的时候，也调用了不同方法进行测试，发现打印的_occupied和_maybeMask的值有变化，刚开始调用两个方法，打印2-3，后来又多调用增加到7个方法，打印4-7，而且打印输出的方法顺序不一样，有的方法还打印了null。

_occupied 表示哈希表中 sel方法的数量 (分配的内存中已经存储了sel方法的个数)
_mask是用于在哈希算法中计算下标用的掩码，其中mask=capacity - 1
cache是方法缓存，是用散列表（哈希表)来缓存曾经调用过的方法，可以提高方法的查找速度
bucket_t其实就是一个散列表，里面存了sel和imp，sel是方法名，作为key ,imp是函数的内存地址
缓存大于3/4就会进行扩容(7个方法大于了第一次给的4)，是以之前的2倍进行扩容，扩容就会清空之前分配的空间，再哈希运算，插入新开辟的空间，用空间换时间，提高查询速度
由于哈希表是无序的，所以扩容后，我们看到有的打印了null(由于扩容后清空了之前缓存的方法，后面的4个方法插入到新扩容的地方，并没有存满，无序存的，就出现了null)，说明该位置没有插入方法