objc源码解析|引用计数管理

通过以下方法查看iOS的引用计数管理：

  • alloc
  • retain
  • release
  • retainCount
  • dealloc

源码版本：objc4-723

alloc

+ (id)alloc {
    return _objc_rootAlloc(self);
}

id
_objc_rootAlloc(Class cls)
{
    return callAlloc(cls, false/*checkNil*/, true/*allocWithZone*/);
}

static ALWAYS_INLINE id
callAlloc(Class cls, bool checkNil, bool allocWithZone=false)
{
    if (slowpath(checkNil && !cls)) return nil;

#if __OBJC2__
    if (fastpath(!cls->ISA()->hasCustomAWZ())) {
        // No alloc/allocWithZone implementation. Go straight to the allocator.
        // fixme store hasCustomAWZ in the non-meta class and 
        // add it to canAllocFast's summary
        if (fastpath(cls->canAllocFast())) {
            // No ctors, raw isa, etc. Go straight to the metal.
            bool dtor = cls->hasCxxDtor();
            id obj = (id)calloc(1, cls->bits.fastInstanceSize());
            if (slowpath(!obj)) return callBadAllocHandler(cls);
            obj->initInstanceIsa(cls, dtor);
            return obj;
        }
        else {
            // Has ctor or raw isa or something. Use the slower path.
            id obj = class_createInstance(cls, 0);
            if (slowpath(!obj)) return callBadAllocHandler(cls);
            return obj;
        }
    }
#endif

    // No shortcuts available.
    if (allocWithZone) return [cls allocWithZone:nil];
    return [cls alloc];
}

当我们调用类的alloc方法时，调用的方法栈如上所示，我们来看最后一部分代码即可。

在这一部分代码中，有两个宏定义：

#define fastpath(x) (__builtin_expect(bool(x), 1))
#define slowpath(x) (__builtin_expect(bool(x), 0))

__builtin_expect的主要作用就是帮助编译器判断条件跳转的预期值，避免因执行jmp跳转指令造成时间浪费。

编译器优化时，根据条件跳转的预期值，按正确地顺序生成汇编代码，把“很有可能发生”的条件分支放在顺序执行指令段，而不是jmp指令段（jmp指令会打乱CPU的指令执行顺序，大大影响CPU指令执行效率）。
在本例中，if else句型编译后, 一个分支的汇编代码紧随前面的代码，而另一个分支的汇编代码需要使用jmp指令才能访问到，很明显通过jmp访问需要更多的时间, 在复杂的程序中，有很多的if else句型,又或者是一个有if else句型的库函数，每秒钟被调用几万次，通常程序员在分支预测方面做得很糟糕，编译器又不能精准的预测每一个分支，这时jmp产生的时间浪费就会很大，函数__builtin_expert()就是用来解决这个问题的。

所以，这里的逻辑就是如果slowpath(checkNil && !cls)为0时，该函数返回nil，为1时走接下里的逻辑。

在接下来的逻辑中，fastpath(!cls->ISA()->hasCustomAWZ()首先会判断当前class或super class是否实现了allocWithZone:方法（AWZ即AllocWithZone），如果没有实现这个方法，最终都会调用C语言函数calloc申请一块内存空间。

如果实现了AWZ方法，就会执行allocWithZone:。

总结，调用alloc时，经过一系列方法调用，最终会在内存中申请一块内存空间，但此时并没有设置引用计数。

retain

- (id)retain {
    return ((id)self)->rootRetain();
}


ALWAYS_INLINE id 
objc_object::rootRetain()
{
    return rootRetain(false, false);
}

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;
}

在上面代码块中，因为篇幅所限省去了rootRetain()的具体实现代码，在rootRetain()中实际上调用了sidetable_retain()方法，也就是最后那部分代码。

在了解最后一部分代码前，需要了解一些概念上的知识，有助于更好的理解系统对对象引用计数管理的实现原理。

为了管理所有对象的引用计数以及对象的所有弱引用指针，系统创建了一个全局的SideTables，SideTables里存的是一个个的SideTable，每个SideTable实际上都是一个结构体，如下：

struct SideTable {
    spinlock_t slock;
    RefcountMap refcnts;
    weak_table_t weak_table;

    //省略部分代码

SideTables本质上是一个全局的hash表，key值为对象的内存地址。
回到sidetable_retain()方法，首先会根据当前对象的指针到SideTables中获取SideTable：

SideTable& table = SideTables()[this];

然后在SideTable的结构体当中获取当前对象的引用计数值：

size_t &refcntStorage = table.refcnts[this];

需要注意的是，这两次查找都是hash查找。
然后再对应用计数值进行+1操作：

refcntStorage += SIDE_TABLE_RC_ONE;

以上，就是进行retain操作时，系统对对象引用计数操作的具体实现。

release

- (oneway void)release {
    ((id)self)->rootRelease();
}

ALWAYS_INLINE bool 
objc_object::rootRelease()
{
    return rootRelease(true, false);
}

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();
    RefcountMap::iterator it = table.refcnts.find(this);
    if (it == table.refcnts.end()) {
        do_dealloc = true;
        table.refcnts[this] = SIDE_TABLE_DEALLOCATING;
    } 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;
    } 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);
    }
    return do_dealloc;
}

篇幅所限，省略了rootRelease()的代码实现，在rootRelease()中会调用sidetable_release()，也就是最后一部分代码，我们可以将最后一部分代码进行简化，简化后的代码如下所示：

SideTable &table = SideTables()[this];
RefcountMap ::iterator it = table.refcnts.find(this);
it->second -= SIDE_TABLE_RC_ONE;

首先根据对象的内存地址到hash表中查找SideTable：

SideTable &table = SideTables()[this];

然后根据查找到的SideTable和对象的内存地址获取其引用计数并-1：

RefcountMap ::iterator it = table.refcnts.find(this);
it->second -= SIDE_TABLE_RC_ONE;

另外，当对象需要被回收时，系统还会利用objc_msgSend向对象发送dealloc消息。

以上，就是进行release操作时，系统对对象引用计数操作的具体实现。

retainCount

- (NSUInteger)retainCount {
    return ((id)self)->rootRetainCount();
}


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;
        if (bits.has_sidetable_rc) {
            rc += sidetable_getExtraRC_nolock();
        }
        sidetable_unlock();
        return rc;
    }

    sidetable_unlock();
    return sidetable_retainCount();
}

uintptr_t
objc_object::sidetable_retainCount()
{
    SideTable& table = SideTables()[this];

    size_t refcnt_result = 1;
    
    table.lock();
    RefcountMap::iterator it = table.refcnts.find(this);
    if (it != table.refcnts.end()) {
        // this is valid for SIDE_TABLE_RC_PINNED too
        refcnt_result += it->second >> SIDE_TABLE_RC_SHIFT;
    }
    table.unlock();
    return refcnt_result;
}

这里把retainCount方法调用栈的全部代码都贴出来了，主要来看最后一部分代码，也就是sidetable_retainCount()方法的代码。

我们也可以带着一个问题来看这段代码，问题是：

为什么刚创建完的对象，它的retainCount是0？

在这个方法的实现中，首先会根据对象的内存地址获取到SideTable：

SideTable& table = SideTables()[this];

然后紧接着声明了一个局部变量refcnt_result，值为1：

size_t refcnt_result = 1;

所以，刚alloc出来的对象，在引用计数表（SideTables）中是没有这个对象的key-value映射的，所以table.refcnts.find(this)读出来的值是0，所以如果这里是0，就将局部变量refcnt_result的值返回，也即是1。

如果table.refcnts.find(this)读出来的值不是0，则会把查找的结果做向右偏移的操作然后+1，返回给调用方：

refcnt_result += it->second >> SIDE_TABLE_RC_SHIFT;

以上，就是进行retainCount操作时，系统对获取对象引用计数的具体实现原理。

dealloc

- (void)dealloc {
    _objc_rootDealloc(self);
}

void
_objc_rootDealloc(id obj)
{
    assert(obj);

    obj->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);
    }
}

以上是dealloc的方法调用栈，从最后一个方法开始看，在这个方法中有一个if判断条件比较多：

  • 首先判断有没有使用非指针型isa（nonpointer_isa）
  • 判断是否有weak指针指向它
  • 判断是否有关联对象
  • 判断内部实现是否涉及到有C++相关的内容
  • 当前对象的引用计数是否是通过SideTable来维护的

只有当当前对象既不是nonpointer_isa，也没有弱引用，还没有涉及到C++、关联对象、没有使用SideTable存储相关引用计数，才会调用C函数free()进行释放，否则，就调用object_dispose()对象清除函数进行清除。

再来看object_dispose()函数的实现：

id 
object_dispose(id obj)
{
    if (!obj) return nil;

    objc_destructInstance(obj);    
    free(obj);

    return nil;
}


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;
}

先来看objc_destructInstance函数，如果obj对象存在的话，会先判断当前对象是否有用到涉及到C++相关的东西，如果有，稍后会调用object_cxxDestruct函数进行销毁操作。

还会判断当前对象是否拥有关联对象，如果有的话稍后就会调用_object_remove_assocations函数进行清除操作，所以我们并不需要在dealloc方法中显式的清除关联对象。

最后会调用obj的clearDeallocating函数，函数实现如下：

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());
}

其会调用两个函数，分别是：

  • sidetable_clearDeallocating()
  • clearDeallocating_slow()

（1）sidetable_clearDeallocating()函数实现如下：

void 
objc_object::sidetable_clearDeallocating()
{
    SideTable& table = SideTables()[this];

    // clear any weak table items
    // clear extra retain count and deallocating bit
    // (fixme warn or abort if extra retain count == 0 ?)
    table.lock();
    RefcountMap::iterator it = table.refcnts.find(this);
    if (it != table.refcnts.end()) {
        if (it->second & SIDE_TABLE_WEAKLY_REFERENCED) {
            weak_clear_no_lock(&table.weak_table, (id)this);
        }
        table.refcnts.erase(it);
    }
    table.unlock();
}

其中还会调用weak_clear_no_lock()函数，实现如下：

void 
weak_clear_no_lock(weak_table_t *weak_table, id referent_id) 
{
    objc_object *referent = (objc_object *)referent_id;

    weak_entry_t *entry = weak_entry_for_referent(weak_table, referent);
    if (entry == nil) {
        /// XXX shouldn't happen, but does with mismatched CF/objc
        //printf("XXX no entry for clear deallocating %p\n", referent);
        return;
    }

    // zero out references
    weak_referrer_t *referrers;
    size_t count;
    
    if (entry->out_of_line()) {
        referrers = entry->referrers;
        count = TABLE_SIZE(entry);
    } 
    else {
        referrers = entry->inline_referrers;
        count = WEAK_INLINE_COUNT;
    }
    
    for (size_t i = 0; i < count; ++i) {
        objc_object **referrer = referrers[i];
        if (referrer) {
            if (*referrer == referent) {
                *referrer = nil;
            }
            else if (*referrer) {
                _objc_inform("__weak variable at %p holds %p instead of %p. "
                             "This is probably incorrect use of "
                             "objc_storeWeak() and objc_loadWeak(). "
                             "Break on objc_weak_error to debug.\n", 
                             referrer, (void*)*referrer, (void*)referent);
                objc_weak_error();
            }
        }
    }
    
    weak_entry_remove(weak_table, entry);
}

weak_clear_no_lock函数有两个参数，weak_table及referent_id。

weak_table就是弱引用表，记录了指向该对象的弱引用指针。

referent_id就是当前正在被销毁的对象。

这里会把referent_id强转成objc_object类型的结构体指针，记做referent，根据referent到weak_table中获取entry，进而通过weak_entry_t获取弱引用数组referrers，绕后遍历这个referrers数组，将指向该对象的弱引用指针全部置为nil，最后从weak_table中把这个entry删除。

所以，当一个对象有一个弱引用指针指向它的时候，当这个对象被废弃之后它的弱引用指针会被自动置为nil。

（2）clearDeallocating_slow()函数实现如下：

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();
}

table.refcnts.erase(this);函数的主要作用是从引用计数表中擦除该对象的引用计数。

总结一下，当对象被释放时，也就是在系统的dealloc方法实现中，系统会销毁该对象所使用的C++相关的内容，还会删除该对象的关联对象，并且将指向该对象的弱引用指针全部置为nil，这些操作完成后，会从全局的引用计数表中擦除该对象的引用计数。

以上，就是dealloc的实现原理。

内存管理方案

分类

  • TaggedPointer
    针对于小对象，如NSNumber、NSDate等。
  • NONPOINTER_ISA
    对于64位架构下的应用程序采用这种内存管理方案，在64位架构下，ISA指针占64个bit位，实际上有32位或40位就够用了，剩余的是浪费的，Apple为了提高内存的利用率，在剩余的bit位当中存储一些关于内存管理的数据内容，也被称为非指针型的isa。
  • 散列表
    包括引用计数表和弱引用表。

NONPOINTER_ISA

arm64架构
arm64架构
  • indexed
    0：代表它是一个纯的isa指针，里面的内容直接代表当前对象的类对象的地址。
    1：代表isa指针里面存储的不仅是类对象的地址，还有一些内存管理的数据。
  • has_assoc
    当前对象是否有关联对象
    0：没有
    1：有
  • has_cxx_dtor
    当前对象是否有使用到C++语言方面的内容
  • 后续33位
    当前对象的类对象的指针地址
  • magic
    略，不影响分析
  • weakly_referenced
    当前对象是否有弱引用指针
  • deallocating
    表示当前对象是否在进行dealloc操作
  • has_sidetable_rc
    指当前isa指针当中如果所存储的引用计数已经达到了上限的话，需要外挂一个sidetable这样的数据结构去存储相关的引用计数内容。
  • extra_rc
    额外的引用计数，当引用计数在一个很小的值得范围内就会存到isa指针当中，而不是由单独的引用计数表去存储引用计数，

散列表方式

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);
};

在非嵌入式系统中，SideTables管理着64个SideTable，每个SideTable有3个元素：

  • spinlock_t自旋锁
  • RefcountMap引用计数表
  • weak_table_t弱引用表

为什么不是一个SideTable，而是由多个SideTable组成SideTables？

如果使用一个SideTable管理系统所有对象的引用计数，那么当我们在多线程中对其中一个对象进行retain、release等操作时就会对这个SideTable加锁，以此保证数据访问的安全，那么在这个过程中实际上就产生了效率的问题，下一个对象要想进行操作（比如修改引用计数），就必须要等锁释放只会才能操作这张表，如果成千上万个对象同操作一张表，那么效率是极其低下的。

系统为了解决效率低下的问题，系统引入了分离锁的技术方案，我们可以把对象所对应的引用计数表可以分拆成多个部分，比如可以分拆成8个，那么就会对8个表分别加锁，假如A对象属于表1，B对象属于表2，那么此时就可以进行并行操作，提高了访问效率。

如何实现快速分流？

指通过一个对象的指针，如何快速定位到它属于哪张SideTable？

SideTable的本质是一张Hash表，这张Hash表中可能有64张具体的SideTable用以存储不同对象的引用计数表和弱引用表。

Hash表的key是对象指针经过hash函数计算出一个值，这个值决定对象所属的SideTable是哪一个，或者说在数组中（SideTables）的位置是第几个。

Hash查找

eg:给定值是对象的内存地址，目标值是数组（SideTables）下标索引。

f(ptr) = (uintptr_t)ptr % array.count

其他涉及到的技术

  • spinlock_t slock;自旋锁
  • RefcountMap refcnts;引用计数表
  • weak_table_t weak_table;弱引用表

spinlock_t

  • 自旋锁是一种忙等的锁，指当前锁已经被其他线程获取，当前线程会不断探测这个锁是否有被释放，如果被释放掉自己会第一时间获取这个锁。
    • 信号量是如果获取不到这个锁的时候，会把自己线程进行阻塞休眠，等到其他线程释放这个锁的时候唤醒当前线程。
  • 适用于轻量访问，因为对于引用计数的操作只是简单的+1 -1操作，这种操作都是轻量的操作，所以在轻量的访问场景下，都可以使用自旋锁。

RefcountMap

实际上是一个Hash表，可以通过对象的指针查找到对应的引用计数，查找的过程也是哈希查找，提高查找效率。

  • size_t共有64位
    • 第一位是weakly_referenced，表示对象是否有弱引用，0就是没有，1就是有。
    • 第二位是deallocating，表示当前对象是否正在dealloc。
    • 其余位存储的就是对象的实际引用计数值，具体的引用计数值实际上要偏移两位，因为前面有两位是weakly_referenced和deallocating，我们要把这两位去掉。

weak_table_t

实际上也是一张Hash表，key为对象指针，value为weak_entry_t，weak_entry_t是一个结构体数组，数组存储的每一个对象就是弱引用指针，也就是在代码中定义的__weak变量，这个变量的指针就存储在weak_entry_t中。

完。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 199,393评论 5赞 467
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 83,790评论 2赞 376
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 146,391评论 0赞 330
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 53,703评论 1赞 270
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 62,613评论 5赞 359
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,003评论 1赞 275
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,507评论 3赞 390
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,158评论 0赞 254
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,300评论 1赞 294
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,256评论 2赞 317
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,274评论 1赞 328
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 32,984评论 3赞 316
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,569评论 3赞 303
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,662评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,899评论 1赞 255
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,268评论 2赞 345
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 41,840评论 2赞 339

推荐阅读更多精彩内容