objc_class结构体中cache_t分析

前面的文章分析了OC类的结构构体实现，了解了objc_class结构体中有几个主要成员分别是isa、superclass、cache以及bits，今天就来分析一下cache成员的作用，以及如何实现的。

classstruct.png

还是以一个简单的类Person来分析：

@interface Person : NSObject
@property (nonatomic, copy) NSString *lgName;
@property (nonatomic, strong) NSString *nickName;
- (void)sayHello;
- (void)sayCode;
- (void)sayMaster;
- (void)sayXX;
+ (void)sayHappy;
@end

@implementation Person
- (void)sayHello{
    NSLog(@"Person say : %s",__func__);
}
- (void)sayCode{
    NSLog(@"Person say : %s",__func__);
}
- (void)sayMaster{
    NSLog(@"Person say : %s",__func__);
}
- (void)sayXX{
    NSLog(@"Person say : %s",__func__);
}
+ (void)sayHappy{
    NSLog(@"Person say : %s",__func__);
}
@end
//cache_t测试代码
int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // insert code here...
        Person *p  = [Person alloc];
        Class pClass = [Person class];
        [p sayHello];
        [p sayCode];
        [p sayMaster];
        NSLog(@"%@",pClass);
    }
    return 0;
}

在[p sayHello];处打断点，运行后在lldb窗口进行打印调试：

classadress.png

打印出pClass的地址0x0000000100002298，注意这里的pClass是Person类，而不是Person的实例，不要搞混了，既然要分析objc_class结构体中的cache，就要先找到他的源码，首先找到objc_class结构体：

struct objc_class : objc_object {
    // Class ISA;
    Class superclass;
    cache_t cache;             // formerly cache pointer and vtable
    class_data_bits_t bits; 
.......
}

还是用指针偏移的方式，找到cache_t cache;所在的内存位置并打印出来。cache_t cache;之前有两个成员分别是isa和superclass，各占8字节，所以cache_t cache;的位置就是类的首地址偏移16字节，对于十六进制地址0x0000000100002298来说，就是倒数第二位加1，变成0x00000001000022a8，并把类型转换为cache_t类型，打印可以看到：

(lldb) p (cache_t*)0x00000001000022a8
(cache_t *) $1 = 0x00000001000022a8

这样就拿到了cache_t cache;成员的指针，那么想看其内部的内容就要先了解cache_t结构体的实现，找到源码打开看下：

struct cache_t {
#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_OUTLINED
    explicit_atomic<struct bucket_t *> _buckets;
    explicit_atomic<mask_t> _mask;
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16
    explicit_atomic<uintptr_t> _maskAndBuckets;
    mask_t _mask_unused;
   ....省略
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_LOW_4
   ....
    explicit_atomic<uintptr_t> _maskAndBuckets;
    mask_t _mask_unused;
....
#else
#error Unknown cache mask storage type.
#endif
    
#if __LP64__
    uint16_t _flags;
#endif
    uint16_t _occupied;
....
};

已经省略了很多非关键代码，可以看到cache_t的内部是比较复杂的，如何来分析他的内容呢，比较明显的是这里面的几个宏判断：

#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_OUTLINED
....
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_HIGH_16
....
#elif CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_LOW_4
....
#else
#error Unknown cache mask storage type.
#endif

首先要确定我们的调试环境会走入那个分支，这个在我之前分析OC类的isa结构的文章中已经做过分析，这里就不在赘述，结论就是在MAC环境下调试会进入第一个分支，也就是#if CACHE_MASK_STORAGE == CACHE_MASK_STORAGE_OUTLINED，有了这个结论结合源码就可以知道此时我们只关心下面的两个家伙就可以了：

explicit_atomic<struct bucket_t *> _buckets;
explicit_atomic<mask_t> _mask;

这两个家伙看起来也不是什么好对付的，不过他们的声明方式很像泛型都有一个<>来指定具体类型，前面也是相同的explicit_atomic类型，那就点击explicit_atomic看下源码：

template <typename T>
struct explicit_atomic : public std::atomic<T> {
    explicit explicit_atomic(T initial) noexcept : std::atomic<T>(std::move(initial)) {}
    operator T() const = delete;
    
    T load(std::memory_order order) const noexcept {
        return std::atomic<T>::load(order);
    }
    void store(T desired, std::memory_order order) noexcept {
        std::atomic<T>::store(desired, order);
    }
    
    // Convert a normal pointer to an atomic pointer. This is a
    // somewhat dodgy thing to do, but if the atomic type is lock
    // free and the same size as the non-atomic type, we know the
    // representations are the same, and the compiler generates good
    // code.
    static explicit_atomic<T> *from_pointer(T *ptr) {
        static_assert(sizeof(explicit_atomic<T> *) == sizeof(T *),
                      "Size of atomic must match size of original");
        explicit_atomic<T> *atomic = (explicit_atomic<T> *)ptr;
        ASSERT(atomic->is_lock_free());
        return atomic;
    }
};

果然第一行就是template <typename T>，很明显是个泛型声明，这个就是C++的模板，具体的类型还是由<>中的类型决定，除此之外explicit_atomic只是对泛型T进行了方法声明，并没有其他的成员，所以对于整个explicit_atomic<struct bucket_t *> _buckets;来说，我们只关心struct bucket_t * _buckets就可以了，对于explicit_atomic<mask_t> _mask;也可以等价为mask_t _mask来看待。如果实在想弄明白explicit_atomic的作用，这里可以做一个简单的解答，由于struct cache_t结构体顾名思义是一个缓存，对于缓存来说就会有增删改查，而对数据进行增删改查操作就会牵扯到线程安全，而atomic关键字就是线程安全的作用，所以explicit_atomic<T>结构体声明的数据类型代表着他的操作是线程安全的。由于本文的重点是研究cache_t缓存的工作机制，对于explicit_atomic<T>模板泛型是怎么实现的线程安全暂不展开。
下面再来看看另外一个重点分析的对象struct bucket_t * _buckets，看看他的源码：

struct bucket_t {
private:
    // IMP-first is better for arm64e ptrauth and no worse for arm64.
    // SEL-first is better for armv7* and i386 and x86_64.
#if __arm64__
    explicit_atomic<uintptr_t> _imp;
    explicit_atomic<SEL> _sel;
#else
    explicit_atomic<SEL> _sel;
    explicit_atomic<uintptr_t> _imp;
#endif
............
};

同样的道理，这里我们只关心uintptr_t _imp和SEL _sel就好了，而外面套着的explicit_atomic就是起到线程安全的作用，这个宏判断#if __arm64__当然是区分运行环境的，可以看到真机环境和非真机环境只是两个成员的声明顺序不同。bucket本身是桶的意思，代表一个可以存放东西的工具，因此可以得知bucket_t就是存放方法实现_imp和方法编号SEL的地方。说完了bucket_t再回到struct cache_t中看看下一个成员mask_t _mask，mask顾名思义是面具的意思，之前分析isa的时候也有一个ISA_MASK，也就是掩码，再往下跳出宏判断还有两个需要关注的成员，一个是uint16_t _flags;，另外一个是uint16_t _occupied;，这些成员就是我们分析cache_t缓存机制时需要重点分析的内容：

dijinfenxi.png

上图就清晰的展示了我们的分析路径，到这里我们对cache_t就有了一个宏观的认识，知道他的作用是缓存，缓存中存储的就是方法编号SEL和方法实现_imp，分析到此，我们是否能通过lldb打印出一个类的cache_t内容，看看它内部是否真的如我们所分析的那样，还记得上面通过Person类的首地址偏移打印出了Person类的cache_t指针，下面就继续追踪，看看能否直接获取到cache_t的内容：

//打印出cache_t的指针
(lldb) p (cache_t*)0x00000001000022a8
(cache_t *) $1 = 0x00000001000022a8
//打印cache_t指针内容
(lldb) p *$1
(cache_t) $2 = {
  _buckets = {
    std::__1::atomic<bucket_t *> = 0x000000010032e410 {
      _sel = {
        std::__1::atomic<objc_selector *> = (null)
      }
      _imp = {
        std::__1::atomic<unsigned long> = 0
      }
    }
  }
  _mask = {
    std::__1::atomic<unsigned int> = 0
  }
  _flags = 32804
  _occupied = 0
}
(lldb)

可以看到，直接p *$1，也就是cache_t的指针，可以直接打印出cache_t的内容，可以清晰的看到里面有_buckets，它的内部还有_sel和_imp，还有_mask、_flags以及_occupied，下面就要有一些处理，看看最开始的代码，还记得最初的断点是在[p sayHello];这里，下面就让[p sayHello];这里的断点过一下，按照上面的方法在打印一次看看结果是否相同：

aftermethod.png

可以看到执行了sayHello方法后再次打印cache_t，其内容已经不同。由此可以推断，由于执行了方法，所以cache_t里面就会缓存这个方法，导致打印结果有变化，如果能打印出cache_t中缓存的sayHello方法，就能证明这个推断是对的，下面通过打印来证明这个推断：
cannotprint.png
可以看到上面打印了*$4也就是cache_t的_buckets成员内容，但是却打印出了一串乱码，在试试p $4._sel能否打印出缓存的sayHello方法，结果也没有，后面尝试了p $4->_sel和p $4.sel()都失败了，此时只能求助源码看看能否通过_buckets获取到缓存的方法名称和实现，再看cache_t的源码：

struct cache_t {
...........
public:
    static bucket_t *emptyBuckets();
    struct bucket_t *buckets();
..........
}

在public方法声明中，有一个buckets()方法，返回bucket_t *类型，就来试试它能否拿到我们需要的_buckets成员：

buckets.png

可以看到，打印p $5.buckets()就能拿到$6，也就是bucket_t *的指针，接着打印p *$6，就得到了真正的bucket_t结构体的内容，存放在$7中，接着打印了p $7._sel没有得到想要的结果，再看bucket_t结构体的源码，可以找到其中有个sel()方法：

struct bucket_t {
.............
public:
    inline SEL sel() const { return _sel.load(memory_order::memory_order_relaxed); }
    inline IMP imp(Class cls) const{
.............
}

接着打印p $7.sel()就拿到了方法名称sayHello，再来试试打印imp(Class cls)方法：

impl.png

可以看到第一次打印了p $7.impl()并没有打印出记过，是因为imp(Class cls)中有个参数Class cls，后面把参数pClass带入进去，打印结果就是[Person sayHello]方法了。最后还可以通过MachOView查看二进制文件中的方法地址和这里打印的是一致的，都是0x0000000100000c00：
machoview.png

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,271评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,275评论 2赞 380
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,151评论 0赞 336
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,550评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,553评论 5赞 365
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,559评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,924评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,580评论 0赞 257
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,826评论 1赞 297
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2赞 320
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,363评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,940评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2赞 342