iOS 面试 -- 内存管理

最近给人的感觉就是哪里都想去但是哪里却又不敢去，好比在你面前摆了个毒苹果，你就那么的看着，就是不敢碰，不敢吃！！！ 自己体会一下那种心情吧。虽说如此，各位还是要把安全健康摆在第一位，出门记得带口罩，回家记得做好消毒！疫情之下，未工作的小朋友们的世界是尽情撒欢，而已工作在家的人则担心延期上班工资是否会照发，上有老，下有小... 负重前行的大人们，今天还是看看iOS面试篇之内存管理吧，夯实基础！！！

前言

判断一个人的基础是否扎实，或者说是否有足够解决问题的能力，那么就看他分析问题和研究问题的深入性以及是否具备举一反三的能力，这个从面试iOS的内存管理其实也能看出个大概。iOS 内存管理主要从以下几个问题着手，如下图：

内存布局

内存布局

上图给我们展示的则是 iOS 的内存布局，最上方代表的是一个内核区的内存，最下方是保留的内存空间，中间的位置是我们程序进行加载的空间，整个地址的表示是由下到上从低地址到高地址的表述，我们的程序加载到内存会分成三段，分别是代码段，已初始化数据，未初始化数据，我们声明的一些已初始化的静态变量和全局变量一般是放在已初始化数据区，我们声明的一些未初始化的静态变量和全局变量一般是放在未初始化数据区，代码段则是我们的代码所在的空间。而我们定义的一些方法或者函数都是在栈里，栈是自顶向下的，也就是所谓的高地址向低地址进行拓展的。而我们创建的对象或者 block 经过 copy 以后都是在堆内存中的，堆是向上增长。

内存管理方案

iOS 系统针对不同场景下有以下三种方案进行内存管理

• TaggedPointer
  对于一些小对象，比如说 NSNumber
• NONPOINTER_ISA
  arm64下，实际有 64bit 位表示对象的内存地址，而实际使用的位数则是需要 30/40位就够用，其他的位数苹果公司为了不浪费内存地址，就用来做了其他的事情，所以这个就是NONPOINTER_ISA，后续会详细介绍
• 散列表
  引用计数、弱引用表等

NONPOINTER_ISA

注：以下都是基于 arm64 架构下进行阐述的
arm64下，实际有 64bit 位表示对象的内存地址，

• 在 0-15 位中，第一位代表的是indexed，indexed 为 0 的时候，表示该类对象的地址就是该 isa 指针的地址，如果是 1，则代表后续的bit 位会存储除了类对象的地址之外，还会存在其他的内存管理相关的数据
• 第二位代表是当前对象是否有关联对象0 没有，1 有
• 第三位代表的是当前对象是否有 c++相关的内容
• 后面的位数则代表当前对象的类对象的地址5-38 位总共 33 位表述的是类对象的地址
• 接下来的 6 位代表的 magic
• 后的一位标识的是该类对相关是否有弱引用指针
• 再往后一位标识的是当前对象是否在 deallocting 中
• 再往后则是当前类对象存储的引用计数是否达到上限，如果是 1 则需要外挂一个散列表
• 再往后则代表的是当前类对象额外的引用计数。

散列表

上图中的SideTables的数据结构它实际上是一个 hash 表

上图表述的是 sideTable的数据结构

下面思考一个问题

为什么不是一个 sideTable，而是多个 sideTable共同组成一个 sideTables呢？

假如只有一张，那么我们的类对象在内存中分配的所有的引用计数表、弱引用表都放到一张大表中，这个时候如果我们要操作某一个对象的引用计数值，对其进行修改，+1 或者-1，由于所有的对象是在不同的线程中进行创建或者分配的，我们要保证数据安全的前提下，进行操作，那么就要加锁，所以存在一个效率问题！！！所以苹果使用的是 sideTables，引入分离锁的机智，提升了访问效率！另外如果感兴趣，大家可以上网搜一下特斯拉的电池管理技术，和苹果的散列表方法，如出一辙！

怎么样快速分流？（通过对象的指针地址如何快速的定位到sideTable）

其实 sideTables的本质是一张 hash 表，hash 查找和 hash 算法， key 经过hash 运算最终得出 value。key 则是指针地址，value 其实就是数组的 index，其 hash 函数其实就是 指针地址对数组个数进行取余，最终得出的就是 index。下图就是 hash 查找的过程

sideTable数据结构

Spinlock_t

Spinlock_t：“忙等”的锁
适用于轻量访问
自旋锁：原子操作+自循环。通常说的用户构造模式。 线程不休眠，一直循环尝试对资源访问，直到可用。
优点：完美解决内核锁的缺点。
缺点：长时间一直循环会导致cpu的白白浪费，高并发竞争下、CPU的消耗特别严重。

你是否用过自旋锁，是在什么场景下使用的？

引用计数表

引用计数表 其实也是 hash 表，为什么使用 hash，插入和查找都是通过同一个 hash 函数实现，避免重复遍历，提高查找效率

size_t

上图我们可以看到，假如我们用 64 位表示 size_t，那么它的第一位代表的是该对象是否是弱引用，第二位代表的是当前对象是否在进行 dealloc 操作，后面的则是其引用计数的值

弱引用表

weak_table_t 也是 hash 表，具体不是了，上面说了很多与 hash 相关的了。

ARC&MRC

MRC

手动引用计数
alloc：分类内存空间
retain：引用计数+1
release：引用计数-1
retainCount：获取当前对象的引用计数
autorelease：当前对象会在 autoreleasepool 结束的时候-1
dealloc：需要废弃父类的成员变量

ARC

自动引用计数：是 LLVM和 runtime 共同协作完成

引用计数

引用计数管理原理分析

alloc实现

经过一系列的调用，最终调用了 C函数 calloc，此时其引用计数并没有设置为 1，但是通过 retainCount获取时，其值为 1

retain 实现

retain 实现源码

id
objc_object::sidetable_retain()
{
#if SUPPORT_NONPOINTER_ISA
   assert(!isa.nonpointer);
#endif
   SideTable& table = SideTables()[this]; //从SideTables中取出SideTable 实际就是 hash 查找。
   table.lock();
   size_t& refcntStorage = table.refcnts[this]; //根据this地址取出refcntStorage 这里又是一次 hash 查找
   if (! (refcntStorage & SIDE_TABLE_RC_PINNED)) {//如果没有超出引用计数最大值
       refcntStorage += SIDE_TABLE_RC_ONE;//引用计数加4也就是向左移动两位。上面提到的 0-64 位，第一位代表的是弱引用，第二位代表的 dealloc 操作，所以这里不是实际意义的 1，但是展现给我们的确是 1
   }
   table.unlock();
   return (id)this;
}

release内部实现

release 内部实现原理

objc_object::sidetable_release(bool performDealloc)
{
#if SUPPORT_NONPOINTER_ISA
    assert(!isa.nonpointer);
#endif
    SideTable& table = SideTables()[this];//获取到SideTable
 
    bool do_dealloc = false;//是否要被dealloc
 
    table.lock();//锁住table表
    RefcountMap::iterator it = table.refcnts.find(this);//获取到RefcountMap
    if (it == table.refcnts.end()) {//没有找到this
        do_dealloc = true;
        table.refcnts[this] = SIDE_TABLE_DEALLOCATING;//设置为需要dealloc
    } else if (it->second < SIDE_TABLE_DEALLOCATING) {//没有引用计数值
        // SIDE_TABLE_WEAKLY_REFERENCED may be set. Don't change it.
        do_dealloc = true;
        it->second |= SIDE_TABLE_DEALLOCATING;//给it->second赋值
    } else if (! (it->second & SIDE_TABLE_RC_PINNED)) {//引用计数减一
        it->second -= SIDE_TABLE_RC_ONE;
    }
    table.unlock();
    if (do_dealloc  &&  performDealloc) {//对象需要被销毁
        ((void(*)(objc_object *, SEL))objc_msgSend)(this, SEL_dealloc);//发送消息调用dealloc销毁对象。
    }
    return do_dealloc;
}

retainCount内部实现

objc_object::sidetable_retainCount()
{
  SideTable& table = SideTables()[this];
  //对象初始化时默认为1之后每次对对象retain引入计数值加1，这里就解释了为什么一个对象 alloc 以后，调用 retainCount，其值为 1 了
  size_t refcnt_result = 1;
  table.lock();
//获取RefcountMap  hash 查找
  RefcountMap::iterator it = table.refcnts.find(this);
  if (it != table.refcnts.end()) {//能找到this对象
      // this is valid for SIDE_TABLE_RC_PINNED too
      refcnt_result += it->second >> SIDE_TABLE_RC_SHIFT;//
      //it->second是获取到it的value
      //>> SIDE_TABLE_RC_SHIFT上边获取的value向左移动两位获取到引用计数器的值。
  }
  table.unlock();
  return refcnt_result;//返回引用计数值
}

dealloc的内部实现（重点）

Dealloc 调用流程

• 1.首先调用 _objc_rootDealloc()
• 2.接下来调用 rootDealloc()
• 3.这时候会判断是否可以被释放，判断的依据主要有5个，判断是否有以上五种情况
  • NONPointer_ISA
  • weakly_reference
  • has_assoc
  • has_cxx_dtor
  • has_sidetable_rc
• 4-1.如果有以上五中任意一种，将会调用 object_dispose()方法，做下一步的处理。
• 4-2.如果没有之前五种情况的任意一种，则可以执行释放操作，C函数的 free()。
• 5.执行完毕。

object_dispose() 调用流程。

• 1.直接调用 objc_destructInstance()。
• 2.之后调用 C函数的 free()。

objc_destructInstance() 调用流程

• 1.先判断 hasCxxDtor，如果有 C++ 的相关内容，要调用 object_cxxDestruct() ，销毁 C++ 相关的内容。
• 2.再判断 hasAssocitatedObjects，如果有的话，要调用 object_remove_associations()，销毁关联对象的一系列操作。
• 3.然后调用 clearDeallocating()。
• 4.执行完毕。

clearDeallocating() 调用流程。

• 1.先执行 sideTable_clearDellocating()。
• 2.再执行 weak_clear_no_lock,在这一步骤中，会将指向该对象的弱引用指针置为 nil。
• 3.接下来执行 table.refcnts.eraser()，从引用计数表中擦除该对象的引用计数。
• 4.至此为止，Dealloc 的执行流程结束。

弱引用

关于弱引用篇幅比较长，我找了一篇讲的不错的， 看下面这个就好了
https://www.cnblogs.com/oc-bowen/p/9120727.html

自动释放池（待续）

autoreleasepool 的实现原理?

autoreleasepool 为什么可以嵌套使用?

循环引用（这个问题留到章节再一起）