内存对齐探索

本篇探索依旧是基于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、声明成员变量的顺序不一致,会导致最终分配内存大小的不同。

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

你可能感兴趣的:(内存对齐探索)