聊聊iOS OC 对象的内存对齐原则

移动开发 iOS
经过各种分析,我们可以得到的结论是 instanceSize 是以 8 字节进行对齐的, 后面 calloc 是以 16 字节进行对齐的,说明 calloc 进一步对对象进行了处理。也就解释了我们打印出来的 40-48 了。

[[409899]]

本文转载自微信公众号「网罗开发」,作者just东东。转载本文请联系网罗开发公众号。

问题的引入

初始化一个 OC 类,具有如下属性:

  1. #import <Foundation/Foundation.h> 
  2.  
  3. NS_ASSUME_NONNULL_BEGIN 
  4.  
  5. @interface LGTeacher : NSObject 
  6. @property (nonatomic, copy) NSString *name
  7. @property (nonatomic, assign) int age; 
  8. @property (nonatomic, assign) long height; 
  9. @property (nonatomic, strong) NSString *hobby; 
  10.  
  11. @end 
  12.  
  13. NS_ASSUME_NONNULL_END 

初始化对象,并获取对象的内存 size:

  1. LGTeacher  *p = [[LGTeacher alloc] init]; 
  2. p.name = @"LG_Cooci"
  3. p.age  = 18; 
  4. p.height = 185; 
  5. p.hobby  = @"女"
  6.  
  7. NSLog(@"%lu - %lu",class_getInstanceSize([p class]),malloc_size((__bridge const void *)(p))); 

打印结果:

由以上打印结果可以看出 class_getInstanceSize 和 malloc_size 获取到的内存大小不一样,那么是什么导致的两者获取同一对象的内存大小不一样呢?我们下一步继续探索。

首先我们先手动计算一下这个对象所占的内存:

  • isa -- 8字节
  • name -- 8字节
  • age -- 4字节
  • height -- 8字节
  • hobby -- 8字节
  • 总计 36 字节。

我们跟踪 objc 源码可以发现改变 size 的地方有两个地方:

  • instanceSize 继续跟踪

1.instanceSize

  1. size_t instanceSize(size_t extraBytes) const { 
  2.         if (fastpath(cache.hasFastInstanceSize(extraBytes))) { 
  3.             return cache.fastInstanceSize(extraBytes); 
  4.         } 
  5.  
  6.         size_t size = alignedInstanceSize() + extraBytes;// alignedInstanceSize 
  7.         // CF requires all objects be at least 16 bytes. 
  8.         if (size < 16) size = 16; 
  9.         return size
  10.  
  11. uint32_t alignedInstanceSize() const { 
  12.         return word_align(unalignedInstanceSize()); 
  13.  
  14. #   define WORD_MASK 7UL 
  15. static inline uint32_t word_align(uint32_t x) { 
  16.     return (x + WORD_MASK) & ~WORD_MASK; 

由以上源码可以得到 instanceSize 使用 8 字节对齐原则处理 Size,并且最小为 16 字节。

2.calloc

由于 calloc 属于 malloc 源码里面

跟踪 libmalloc 源码:

calloc 源码实现:

  1. void * 
  2. calloc(size_t num_items, size_t size
  3.     void *retval; 
  4.     retval = malloc_zone_calloc(default_zone, num_items, size); 
  5.     if (retval == NULL) { 
  6.         errno = ENOMEM; 
  7.     } 
  8.     return retval; 
  9.  
  10. // malloc_zone_calloc 
  11. void * 
  12.     malloc_zone_calloc(malloc_zone_t *zone, size_t num_items, size_t size
  13.     MALLOC_TRACE(TRACE_calloc | DBG_FUNC_START, (uintptr_t)zone, num_items, size, 0); 
  14.  
  15.     void *ptr; 
  16.     if (malloc_check_start && (malloc_check_counter++ >= malloc_check_start)) { 
  17.         internal_check(); 
  18.     } 
  19.  
  20.     ptr = zone->calloc(zone, num_items, size); 
  21.      
  22.     if (malloc_logger) { 
  23.         malloc_logger(MALLOC_LOG_TYPE_ALLOCATE | MALLOC_LOG_TYPE_HAS_ZONE | MALLOC_LOG_TYPE_CLEARED, (uintptr_t)zone, 
  24.                 (uintptr_t)(num_items * size), 0, (uintptr_t)ptr, 0); 
  25.     } 
  26.  
  27.     MALLOC_TRACE(TRACE_calloc | DBG_FUNC_END, (uintptr_t)zone, num_items, size, (uintptr_t)ptr); 
  28.     return ptr; 

断点打印 zone->calloc

  • ①:得到其真实调用为 default_zone_calloc
  • ②:搜索 default_zone_calloc 继续跟进,打印 default_zone_calloc 内部的 zone->calloc 得到 nano_calloc
  • ③:分析 nano_calloc 源码可以知道在 _nano_malloc_check_clear 内进行了相关操作
  1. static void * 
  2. default_zone_calloc(malloc_zone_t *zone, size_t num_items, size_t size
  3.     zone = runtime_default_zone(); 
  4.      
  5.     return zone->calloc(zone, num_items, size); 
  6.  
  7. static void * 
  8. nano_calloc(nanozone_t *nanozone, size_t num_items, size_t size
  9.     size_t total_bytes; 
  10.  
  11.     if (calloc_get_size(num_items, size, 0, &total_bytes)) { 
  12.         return NULL
  13.     } 
  14.  
  15.     if (total_bytes <= NANO_MAX_SIZE) { 
  16.         void *p = _nano_malloc_check_clear(nanozone, total_bytes, 1); 
  17.         if (p) { 
  18.             return p; 
  19.         } else { 
  20.             /* FALLTHROUGH to helper zone */ 
  21.         } 
  22.     } 
  23.     malloc_zone_t *zone = (malloc_zone_t *)(nanozone->helper_zone); 
  24.     return zone->calloc(zone, 1, total_bytes); 

跳转到 _nano_malloc_check_clear 内部发现代码很多,一脸懵逼,但是仔细一看很多都是做一些容错判断,除去这些代码后,返现与size 有关的只有一行代码:

  1. size_t slot_bytes = segregated_size_to_fit(nanozone, size, &slot_key); 

跳转进 segregated_size_to_fit 可以看到又是内存对齐的代码,这里的内存对齐是以16字节原则进行对齐的。

  1. #define SHIFT_NANO_QUANTUM      4 
  2. #define NANO_REGIME_QUANTA_SIZE (1 << SHIFT_NANO_QUANTUM)   // 16 
  3.  
  4. static MALLOC_INLINE size_t 
  5. segregated_size_to_fit(nanozone_t *nanozone, size_t size, size_t *pKey) 
  6.     size_t k, slot_bytes; 
  7.  
  8.     if (0 == size) { 
  9.         size = NANO_REGIME_QUANTA_SIZE; // Historical behavior 
  10.     } 
  11.     k = (size + NANO_REGIME_QUANTA_SIZE - 1) >> SHIFT_NANO_QUANTUM; // round up and shift for number of quanta 
  12.     slot_bytes = k << SHIFT_NANO_QUANTUM;                           // multiply by power of two quanta size 
  13.     *pKey = k - 1;                                                  // Zero-based! 
  14.  
  15.     return slot_bytes; 

总结

经过上述的各种分析,我们可以得到的结论是 instanceSize 是以 8 字节进行对齐的, 后面 calloc 是以 16 字节进行对齐的,说明 calloc 进一步对对象进行了处理。也就解释了我们打印出来的 40-48 了。

 

由以上可以知道对象申请的内存大小和系统开辟的大小存在不一致的情况,8 字节对齐应用于对象的属性,16 字节对齐应用于对象,由于对象的内存是连续的,这样可以规避一些不必要的风险,以空间换时间来得到更高的安全性。

 

责任编辑:武晓燕 来源: 网罗开发
相关推荐

2021-08-06 11:50:49

Linux 字节对齐Linux 系统

2021-01-07 07:53:10

JavaScript内存管理

2021-12-16 06:52:33

C语言内存分配

2021-08-16 06:56:21

Slice数组类型内存

2022-11-30 08:19:15

内存分配Go逃逸分析

2018-03-27 10:06:26

对象存储演进

2013-04-17 10:46:54

面向对象

2022-11-28 07:21:53

操作系统内存管理

2023-06-14 08:15:34

算法合并操作Winner

2024-03-05 10:09:16

restfulHTTPAPI

2010-08-10 10:00:57

Flex内存

2012-06-07 10:11:01

面向对象设计原则Java

2021-02-03 15:12:08

java内存溢出

2021-05-19 08:04:11

ASP.Net服务性原则

2019-07-11 15:43:44

KVMKSM内存

2009-10-09 09:42:07

虚拟机内存

2020-05-09 13:49:00

内存空间垃圾

2020-09-25 07:55:51

内存Java对象

2022-12-12 08:42:06

Java对象栈内存

2021-03-28 13:54:31

操作系统内存管理
点赞
收藏

51CTO技术栈公众号