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

Posted 卡卡西Sensei

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了iOS底层探索之类的结构—cache分析(下)相关的知识,希望对你有一定的参考价值。

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

在这里插入图片描述

cache_t底层源码分析

insert

在查看源码的时候发现了,cache_tinsert方法,这不就是插入方法的函数吗?

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

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

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

  2. 第二部分是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);
    }
}
  1. 第三部分对bucket_t进行操作,bucket里面存的是selimp,根据传入的selm(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,将selimp存储进去,并将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-10的情况,就直接赋值为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其实就是一个散列表,里面存了selimpsel是方法名,作为key ,imp是函数的内存地址
  • 缓存大于3/4就会进行扩容(7个方法大于了第一次给的4),是以之前的2倍进行扩容,扩容就会清空之前分配的空间,再哈希运算,插入新开辟的空间,用空间换时间,提高查询速度
  • 由于哈希表无序的,所以扩容后,我们看到有的打印了null(由于扩容后清空了之前缓存的方法,后面的4个方法插入到新扩容的地方,并没有存满,无序存的,就出现了null),说明该位置没有插入方法

以上是关于iOS底层探索之类的结构—cache分析(下)的主要内容,如果未能解决你的问题,请参考以下文章

iOS底层探索之Runtime:运行时&方法的本质

iOS开发底层之类的底层Cache_t 探究 - 07

iOS开发底层之类的底层Cache_t 探究 - 07

iOS底层探索之类的结构(上)

iOS底层原理类探索之cache分析

iOS底层探索之类的结构(下)