美文网首页
iOS-内存管理

iOS-内存管理

作者: 泽泽伐木类 | 来源:发表于2020-12-02 18:26 被阅读0次
    前言

    说到iOS的内存管理,大致应该分为以下几个方面:

    1. NSTaggedPointer 类型
    2. alloc,retain,release,dealloc,retainCount 原理
    3. @autoreleasepool 原理

    alloc可以移步我的这篇文章:iOS-OC对象原理_alloc&init
    @autoreleasepool移步:iOS-OC底层-AutoReleasePool分析

    TaggedPointer

    TaggedPointer一直都没找到一个比较官方的定义,俗称小对象类型。它是一种特殊的类型,特点就是它的指针是值+指针。这是苹果做的一层优化处理,小对象类型的数据存储在常量区,所以它的释放是由系统来处理的。比如在retainrelease中,都对这种类型做了排除处理:

    if (isTaggedPointer()) return (uintptr_t)this;
    

    在看下面的代码:

    - (void)viewDidLoad
    {
        [super viewDidLoad];
        NSString *str0 = [NSString stringWithFormat:@"z"];
        NSString *str1 = [NSString stringWithFormat:@"zezefamily.com我是zezefaily"];
    }
    

    通过LLDB,输出一下str0str1

    (lldb) p str0
    (NSTaggedPointerString *) $2 = 0xac6d1e2074072a9f @"z"
    (lldb) p str1
    (__NSCFString *) $3 = 0x0000600001a24230 @"zezefamily.com我是zezefaily"
    (lldb) 
    

    这里可以看到一个非常明显的不同是str0NSTaggedPointerString *类型,而str1__NSCFString *类型。这就是苹果的优化处理,当对象存在的内容比较小时,就被优化为一个TaggedPointer类型,以更少的字节数来保存,同时指针也做了混淆处理,来保证值的安全。
    我们可以通过源码中的混淆编解码函数,将混淆后的指针还原回来。

    extern uintptr_t objc_debug_taggedpointer_obfuscator;
    uintptr_t
    _objc_decodeTaggedPointer_(id ptr)
    {
        return (uintptr_t)ptr ^ objc_debug_taggedpointer_obfuscator;
    }
    

    通过指针还原输出如下:

    (lldb) p/x str0
    (NSTaggedPointerString *) $4 = 0xab158b5ee1846519 @"z"
    (lldb) p/x _objc_decodeTaggedPointer_(str0)
    (uintptr_t) $5 = 0xa0000000000007a1
    

    0xa0000000000007a1指针,解析出0x7a(ascii码:122)是这个z,0xa是类型信息,即1 010->1标识为是TaggedPointer类型,010->2, 对应关系如下:

    typedef uint16_t objc_tag_index_t;
    enum
    #endif
    {
        // 60-bit payloads
        OBJC_TAG_NSAtom            = 0, 
        OBJC_TAG_1                 = 1, 
        OBJC_TAG_NSString          = 2, 
        OBJC_TAG_NSNumber          = 3, 
        OBJC_TAG_NSIndexPath       = 4, 
        OBJC_TAG_NSManagedObjectID = 5, 
        OBJC_TAG_NSDate            = 6,
    
        // 60-bit reserved
        OBJC_TAG_RESERVED_7        = 7, 
    
        // 52-bit payloads
        OBJC_TAG_Photos_1          = 8,
        OBJC_TAG_Photos_2          = 9,
        OBJC_TAG_Photos_3          = 10,
        OBJC_TAG_Photos_4          = 11,
        OBJC_TAG_XPC_1             = 12,
        OBJC_TAG_XPC_2             = 13,
        OBJC_TAG_XPC_3             = 14,
        OBJC_TAG_XPC_4             = 15,
        OBJC_TAG_NSColor           = 16,
        OBJC_TAG_UIColor           = 17,
        OBJC_TAG_CGColor           = 18,
        OBJC_TAG_NSIndexSet        = 19,
    
        OBJC_TAG_First60BitPayload = 0, 
        OBJC_TAG_Last60BitPayload  = 6, 
        OBJC_TAG_First52BitPayload = 8, 
        OBJC_TAG_Last52BitPayload  = 263, 
    
        OBJC_TAG_RESERVED_264      = 264
    };
    

    说明:笔者对这个地址相关的东西比较懵逼,说不清楚。这里需要知道的就是有TaggedPointer类型的存在,并且当被标记为该类型的对象会存入常量区,其内存管理是由系统决定的。

    retain

    在探索retain之前我们需要先回顾下isa_t这个联合体iOS-OC对象原理_NONPOINTER_ISA,我们知道在isa_t中包含一个extra_rchas_sidetable_rc,其中extra_rc表示该对象的引用计数值,而has_sidetable_rc表示是否引用了散列表,当extra_rc空间存储的值超出范围时,会使用sidetable(散列表进行存储),即标记为has_sidetable_rc = true。所以这里先看下SideTable的数据结构:

    struct SideTable {
        spinlock_t slock;  //锁
        RefcountMap refcnts;  //引用计数表
        weak_table_t weak_table;  //弱引用表
        SideTable() {
            memset(&weak_table, 0, sizeof(weak_table));
        }
        ~SideTable() {
            _objc_fatal("Do not delete SideTable.");
        }
        void lock() { slock.lock(); }
        void unlock() { slock.unlock(); }
        void forceReset() { slock.forceReset(); }
        // Address-ordered lock discipline for a pair of side tables.
        template<HaveOld, HaveNew>
        static void lockTwo(SideTable *lock1, SideTable *lock2);
        template<HaveOld, HaveNew>
        static void unlockTwo(SideTable *lock1, SideTable *lock2);
    };
    

    这里可以看到,在SideTable散列表中包含了refcnts引用计数表和weak_table弱引用表。这里要注意的是:不是每个对象对应一个散列表,而是一个散列表中对应多个对象,在iOS真机下,默认创建8个SideTable。 为什么不直接全部存放在一个SideTable里呐?这里主要是为了安全和效率,如果存在一个SideTable,每次访问数据时,会将全部数据暴露出来,有安全隐患;同时查询的数据量庞大,导致效率变慢。
    整个SideTable数据结构图如下:

    SideTable数据结构关系表(仅供参考)
    我们知道了这样一个结构之后,再开始我们的retain探索:
    首先说retain,本质就是引用计数加1,即isa.extra_rc+1,具体是怎么操作的呐,先看一下retain的源码:
    - (id)retain {
        return _objc_rootRetain(self);
    }
    _objc_rootRetain(id obj)
    {
        ASSERT(obj);
        return obj->rootRetain();
    }
    ALWAYS_INLINE id 
    objc_object::rootRetain()
    {
        return rootRetain(false, false);
    }
    ALWAYS_INLINE id 
    objc_object::rootRetain(bool tryRetain, bool handleOverflow)
    {
        if (isTaggedPointer()) return (id)this;
    
        bool sideTableLocked = false;
        bool transcribeToSideTable = false;
        //extra_rc
        //
        isa_t oldisa;
        isa_t newisa;
    
        do {
            transcribeToSideTable = false;
            oldisa = LoadExclusive(&isa.bits);
            newisa = oldisa;
            //判断是否为nonpointer_isa
            if (slowpath(!newisa.nonpointer)) { //不是nonpointer_isa 直接操作散列表
                ClearExclusive(&isa.bits);
                if (rawISA()->isMetaClass()) return (id)this;
                if (!tryRetain && sideTableLocked) sidetable_unlock();
                if (tryRetain) return sidetable_tryRetain() ? (id)this : nil;
                else return sidetable_retain();
            }
            // don't check newisa.fast_rr; we already called any RR overrides
            // 是否正在析构中..
            if (slowpath(tryRetain && newisa.deallocating)) {
                ClearExclusive(&isa.bits);
                if (!tryRetain && sideTableLocked) sidetable_unlock();
                return nil;
            }
            //正常情况
            uintptr_t carry;
            newisa.bits = addc(newisa.bits, RC_ONE, 0, &carry);  // extra_rc++
            
            if (slowpath(carry)) {
                // newisa.extra_rc++ overflowed
                if (!handleOverflow) {
                    ClearExclusive(&isa.bits);
                    return rootRetain_overflow(tryRetain);
                }
                //当isa.extra_rc 满了,将isa.has_sidetable_rc 标记为true,
                //isa.extra_rc保留数据的一半RC_HALF,另一半存入散列表中sidetable->refconts->this
                // Leave half of the retain counts inline and 
                // prepare to copy the other half to the side table.
                if (!tryRetain && !sideTableLocked) sidetable_lock();
                sideTableLocked = true;
                transcribeToSideTable = true;
                newisa.extra_rc = RC_HALF;
                newisa.has_sidetable_rc = true;
            }
        } while (slowpath(!StoreExclusive(&isa.bits, oldisa.bits, newisa.bits)));
    
        if (slowpath(transcribeToSideTable)) {
            // Copy the other half of the retain counts to the side table.
            sidetable_addExtraRC_nolock(RC_HALF);
        }
    
        if (slowpath(!tryRetain && sideTableLocked)) sidetable_unlock();
        return (id)this;
    }
    

    最终retain会来到objc_object::rootRetain()函数,这里可以看到一段核心的代码是在一个do while循环中。大致分为3个部分:

    1. 判断当前对象是否为nonpointer_isa类型,如果不是,直接操作散列表
    id
    objc_object::sidetable_retain()
    {
    #if SUPPORT_NONPOINTER_ISA
        ASSERT(!isa.nonpointer);
    #endif
        SideTable& table = SideTables()[this];
        
        table.lock();
        size_t& refcntStorage = table.refcnts[this];
        if (! (refcntStorage & SIDE_TABLE_RC_PINNED)) {
            refcntStorage += SIDE_TABLE_RC_ONE;
        }
        table.unlock();
    
        return (id)this;
    }
    

    根据this找到对应的SideTable,并通过table.refcnts[this]找到当前对象的引用计数值refcntStorage,并进行refcntStorage += SIDE_TABLE_RC_ONE;并返回。

    1. 判断当前对象是否正在析构
      即判断newisa.deallocating是否为true,如果正在析构(正在dealloc),直接返回nil。

    2. 正常的引用计数情况
      如果以上2个if都不满足,也就是开始正常的操作流程。首先,通过addc(newisa.bits, RC_ONE, 0, &carry)isa.extra_rc++,这里用一个carry来标记extra_rc是否已经满了,如果数据溢出,将isa.extra_rc的值设置为原来的一半,并将has_sidetable_rc标识设置为true,并将剩下的一半数据,通过
      sidetable_addExtraRC_nolock(RC_HALF);存入散列表中:

    bool 
    objc_object::sidetable_addExtraRC_nolock(size_t delta_rc)
    {
        ASSERT(isa.nonpointer);
        SideTable& table = SideTables()[this];
    
        size_t& refcntStorage = table.refcnts[this];
        size_t oldRefcnt = refcntStorage;
        // isa-side bits should not be set here
        ASSERT((oldRefcnt & SIDE_TABLE_DEALLOCATING) == 0);
        ASSERT((oldRefcnt & SIDE_TABLE_WEAKLY_REFERENCED) == 0);
    
        //pinned
        if (oldRefcnt & SIDE_TABLE_RC_PINNED) return true;
    
        uintptr_t carry;
        size_t newRefcnt = 
            addc(oldRefcnt, delta_rc << SIDE_TABLE_RC_SHIFT, 0, &carry);
        if (carry) {
            refcntStorage =
                SIDE_TABLE_RC_PINNED | (oldRefcnt & SIDE_TABLE_FLAG_MASK);
            return true;
        }
        else {
            refcntStorage = newRefcnt;
            return false;
        }
    }
    

    这里将extra_rc设置为原来的一半(RC_HALF),同时将另一半存入SideTable,这里其实也是一种优化方式,当要溢出时,给extra_rc释放容量,将释放出的内容存入Sidetable,下次retain直接通过extra_rc++,减少了对SideTable的频繁操作,通过直接操作extra_rc++效率更高。

    这就是整个retain的流程了,首先先判断当前对象是否为nopointer类型,如果不是,直接操作SideTable散列表,存储引用计数,并return;判断当前对象是否正在析构,如果正在析构,则直接return nil;否则进入正常的引用计数处理,即isa.extra_rc++, 判断当前extra_rc是否溢出,如果没有直接return; 如果发生溢出,则将extra_rc赋值为原来的一半,并将has_sideTable_rc标记为true,将另一半数据存入SideTable散列表中。

    release

    上面已经熟悉了retain的流程,再看release就比较容易了,逆向思维:

    ALWAYS_INLINE bool 
    objc_object::rootRelease(bool performDealloc, bool handleUnderflow)
    {
        if (isTaggedPointer()) return false;
    
        bool sideTableLocked = false;
    
        isa_t oldisa;
        isa_t newisa;
    
     retry:
        do {
            oldisa = LoadExclusive(&isa.bits);
            newisa = oldisa;
            if (slowpath(!newisa.nonpointer)) {
                ClearExclusive(&isa.bits);
                if (rawISA()->isMetaClass()) return false;
                if (sideTableLocked) sidetable_unlock();
                return sidetable_release(performDealloc);
            }
            // don't check newisa.fast_rr; we already called any RR overrides
            uintptr_t carry;
            newisa.bits = subc(newisa.bits, RC_ONE, 0, &carry);  // extra_rc--
            if (slowpath(carry)) {
                // don't ClearExclusive()
                goto underflow;
            }
        } while (slowpath(!StoreReleaseExclusive(&isa.bits, 
                                                 oldisa.bits, newisa.bits)));
    
        if (slowpath(sideTableLocked)) sidetable_unlock();
        return false;
    
     underflow:
        // newisa.extra_rc-- underflowed: borrow from side table or deallocate
    
        // abandon newisa to undo the decrement
        newisa = oldisa;
    
        if (slowpath(newisa.has_sidetable_rc)) {
            if (!handleUnderflow) {
                ClearExclusive(&isa.bits);
                return rootRelease_underflow(performDealloc);
            }
    
            // Transfer retain count from side table to inline storage.
    
            if (!sideTableLocked) {
                ClearExclusive(&isa.bits);
                sidetable_lock();
                sideTableLocked = true;
                // Need to start over to avoid a race against 
                // the nonpointer -> raw pointer transition.
                goto retry;
            }
    
            // Try to remove some retain counts from the side table.        
            size_t borrowed = sidetable_subExtraRC_nolock(RC_HALF);
    
            // To avoid races, has_sidetable_rc must remain set 
            // even if the side table count is now zero.
    
            if (borrowed > 0) {
                // Side table retain count decreased.
                // Try to add them to the inline count.
                newisa.extra_rc = borrowed - 1;  // redo the original decrement too
                bool stored = StoreReleaseExclusive(&isa.bits, 
                                                    oldisa.bits, newisa.bits);
                if (!stored) {
                    // Inline update failed. 
                    // Try it again right now. This prevents livelock on LL/SC 
                    // architectures where the side table access itself may have 
                    // dropped the reservation.
                    isa_t oldisa2 = LoadExclusive(&isa.bits);
                    isa_t newisa2 = oldisa2;
                    if (newisa2.nonpointer) {
                        uintptr_t overflow;
                        newisa2.bits = 
                            addc(newisa2.bits, RC_ONE * (borrowed-1), 0, &overflow);
                        if (!overflow) {
                            stored = StoreReleaseExclusive(&isa.bits, oldisa2.bits, 
                                                           newisa2.bits);
                        }
                    }
                }
    
                if (!stored) {
                    // Inline update failed.
                    // Put the retains back in the side table.
                    sidetable_addExtraRC_nolock(borrowed);
                    goto retry;
                }
    
                // Decrement successful after borrowing from side table.
                // This decrement cannot be the deallocating decrement - the side 
                // table lock and has_sidetable_rc bit ensure that if everyone 
                // else tried to -release while we worked, the last one would block.
                sidetable_unlock();
                return false;
            }
            else {
                // Side table is empty after all. Fall-through to the dealloc path.
            }
        }
    
        // Really deallocate.
    
        if (slowpath(newisa.deallocating)) {
            ClearExclusive(&isa.bits);
            if (sideTableLocked) sidetable_unlock();
            return overrelease_error();
            // does not actually return
        }
        newisa.deallocating = true;
        if (!StoreExclusive(&isa.bits, oldisa.bits, newisa.bits)) goto retry;
    
        if (slowpath(sideTableLocked)) sidetable_unlock();
    
        __c11_atomic_thread_fence(__ATOMIC_ACQUIRE);
    
        if (performDealloc) {
            ((void(*)(objc_object *, SEL))objc_msgSend)(this, @selector(dealloc));
        }
        return true;
    }
    

    这里还是跟retain差不多,先是判断当前对象是否为nonpointer类型,如果是,直接操作SideTable操作引用计数减减:

    uintptr_t
    objc_object::sidetable_release(bool performDealloc)
    {
    #if SUPPORT_NONPOINTER_ISA
        ASSERT(!isa.nonpointer);
    #endif
        SideTable& table = SideTables()[this];
    
        bool do_dealloc = false;
    
        table.lock();
        auto it = table.refcnts.try_emplace(this, SIDE_TABLE_DEALLOCATING);
        auto &refcnt = it.first->second;
        if (it.second) {
            do_dealloc = true;
        } else if (refcnt < SIDE_TABLE_DEALLOCATING) {
            // SIDE_TABLE_WEAKLY_REFERENCED may be set. Don't change it.
            do_dealloc = true;
            refcnt |= SIDE_TABLE_DEALLOCATING;
        } else if (! (refcnt & SIDE_TABLE_RC_PINNED)) {
            refcnt -= SIDE_TABLE_RC_ONE;
        }
        table.unlock();
        if (do_dealloc  &&  performDealloc) {
            ((void(*)(objc_object *, SEL))objc_msgSend)(this, @selector(dealloc));
        }
        return do_dealloc;
    }
    

    如果是nonpointer类型,直接执行extra_rc--,之后通过carry判断extra_rc是否已经减没了,如果已经没值了,跳转到underflow处理。在underflow中,
    判断是否引用散列表计数newisa.has_sidetable_rc?,如果成立,通过size_t borrowed = sidetable_subExtraRC_nolock(RC_HALF),取出对应的计数值,判断borrowed是否大于0,如果大于0,将borrowed-1赋值给isa.extra_rc;如果不大于0,什么都不做。如果最终的引用计数=0 ,则会通过objc_msgSend()触发dealloc

    ((void(*)(objc_object *, SEL))objc_msgSend)(this, @selector(dealloc));
    

    紧接着,看dealloc

    dealloc

    dealloc最终也会来到rootDealloc

    inline void
    objc_object::rootDealloc()
    {
        if (isTaggedPointer()) return;  // fixme necessary?
    
        if (fastpath(isa.nonpointer  &&  
                     !isa.weakly_referenced  &&  
                     !isa.has_assoc  &&  
                     !isa.has_cxx_dtor  &&  
                     !isa.has_sidetable_rc))
        {
            assert(!sidetable_present());
            free(this);
        } 
        else {
            object_dispose((id)this);
        }
    }
    

    首先判断当前对象是否为nonpointer类型,且没有弱引用,没有关联对象,没有C++函数,没有sidetable引用,如果成立就直接free(this);否则object_dispose((id)this);

    id 
    object_dispose(id obj)
    {
        if (!obj) return nil;
        objc_destructInstance(obj);    
        free(obj);
        return nil;
    }
    //释放C++相关, 移除关联对象
    void *objc_destructInstance(id obj) 
    {
        if (obj) {
            // Read all of the flags at once for performance.
            bool cxx = obj->hasCxxDtor();
            bool assoc = obj->hasAssociatedObjects();
    
            // This order is important.
            if (cxx) object_cxxDestruct(obj);
            if (assoc) _object_remove_assocations(obj);
            obj->clearDeallocating();
        }
        return obj;
    }
    inline void 
    objc_object::clearDeallocating()
    {
        if (slowpath(!isa.nonpointer)) {
            // Slow path for raw pointer isa.
            sidetable_clearDeallocating();
        }
        else if (slowpath(isa.weakly_referenced  ||  isa.has_sidetable_rc)) {
            // Slow path for non-pointer isa with weak refs and/or side table data.
            clearDeallocating_slow();
        }
        assert(!sidetable_present());
    }
    //清空弱引用表和引用计数表中的数据
    NEVER_INLINE void
    objc_object::clearDeallocating_slow()
    {
        ASSERT(isa.nonpointer  &&  (isa.weakly_referenced || isa.has_sidetable_rc));
    
        SideTable& table = SideTables()[this];
        table.lock();
        if (isa.weakly_referenced) {
            weak_clear_no_lock(&table.weak_table, (id)this);
        }
        if (isa.has_sidetable_rc) {
            table.refcnts.erase(this);
        }
        table.unlock();
    }
    

    这里就不细说每一个函数的内容了,总之就是释放C++相关内容,移除关联对象,清空弱引用表对应的数据,清空引用计数表中对应的数据,最后执行free(this)

    retainCount

    先来一段代码:

    int main(int argc, const char * argv[]) {
        @autoreleasepool {
            // insert code here...
            NSObject *obj = [NSObject alloc];
            NSLog(@"retainCount == %ld",CFGetRetainCount((__bridge CFTypeRef)(obj)));
            NSLog(@"retainCount == %ld",CFGetRetainCount((__bridge CFTypeRef)(obj)));
            NSLog(@"retainCount == %ld",CFGetRetainCount((__bridge CFTypeRef)(obj)));
        }
        return 0;
    }
    

    上面的retainCount输出为多少? 答案为1,

    [49975:21037772] retainCount == 1
    [49975:21037772] retainCount == 1
    [49975:21037772] retainCount == 1
    

    这里只是创建对象,还没有被引用为什么就是1了呐?来看下retainCount源码:

    inline uintptr_t 
    objc_object::rootRetainCount()
    {
        if (isTaggedPointer()) return (uintptr_t)this;
        sidetable_lock();
        isa_t bits = LoadExclusive(&isa.bits);
        ClearExclusive(&isa.bits);
        if (bits.nonpointer) {
            uintptr_t rc = 1 + bits.extra_rc;  // alloc 1 + 0 = 1;
            if (bits.has_sidetable_rc) {
                rc += sidetable_getExtraRC_nolock();
            }
            sidetable_unlock();
            return rc;
        }
        sidetable_unlock();
        return sidetable_retainCount();
    }
    

    这里可以看到,rc = 1 + bits.extra_rc,我们知道在alloc内部并没有对extra_rc做任何操作,所有这里的extra_rc = 0,最终rc = 1。这里也就说明,一个对象创建后,默认的引用计数为1。这里的1其实也是有意义的,当对象创建时,第一个引用该对象的其实就是这个作用域空间,只是这个1,并没有通过extra_rc来维护。

    到此,alloc -> retain -> release -> dealloc一个闭环就形成了。

    总结

    关于内存管理,其实只要知道了isa.extra_rchas_sidetable_rc,再结合SideTable数据结构关系表,就可以很清楚的理解整个流程了。从头到尾梳理一遍,希望对你的工作和面试会有帮助。

    相关文章

      网友评论

          本文标题:iOS-内存管理

          本文链接:https://www.haomeiwen.com/subject/nsxuwktx.html