iOS 面試 -- 內(nèi)存管理


最近給人的感覺就是哪里都想去但是哪里卻又不敢去，好比在你面前擺了個(gè)毒蘋果，你就那么的看著，就是不敢碰，不敢吃?。?！ 自己體會(huì)一下那種心情吧。雖說如此，各位還是要把安全健康擺在第一位，出門記得帶口罩，回家記得做好消毒！疫情之下，未工作的小朋友們的世界是盡情撒歡，而已工作在家的人則擔(dān)心延期上班工資是否會(huì)照發(fā)，上有老，下有小... 負(fù)重前行的大人們，今天還是看看iOS面試篇之內(nèi)存管理吧，夯實(shí)基礎(chǔ)?。?！


前言

判斷一個(gè)人的基礎(chǔ)是否扎實(shí)，或者說是否有足夠解決問題的能力，那么就看他分析問題和研究問題的深入性以及是否具備舉一反三的能力，這個(gè)從面試iOS的內(nèi)存管理其實(shí)也能看出個(gè)大概。iOS 內(nèi)存管理主要從以下幾個(gè)問題著手，如下圖：


內(nèi)存布局

內(nèi)存布局

上圖給我們展示的則是 iOS 的內(nèi)存布局，最上方代表的是一個(gè)內(nèi)核區(qū)的內(nèi)存，最下方是保留的內(nèi)存空間，中間的位置是我們程序進(jìn)行加載的空間，整個(gè)地址的表示是由下到上從低地址到高地址的表述，我們的程序加載到內(nèi)存會(huì)分成三段，分別是代碼段，已初始化數(shù)據(jù)，未初始化數(shù)據(jù)，我們聲明的一些已初始化的靜態(tài)變量和全局變量一般是放在已初始化數(shù)據(jù)區(qū)，我們聲明的一些未初始化的靜態(tài)變量和全局變量一般是放在未初始化數(shù)據(jù)區(qū)，代碼段則是我們的代碼所在的空間。而我們定義的一些方法或者函數(shù)都是在棧里，棧是自頂向下的，也就是所謂的高地址向低地址進(jìn)行拓展的。而我們創(chuàng)建的對(duì)象或者 block 經(jīng)過 copy 以后都是在堆內(nèi)存中的，堆是向上增長(zhǎng)。

內(nèi)存管理方案

iOS 系統(tǒng)針對(duì)不同場(chǎng)景下有以下三種方案進(jìn)行內(nèi)存管理

  • TaggedPointer
    對(duì)于一些小對(duì)象，比如說 NSNumber
  • NONPOINTER_ISA
    arm64下，實(shí)際有 64bit 位表示對(duì)象的內(nèi)存地址，而實(shí)際使用的位數(shù)則是需要 30/40位就夠用，其他的位數(shù)蘋果公司為了不浪費(fèi)內(nèi)存地址，就用來做了其他的事情，所以這個(gè)就是NONPOINTER_ISA，后續(xù)會(huì)詳細(xì)介紹
  • 散列表
    引用計(jì)數(shù)、弱引用表等

NONPOINTER_ISA

注：以下都是基于 arm64 架構(gòu)下進(jìn)行闡述的
arm64下，實(shí)際有 64bit 位表示對(duì)象的內(nèi)存地址，

  • 在 0-15 位中，第一位代表的是indexed，indexed 為 0 的時(shí)候，表示該類對(duì)象的地址就是該 isa 指針的地址，如果是 1，則代表后續(xù)的bit 位會(huì)存儲(chǔ)除了類對(duì)象的地址之外，還會(huì)存在其他的內(nèi)存管理相關(guān)的數(shù)據(jù)
  • 第二位代表是當(dāng)前對(duì)象是否有關(guān)聯(lián)對(duì)象0 沒有，1 有
  • 第三位代表的是當(dāng)前對(duì)象是否有 c++相關(guān)的內(nèi)容
  • 后面的位數(shù)則代表當(dāng)前對(duì)象的類對(duì)象的地址5-38 位總共 33 位表述的是類對(duì)象的地址
  • 接下來的 6 位代表的 magic
  • 后的一位標(biāo)識(shí)的是該類對(duì)相關(guān)是否有弱引用指針
  • 再往后一位標(biāo)識(shí)的是當(dāng)前對(duì)象是否在 deallocting 中
  • 再往后則是當(dāng)前類對(duì)象存儲(chǔ)的引用計(jì)數(shù)是否達(dá)到上限，如果是 1 則需要外掛一個(gè)散列表
  • 再往后則代表的是當(dāng)前類對(duì)象額外的引用計(jì)數(shù)。

散列表


上圖中的SideTables的數(shù)據(jù)結(jié)構(gòu)它實(shí)際上是一個(gè) hash 表


上圖表述的是 sideTable的數(shù)據(jù)結(jié)構(gòu)

下面思考一個(gè)問題

為什么不是一個(gè) sideTable，而是多個(gè) sideTable共同組成一個(gè) sideTables呢？

假如只有一張，那么我們的類對(duì)象在內(nèi)存中分配的所有的引用計(jì)數(shù)表、弱引用表都放到一張大表中，這個(gè)時(shí)候如果我們要操作某一個(gè)對(duì)象的引用計(jì)數(shù)值，對(duì)其進(jìn)行修改，+1 或者-1，由于所有的對(duì)象是在不同的線程中進(jìn)行創(chuàng)建或者分配的，我們要保證數(shù)據(jù)安全的前提下，進(jìn)行操作，那么就要加鎖，所以存在一個(gè)效率問題?。?！所以蘋果使用的是 sideTables，引入分離鎖的機(jī)智，提升了訪問效率！另外如果感興趣，大家可以上網(wǎng)搜一下特斯拉的電池管理技術(shù)，和蘋果的散列表方法，如出一轍！

怎么樣快速分流？（通過對(duì)象的指針地址如何快速的定位到sideTable）

其實(shí) sideTables的本質(zhì)是一張 hash 表，hash 查找和 hash 算法， key 經(jīng)過hash 運(yùn)算最終得出 value。key 則是指針地址，value 其實(shí)就是數(shù)組的 index，其 hash 函數(shù)其實(shí)就是 指針地址對(duì)數(shù)組個(gè)數(shù)進(jìn)行取余，最終得出的就是 index。下圖就是 hash 查找的過程


sideTable數(shù)據(jù)結(jié)構(gòu)

Spinlock_t

Spinlock_t：“忙等”的鎖
適用于輕量訪問
自旋鎖：原子操作+自循環(huán)。通常說的用戶構(gòu)造模式。 線程不休眠，一直循環(huán)嘗試對(duì)資源訪問，直到可用。
優(yōu)點(diǎn)：完美解決內(nèi)核鎖的缺點(diǎn)。
缺點(diǎn)：長(zhǎng)時(shí)間一直循環(huán)會(huì)導(dǎo)致cpu的白白浪費(fèi)，高并發(fā)競(jìng)爭(zhēng)下、CPU的消耗特別嚴(yán)重。

你是否用過自旋鎖，是在什么場(chǎng)景下使用的？

引用計(jì)數(shù)表

引用計(jì)數(shù)表 其實(shí)也是 hash 表，為什么使用 hash，插入和查找都是通過同一個(gè) hash 函數(shù)實(shí)現(xiàn)，避免重復(fù)遍歷，提高查找效率


size_t

上圖我們可以看到，假如我們用 64 位表示 size_t，那么它的第一位代表的是該對(duì)象是否是弱引用，第二位代表的是當(dāng)前對(duì)象是否在進(jìn)行 dealloc 操作，后面的則是其引用計(jì)數(shù)的值

弱引用表

weak_table_t 也是 hash 表，具體不是了，上面說了很多與 hash 相關(guān)的了。


ARC&MRC

MRC

手動(dòng)引用計(jì)數(shù)
alloc：分類內(nèi)存空間
retain：引用計(jì)數(shù)+1
release：引用計(jì)數(shù)-1
retainCount：獲取當(dāng)前對(duì)象的引用計(jì)數(shù)
autorelease：當(dāng)前對(duì)象會(huì)在 autoreleasepool 結(jié)束的時(shí)候-1
dealloc：需要廢棄父類的成員變量

ARC

自動(dòng)引用計(jì)數(shù)：是 LLVM和 runtime 共同協(xié)作完成

引用計(jì)數(shù)

引用計(jì)數(shù)管理原理分析

alloc實(shí)現(xiàn)

經(jīng)過一系列的調(diào)用，最終調(diào)用了 C函數(shù) calloc，此時(shí)其引用計(jì)數(shù)并沒有設(shè)置為 1，但是通過 retainCount獲取時(shí)，其值為 1

retain 實(shí)現(xiàn)

retain 實(shí)現(xiàn)源碼

id
objc_object::sidetable_retain()
{
#if SUPPORT_NONPOINTER_ISA
   assert(!isa.nonpointer);
#endif
   SideTable& table = SideTables()[this]; //從SideTables中取出SideTable 實(shí)際就是 hash 查找。
   table.lock();
   size_t& refcntStorage = table.refcnts[this]; //根據(jù)this地址取出refcntStorage 這里又是一次 hash 查找
   if (! (refcntStorage & SIDE_TABLE_RC_PINNED)) {//如果沒有超出引用計(jì)數(shù)最大值
       refcntStorage += SIDE_TABLE_RC_ONE;//引用計(jì)數(shù)加4也就是向左移動(dòng)兩位。上面提到的 0-64 位，第一位代表的是弱引用，第二位代表的 dealloc 操作，所以這里不是實(shí)際意義的 1，但是展現(xiàn)給我們的確是 1
   }
   table.unlock();
   return (id)this;
}
release內(nèi)部實(shí)現(xiàn)

release 內(nèi)部實(shí)現(xiàn)原理

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;//設(shè)置為需要dealloc
    } else if (it->second < SIDE_TABLE_DEALLOCATING) {//沒有引用計(jì)數(shù)值
        // 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)) {//引用計(jì)數(shù)減一
        it->second -= SIDE_TABLE_RC_ONE;
    }
    table.unlock();
    if (do_dealloc  &&  performDealloc) {//對(duì)象需要被銷毀
        ((void(*)(objc_object *, SEL))objc_msgSend)(this, SEL_dealloc);//發(fā)送消息調(diào)用dealloc銷毀對(duì)象。
    }
    return do_dealloc;
}
retainCount內(nèi)部實(shí)現(xiàn)
objc_object::sidetable_retainCount()
{
  SideTable& table = SideTables()[this];
  //對(duì)象初始化時(shí)默認(rèn)為1之后每次對(duì)對(duì)象retain引入計(jì)數(shù)值加1，這里就解釋了為什么一個(gè)對(duì)象 alloc 以后，調(diào)用 retainCount，其值為 1 了
  size_t refcnt_result = 1;
  table.lock();
//獲取RefcountMap  hash 查找
  RefcountMap::iterator it = table.refcnts.find(this);
  if (it != table.refcnts.end()) {//能找到this對(duì)象
      // 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向左移動(dòng)兩位獲取到引用計(jì)數(shù)器的值。
  }
  table.unlock();
  return refcnt_result;//返回引用計(jì)數(shù)值
}
dealloc的內(nèi)部實(shí)現(xiàn)（重點(diǎn)）
Dealloc 調(diào)用流程
  • 1.首先調(diào)用 _objc_rootDealloc()
  • 2.接下來調(diào)用 rootDealloc()
  • 3.這時(shí)候會(huì)判斷是否可以被釋放，判斷的依據(jù)主要有5個(gè)，判斷是否有以上五種情況
    • NONPointer_ISA
    • weakly_reference
    • has_assoc
    • has_cxx_dtor
    • has_sidetable_rc
  • 4-1.如果有以上五中任意一種，將會(huì)調(diào)用 object_dispose()方法，做下一步的處理。
  • 4-2.如果沒有之前五種情況的任意一種，則可以執(zhí)行釋放操作，C函數(shù)的 free()。
  • 5.執(zhí)行完畢。
object_dispose() 調(diào)用流程。
  • 1.直接調(diào)用 objc_destructInstance()。
  • 2.之后調(diào)用 C函數(shù)的 free()。
objc_destructInstance() 調(diào)用流程
  • 1.先判斷 hasCxxDtor，如果有 C++ 的相關(guān)內(nèi)容，要調(diào)用 object_cxxDestruct() ，銷毀 C++ 相關(guān)的內(nèi)容。
  • 2.再判斷 hasAssocitatedObjects，如果有的話，要調(diào)用 object_remove_associations()，銷毀關(guān)聯(lián)對(duì)象的一系列操作。
  • 3.然后調(diào)用 clearDeallocating()。
  • 4.執(zhí)行完畢。
clearDeallocating() 調(diào)用流程。
  • 1.先執(zhí)行 sideTable_clearDellocating()。
  • 2.再執(zhí)行 weak_clear_no_lock,在這一步驟中，會(huì)將指向該對(duì)象的弱引用指針置為 nil。
  • 3.接下來執(zhí)行 table.refcnts.eraser()，從引用計(jì)數(shù)表中擦除該對(duì)象的引用計(jì)數(shù)。
  • 4.至此為止，Dealloc 的執(zhí)行流程結(jié)束。

弱引用

關(guān)于弱引用篇幅比較長(zhǎng)，我找了一篇講的不錯(cuò)的， 看下面這個(gè)就好了
https://www.cnblogs.com/oc-bowen/p/9120727.html

自動(dòng)釋放池（待續(xù)）

autoreleasepool 的實(shí)現(xiàn)原理?

autoreleasepool 為什么可以嵌套使用?

循環(huán)引用（這個(gè)問題留到章節(jié)再一起）

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 內(nèi)存布局 不同內(nèi)存布局區(qū)域的含義stack（棧）：方法調(diào)用heap（堆）：通過alloc等分配的對(duì)象bss：未初始...
    愛玩游戲的iOS菜鳥閱讀 1,540評(píng)論 0贊 21
  • 1、內(nèi)存布局 stack:方法調(diào)用 heap:通過alloc等分配對(duì)象 bss:未初始化的全局變量等。 data:...
    AKyS佐毅閱讀 1,712評(píng)論 0贊 19
  • iOS中內(nèi)存管理機(jī)制是開發(fā)中一項(xiàng)很重要的知識(shí)，了解iOS中內(nèi)存管理的規(guī)則不管是在開發(fā)中還是在學(xué)習(xí)中都能很大程度的幫...
    Horson19閱讀 1,254評(píng)論 0贊 4
  • iOS中內(nèi)存管理機(jī)制是開發(fā)中一項(xiàng)很重要的知識(shí)，了解iOS中內(nèi)存管理的規(guī)則不管是在開發(fā)中還是在學(xué)習(xí)中都能很大程度的幫...
    Horson19閱讀 2,001評(píng)論 0贊 7
  • iOS | 面試知識(shí)整理 - 內(nèi)存管理(五) 1.什么是內(nèi)存泄漏? 內(nèi)存泄漏指動(dòng)態(tài)分配內(nèi)存的對(duì)象在使用完后沒有被...
    d76d0c9d2b04閱讀 454評(píng)論 0贊 2

友情鏈接更多精彩內(nèi)容