内存对齐探索

本篇探索依旧是基于objc以及libmalloc源码,源码下载及配置请参考本篇文章

一、对齐原因:

1、平台原因(移植原因):不是所有的硬件平台都能访问任意地址上的任意数据的;某些硬件平台只能在某些地址处取某些特定类型的数据,否则抛出硬件异常。

2、性能原因:数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于,为了访问未对齐的内存,处理器需要作两次内存访问;而对齐的内存访问仅需要一次访问。

(来源百度百科)

二、对齐规则

1、数据成员对齐规则:结构(struct)(或联合(union))的数据成员,第一个数据成员放在offset为0的地方,以后每个数据成员存储的起始位置要从该成员大小或者成员的子成员大小(只要改成员有子成员,比如数组,结构体等)的整数倍开始(比如int为4字节,则要从4的整数倍地址开始存储)。

2、结构体作为成员:如果一个结构里有某些结构体成员,则结构体成员要从其内部最大元素大小的整数倍地址开始存储(struct A里有struct BB里有char,int,double等元素,那B应该从8的整数倍开始存储)。

3、收尾工作:就够提的总大小,也就是sizeof的结果,必须是其内部最大成员的整数倍,不足的要补齐。

4、32位系统下4字节对齐,64位系统下8字节对齐。(本篇例子均默认8字节对齐)

三、结合代码分析

1、结构体中内存对齐分析

struct struct1 {
    int a; // 4 字节
    char b; // 1 字节
    double c; // 8 字节
    int *d; // 8 字节   
}MyStruct1;

struct struct2 {
    int a; // 4 字节 
    int *b; // 8 字节 
    char c; // 1 字节 
    struct struct1 myStruct; // 8字节 
    double d; // 8 字节
} MyStruct2;

1) 内存分析:
括号内为补齐位

  • MyStruct1:
    int a; 0-3 共4字节
    char b; 4 共5字节
    double c; (5,6,7) 8-15 共16字节
    int *d; 16-23 共24字节
    8字节对齐后为24

  • MyStruct2:
    int a; 0-3 共4字节
    int *b (4,5,6,7) 8-15字节 共16字节
    char c 16 字节 共17字节
    struct struct2 myStruct: (17,18,19,20,21,22,23) 24+24 = 47 共48字节
    double d: 48-55 共56字节
    8字节对齐后为56

2、对象及属性中内存对齐分析

Teacher  *p = [Teacher alloc];
p.name = @"TRACER";   //  8
p.age  = 18;            //  4
p.height = 185;         //  8
p.hobby  = @"女";       //  8
// p.sex    = 2;
p.ch1    = 'a';     //  1
p.ch2    = 'b';    //  1

1) 打印属性以及对象分别所占的内存空间。

NSLog(@"%lu",class_getInstanceSize([p class])); // 40
NSLog(@"%lu",malloc_size((__bridge const void *)(p))); // 48

2) 属性内存优化:

① 源码:

// 64位下 WORD_MASK为7,也就是8字节对齐
static inline uint32_t word_align(uint32_t x) {
    // (x + 7) >> 3 << 3
    return (x + WORD_MASK) & ~WORD_MASK;
}

LLDB分析:

(lldb) x/6xg p
0x101044580: 0x001d80010000256d 0x0000001200006261
0x101044590: 0x00000001000020a0 0x00000000000000b9
0x1010445a0: 0x00000001000020c0 0x0000000000000000
(lldb) po 0x0000001200006261
10372493740046155960

(lldb) po 0x00000001000020a0
TRACER

(lldb) po 0x00000000000000b9
185

(lldb) po 0x00000001000020c0
女
  • 第一个即0x001d80010000256disa,先不管它。
  • 我们可以看出agech1以及ch2并没有打印出我们想要的18、a、b,其实这里就是编译器自身帮我们优化的一个过程,那有没有注意到0x0000001200006261打印结果呢?下面我们分开来打印一下看看:
(lldb) po 0x00000012
18
(lldb) po 0x62
98
(lldb) po 0x61
97

97、98感觉不太对?那还记得ASSIC编码吗?

属性以8字节对齐,其中isa固定占8字节,最后一共占40字节

3) 对象内存对齐分析:

上一篇 说到obj = (id)calloc(1, size);进一步的探索需要在libmalloc源码中进行,下面我们来具体看一下。

为什么传入40,会打印出48呢?

void *p = calloc(1, 40);
(lldb) po malloc_size(p)
48
  • 首先来到malloc_zone_calloc方法中,里面有一行至关重要的代码ptr = zone->calloc(zone, num_items, size);初始化并且返回了一个ptr指针,断点在此处打印如下:
(lldb) p zone->calloc
(void *(*)(_malloc_zone_t *, size_t, size_t)) $1 = 0x0000000100381a5f (.dylib`default_zone_calloc at malloc.c:249)
  • 然后来到default_zone_calloc中,会看到return zone->calloc(zone, num_items, size);断点在此处继续打印如下:
(lldb) p zone->calloc
(void *(*)(_malloc_zone_t *, size_t, size_t)) $2 = 0x0000000100383042 (.dylib`nano_calloc at nano_malloc.c:884)
  • 接着来到nano_calloc中,这个方法中核心代码是void *p = _nano_malloc_check_clear(nanozone, total_bytes, 1);,进行内存申请,并且返回指针p

  • _nano_malloc_check_clear 中找到这行size_t slot_bytes = segregated_size_to_fit(nanozone, size, &slot_key);就是对象开启内存大小的算法:

#define SHIFT_NANO_QUANTUM      4
#define NANO_REGIME_QUANTA_SIZE (1 << SHIFT_NANO_QUANTUM)   // 16
static MALLOC_INLINE size_t
segregated_size_to_fit(nanozone_t *nanozone, size_t size, size_t *pKey)
{
    // size = 40
    size_t k, slot_bytes;

    if (0 == size) {
        size = NANO_REGIME_QUANTA_SIZE; // Historical behavior
    }
    // (size + 1<<4 -1) >> 4
    k = (size + NANO_REGIME_QUANTA_SIZE - 1) >> SHIFT_NANO_QUANTUM; // round up and shift for number of quanta
    slot_bytes = k << SHIFT_NANO_QUANTUM;                           
    *pKey = k - 1;                                                  
    return slot_bytes;
}

以上我们可以看出对象是16字节对齐,避免发生内存溢出/野指针的问题。

四、总结

1、属性是以8字节对齐,对象是以16字节对齐。
2、isa本身会占8字节。
3、声明成员变量的顺序不一致,会导致最终分配内存大小的不同。

如有不当,欢迎指正,感谢。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 205,132评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 87,802评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,566评论 0 338
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,858评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,867评论 5 368
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,695评论 1 282
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,064评论 3 399
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,705评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 42,915评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,677评论 2 323
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,796评论 1 333
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,432评论 4 322
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,041评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,992评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,223评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,185评论 2 352
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,535评论 2 343