Objective-C runtime机制(5.1)——iOS 内存管理

概述

当我们创建一个对象时：

SWHunter *hunter = [[SWHunter alloc] init];

上面这行代码在栈上创建了hunter指针，并在堆上创建了一个SWHunter对象。目前，iOS并不支持在栈上创建对象。

iOS 内存分区

iOS的内存管理是基于虚拟内存的。虚拟内存能够让每一个进程都能够在逻辑上“独占”整个设备的内存。关于虚拟内存，可以参考这里。

iOS又将虚拟内存按照地址由低到高划分为如下五个区：

这里写图片描述
  • 代码区： 存放APP二进制代码
  • 常量区：存放程序中定义的各种常量， 包括字符串常量，各种被const修饰的常量
  • 全局/静态区: 全局变量，静态变量就放在这里
  • 堆区：在程序运行时调用alloc，copy，mutablecopy，new会在堆上分配内存。堆内存需要程序员手动释放，这在ARC中是通过引用计数的形式表现的。堆分配地址不连续，但整体是地址从低到高地址分配
  • 栈区：存放局部变量，当变量超出作用域时，内存会被系统自动释放。栈上的地址连续分配，在内存地址由高向低增长

在程序运行时，代码区，常量区以及全局静态区的大小是固定的，会变化的只有栈和堆的大小。而栈的内存是有操作系统自动释放的，我们平常说所的iOS内存引用计数，其实是就堆上的对象来说的。

下面，我们就来看一下，在runtime中，是如何通过引用计数来管理内存的。

tagged pointer

首先，来想这么一个问题，在平常的编程中，我们使用的NSNumber对象来表示数字，最大会有多大？几万？几千万？甚至上亿？

我相信，对于绝大多数程序来说，用不到上亿的数字。同样，对于字符串类型，绝大多数时间，字符个数也在8个以内。

再想另一个方面，自2013年苹果推出iphone5s之后，iOS的寻址空间扩大到了64位。我们可以用63位来表示一个数字（一位做符号位），这是一个什么样的概念？231=2147483648，也达到了20多亿，而263这个数字，用到的概率基本为零。比如NSNumber *num=@10000的话，在内存中则会留下很多无用的空位。这显然浪费了内存空间。

苹果当然也发现了这个问题，于是就引入了tagged pointer。tagged pointer是一种特殊的“指针”，其特殊在于，其实它存储的并不是地址，而是<font color=orange>真实的数据和一些附加的信息</font>。

在引入tagged pointer 之前，iOS对象的内存结构如下所示（摘自唐巧博客）：

[图片上传失败...(image-a44d7c-1548215032013)]

显然，本来4字节就可以表示的数值，现在却用了8字节，明显的内存浪费。而引入了tagged pointer 后, 其内存布局如下

这里写图片描述

可以看到，利用tagged pointer后，“指针”又存储了对本身，也存储了和对象相关的标记。这时的tagged pointer里面存储的不是地址，而是一个数据集合。同时，其占用的内存空间也由16字节缩减为8字节。

我们可以在WWDC2013的《Session 404 Advanced in Objective-C》视频中，看到苹果对于Tagged Pointer特点的介绍：

  1. Tagged Pointer专门用来存储小的对象，例如NSNumber, NSDate, NSString。
  2. Tagged Pointer指针的值不再是地址了，而是真正的值。所以，实际上它不再是一个对象了，它只是一个披着对象皮的普通变量而已。所以，它的内存并不存储在堆中，也不需要malloc和free。
  3. 在内存读取上有着3倍的效率，创建时比以前快106倍。

运行如下代码：

    NSMutableString *mutableStr = [NSMutableString string];
    NSString *immutable = nil;
    #define _OBJC_TAG_MASK (1UL<<63)
    char c = 'a';
    do {
        [mutableStr appendFormat:@"%c", c++];
        immutable = [mutableStr copy];
        NSLog(@"%p %@ %@", immutable, immutable, immutable.class);
    }while(((uintptr_t)immutable & _OBJC_TAG_MASK) == _OBJC_TAG_MASK);

输出为：

这里写图片描述

我们看到，字符串由‘a’增长到‘abcdefghi’的过程中，其地址开头都是0xa 而结尾也很有规律，是1到9递增，正好对应着我们的字符串长度，同时，其输出的class类型为NSTaggedPointerString。在字符串长度在9个以内时，iOS其实使用了tagged pointer做了优化的。

直到字符串长度大于9，字符串才真正成为了__NSCFString类型。

我们回头分析一下上面的代码。
首先，iOS需要一个标志位来判断当前指针是真正的指针还是tagged pointer。这里有一个宏定义_OBJC_TAG_MASK (1UL<<63) ，它表明如果64位数据中，最高位是1的话，则表明当前是一个tagged pointer类型。

然后，既然使用了tagged pointer，那么就失去了iOS对象的数据结构，但是，系统还是需要有个标志位表明当前的tagged pointer 表示的是什么类型的对象。这个标志位，也是在最高4位来表示的。我们将0xa转换为二进制，得到
1010，其中最高位1xxx表明这是一个tagged pointer，而剩下的3位010，表示了这是一个NSString类型。010转换为十进制即为2。也就是说，<font color=red>标志位是2的tagger pointer表示这是一个NSString对象。</font>

在runtime源码的objc-internal.h中，有关于标志位的定义如下：

{
    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, 
    OBJC_TAG_RESERVED_7        = 7, 

    OBJC_TAG_First60BitPayload = 0, 
    OBJC_TAG_Last60BitPayload  = 6, 
    OBJC_TAG_First52BitPayload = 8, 
    OBJC_TAG_Last52BitPayload  = 263, 

    OBJC_TAG_RESERVED_264      = 264
};

最后，让我们再尝试分析一下NSString类型的tagged pointer是如何实现的。

我们前面已经知道，在总共64位数据中，高4位被用于标志tagged pointer以及对象类型标识。低1位用于记录字符串字符个数，那么还剩下59位可以让我们表示数据内容。

对于字符串格式，怎么来表示内容呢？自然的，我们想到了ASCII码。对应ASCII码，a用16进制ASCII码表示为0x61，b为0x62, 依次类推。在字符串长度增加到8个之前，tagged pointer的内容如下。可以看到，从最低2位开始，分别为61，62，63... 这正对应了字符串中字符的ASCII码。

这里写图片描述

直到字符串增加到7个之上，我们仍然可以分辨出tagged pointer中的标志位以及字符串长度，但是中间的内容部分，却不符合ASCII的编码规范了。

这里写图片描述

这是因为，iOS对字符串使用了压缩算法，使得tagged pointer表示的字符串长度最大能够达到9个。关于具体的压缩算法，我们就不再讨论了。由于苹果内部会对实现逻辑作出修改，因此我们只要知道有tagged pointer 的概念就好了。有兴趣的同学可以看采用Tagged Pointer的字符串，但其内容也有些过时了，和我们的实验结果并不一致。

我们顺便看一下NSNumber的tagged pointer实现：

    NSNumber *number1 = @(0x1);
    NSNumber *number2 = @(0x20);
    NSNumber *number3 = @(0x3F);
    NSNumber *numberFFFF = @(0xFFFFFFFFFFEFE);
    NSNumber *maxNum = @(MAXFLOAT);
    NSLog(@"number1 pointer is %p class is %@", number1, number1.class);
    NSLog(@"number2 pointer is %p class is %@", number2, number2.class);
    NSLog(@"number3 pointer is %p class is %@", number3, number3.class);
    NSLog(@"numberffff pointer is %p class is %@", numberFFFF, numberFFFF.class);
    NSLog(@"maxNum pointer is %p class is %@", maxNum, maxNum.class);
这里写图片描述

可以看到，对于MAXFLOAT，系统无法进行优化，输出的是一个正常的NSNumber对象地址。而对于其他的number值，系统采用了tagged pointer，其‘地址’都是以0xb开头，转换为二进制就是1011， 首位1表示这是一个tagged pointer，而011转换为十进制是3，参考前面tagged pointer的类型枚举，这是一个NSNumber类型。接下来几位，就是以16进制表示的NSNumber的值，而对于最后一位，应该是一个标志位，具体作用，笔者也不是很清楚。

isa

由于一个tagged pointer所指向的并不是一个真正的OC对象，它其实是没有isa属性的。

在runtime中，可以这样获取isa的内容：

#define _OBJC_TAG_SLOT_SHIFT 60
#define _OBJC_TAG_EXT_SLOT_MASK 0xff

inline Class 
objc_object::getIsa() 
{
    // 如果不是tagged pointer，则返回ISA()
    if (!isTaggedPointer()) return ISA();

    // 如果是tagged pointer，取出高4位的内容，查找对应的class
    uintptr_t ptr = (uintptr_t)this;
      
    uintptr_t slot = (ptr >> _OBJC_TAG_SLOT_SHIFT) & _OBJC_TAG_SLOT_MASK;
    return objc_tag_classes[slot];
    
}

在runtime中，还有专用的方法用于判断指针是tagged pointer还是普通指针：

#   define _OBJC_TAG_MASK (1UL<<63)
static inline bool 
_objc_isTaggedPointer(const void * _Nullable ptr) 
{
    return ((uintptr_t)ptr & _OBJC_TAG_MASK) == _OBJC_TAG_MASK;
}

isa 指针（NONPOINTER_ISA）

对象的isa指针，用来表明对象所属的类类型。
但是如果isa指针仅表示类型的话，对内存显然也是一个极大的浪费。于是，就像tagged pointer一样，对于isa指针，苹果同样进行了优化。isa指针表示的内容变得更为丰富，除了表明对象属于哪个类之外，还附加了引用计数extra_rc，是否有被weak引用标志位weakly_referenced，是否有附加对象标志位has_assoc等信息。

这里，我们仅关注isa中和内存引用计数有关的extra_rc 以及相关内容。

首先，我们回顾一下isa指针是怎么在一个对象中存储的。下面是runtime相关的源码：

@interface NSObject <NSObject> {
    Class isa  OBJC_ISA_AVAILABILITY;
}

typedef struct objc_class *Class;

// ============ 注意！从这一行开始，其定义就和在XCode中objc.h看到的定义不一致，我们需要阅读runtime的源码，才能看到其真实的定义！下面是简化版的定义：============
struct objc_class : objc_object {
    Class superclass;
    cache_t cache;             // formerly cache pointer and vtable
    class_data_bits_t bits;    // class_rw_t * plus custom rr/alloc flags
}

 
struct objc_object {
private:
    isa_t isa;
}

union isa_t 
{
    isa_t() { }
    isa_t(uintptr_t value) : bits(value) { }

    Class cls;
    uintptr_t bits;

# if __arm64__
#   define ISA_MASK        0x0000000ffffffff8ULL
#   define ISA_MAGIC_MASK  0x000003f000000001ULL
#   define ISA_MAGIC_VALUE 0x000001a000000001ULL
    struct {
        uintptr_t nonpointer        : 1;
        uintptr_t has_assoc         : 1;
        uintptr_t has_cxx_dtor      : 1;
        uintptr_t shiftcls          : 33; // MACH_VM_MAX_ADDRESS 0x1000000000
        uintptr_t magic             : 6;
        uintptr_t weakly_referenced : 1;
        uintptr_t deallocating      : 1;
        uintptr_t has_sidetable_rc  : 1;
        uintptr_t extra_rc          : 19;
#       define RC_ONE   (1ULL<<45)
#       define RC_HALF  (1ULL<<18)
    };
}

结合下面的图，我们可以更清楚的了解runtime中对象和类的结构定义，显然，类也是一种对象，这就是类对象的含义。

这里写图片描述

从图中可以看出，我们所谓的isa指针，最后实际上落脚于isa_t的联合类型。联合类型 是C语言中的一种类型，简单来说，就是一种n选1的关系。比如isa_t 中包含有cls，bits， struct三个变量，它们的内存空间是重叠的。在实际使用时，仅能够使用它们中的一种，你把它当做cls，就不能当bits访问，你把它当bits，就不能用cls来访问。

<font color=orange>联合的作用在于，用更少的空间，表示了更多的可能的类型，虽然这些类型是不能够共存的。</font>

将注意力集中在isa_t联合上，我们该怎样理解它呢？

首先它有两个构造函数isa_t(), isa_t(uintptr_value), 这两个定义很清晰，无需多言。

然后它有三个数据成员Class cls, uintptr_t bits, struct 。 其中uintptr_t被定义为typedef unsigned long uintptr_t，占据64位内存。

关于上面三个成员， uintptr_t bits 和 struct 其实是一个成员，它们都占据64位内存空间，之前已经说过，联合类型的成员内存空间是重叠的。在这里，由于uintptr_t bits 和 struct 都是占据64位内存，因此它们的内存空间是完全重叠的。而你将这块64位内存当做是uintptr_t bits 还是 struct，则完全是逻辑上的区分，在内存空间上，其实是一个东西。
<font color=blue>即uintptr_t bits 和 struct 是一个东西的两种表现形式。</font>

实际上在runtime中，任何对struct 的操作和获取某些值，如extra_rc，实际上都是通过对uintptr_t bits 做位操作实现的。uintptr_t bits 和 struct 的关系可以看做，uintptr_t bits 向外提供了操作struct 的接口，而struct 本身则说明了uintptr_t bits 中各个二进制位的定义。

理解了uintptr_t bits 和 struct 关系后，则isa_t其实可以看做有两个可能的取值，Class cls或struct。如下图所示：

这里写图片描述

当isa_t作为Class cls使用时，这符合了我们之前一贯的认知：isa是一个指向对象所属Class类型的指针。然而，仅让一个64位的指针表示一个类型，显然不划算。

因此，<font color=blue>绝大多数情况下，苹果采用了优化的isa策略，即，isa_t类型并不等同而Class cls, 而是struct。</font>这种情况对于我们自己创建的类对象以及系统对象都是如此，稍后我们会对这一结论进行验证。

先让我们集中精力来看一下struct的结构 ：

# if __arm64__
#   define ISA_MASK        0x0000000ffffffff8ULL
#   define ISA_MAGIC_MASK  0x000003f000000001ULL
#   define ISA_MAGIC_VALUE 0x000001a000000001ULL
    struct {
        uintptr_t nonpointer        : 1;
        uintptr_t has_assoc         : 1;
        uintptr_t has_cxx_dtor      : 1;
        uintptr_t shiftcls          : 33; // MACH_VM_MAX_ADDRESS 0x1000000000
        uintptr_t magic             : 6;
        uintptr_t weakly_referenced : 1;
        uintptr_t deallocating      : 1;
        uintptr_t has_sidetable_rc  : 1;
        uintptr_t extra_rc          : 19;
#       define RC_ONE   (1ULL<<45)
#       define RC_HALF  (1ULL<<18)
    };

struct共占用64位，从低位到高位依次是nonpointer到extra_rc。成员后面的：表明了该成员占用几个bit。成员的含义如下：

成员 位 含义
nonpointer 1bit 标志位。1(奇数)表示开启了isa优化，0(偶数)表示没有启用isa优化。所以，我们可以通过判断isa是否为奇数来判断对象是否启用了isa优化。
has_assoc 1bit 标志位。表明对象是否有关联对象。没有关联对象的对象释放的更快。
has_cxx_dtor 1bit 标志位。表明对象是否有C++或ARC析构函数。没有析构函数的对象释放的更快。
shiftcls 33bit 类指针的非零位。
magic 6bit 固定为0x1a，用于在调试时区分对象是否已经初始化。
weakly_referenced 1bit 标志位。用于表示该对象是否被别的对象弱引用。没有被弱引用的对象释放的更快。
deallocating 1bit 标志位。用于表示该对象是否正在被释放。
has_sidetable_rc 1bit 标志位。用于标识是否当前的引用计数过大，无法在isa中存储，而需要借用sidetable来存储。（这种情况大多不会发生）
extra_rc 19bit 对象的引用计数减1。比如，一个object对象的引用计数为7，则此时extra_rc的值为6。

由上表可以看出，和对象引用计数相关的有两个成员：extra_rc和has_sidetable_rc。iOS用19位的extra_rc来记录对象的引用次数，当extra_rc 不够用时，还会借助sidetable来存储计数值，这时，has_sidetable_rc会被标志为1。

我们可以算一下，对于19位的extra_rc ，其数值可以表示2^19 - 1 = 524287。 52万多，相信绝大多数情况下，都够用了。

现在，我们来真正的验证一下，我们上述的结论。<font color=red>注意，做验证试验时，必须要使用真机，因为模拟器默认是不开启isa优化的。</font>

要做验证试验，我们必须要得到isa_t的值。在苹果提供的公共接口中，是无法获取到它的。不过，通过对象指针，我们确实是可以获取到isa_t 的值。

让我们看一下当我们创建一个对象时，实际上是获得到了什么。

NSObject *obj = [[NSObject alloc] init];

我们得到了obj这个对象，实质上obj是一个指向对象的指针， 即
obj == NSObject *。

而在NSObject中，又有唯一的成员Class isa, 而Class实质上是objc_class *。这样，我们可以用objc_class * 替换掉 NSObject，得到

obj == objc_class **

再看objc_class的定义：

struct objc_class : objc_object {
    。。。
}

objc_class 继承自objc_object， 因此，在objc_class 内存布局的首地址肯定存放的是继承自objc_object的内容。从内存布局的角度，我们可以将objc_class 替换为 objc_object 。得到：

obj == objc_object **

而objc_object 的定义如下，仅含有一个成员isa_t :

struct objc_object {
private:
    isa_t isa;
}

因此，我们又可以将objc_object 替换为isa_t。得到：

obj == isa_t **

<font color = orange>好了，这里到了关键的地方</font>，从现在看，我们得到的obj应该是一个指向 isa_t * 的指针，即 obj是一个指针的指针，obj指向一个指针。 但是，obj真的是指向了一个指针吗？

我们再来看一下isa_t的定义，我们看标志为注意！！！的地方：

# if __arm64__
#   define ISA_MASK        0x0000000ffffffff8ULL
#   define ISA_MAGIC_MASK  0x000003f000000001ULL
#   define ISA_MAGIC_VALUE 0x000001a000000001ULL
    struct {
        uintptr_t nonpointer        : 1;   // 注意！！！ 标志位，表明isa_t *是否是一个真正的指针！！！
        uintptr_t has_assoc         : 1;
        uintptr_t has_cxx_dtor      : 1;
        uintptr_t shiftcls          : 33; // MACH_VM_MAX_ADDRESS 0x1000000000
        uintptr_t magic             : 6;
        uintptr_t weakly_referenced : 1;
        uintptr_t deallocating      : 1;
        uintptr_t has_sidetable_rc  : 1;
        uintptr_t extra_rc          : 19;
#       define RC_ONE   (1ULL<<45)
#       define RC_HALF  (1ULL<<18)
    };

也就是说，当开启了isa_t优化，nonpointer 置位为1， 这时，isa_t *其实不是一个地址，而是一个实实在在有意义的值，也就是说，苹果用isa_t * 所占用的64位空间，表示了一个有意义的值，而这64位值的定义，就符合我们上面struct的定义。

这时，我们可以将isa_t *改写为isa_t，这是因为isa_t *的64位并没有指向任何地址，而是实际表示了isa_t的内容。

继续上面的公式推导，得到结论:

obj == *isa_t

哈哈，有意思吗？obj实际上是指向isa_t的指针。绕了这里大一圈，结论竟如此直白。

如果我们想得到isa_t的值，只需要做*obj操作即可，即

 NSLog(@"isa_t = %p", *obj);

之所以用%p输出，是因为我们要isa_t*本身的值，而不是要取它指向的值。

得出了这个结论，我们就可以通过obj打印出isa_t中存储的内容了（中间需要做几次类型转换，但是实质和上面是一样的）：

 NSLog(@"isa_t = %p", *(void **)(__bridge void*)obj);

我们的实验代码如下：

@interface MyObj : NSObject
@end
@implementation MyObj
@end

@interface ViewController ()
@property(nonatomic, strong) MyObj *obj1;
@property(nonatomic, strong) MyObj *obj2;
@property(nonatomic, weak) MyObj *weakRefObj;
@end

@implementation ViewController
- (void)viewDidLoad {
    [super viewDidLoad];
    MyObj *obj = [[MyObj alloc] init];
    NSLog(@"1. obj isa_t = %p", *(void **)(__bridge void*)obj);
    _obj1 = obj;
    MyObj *tmpObj = obj;
    NSLog(@"2. obj isa_t = %p", *(void **)(__bridge void*)obj);
}

- (void)viewDidAppear:(BOOL)animated {
    [super viewDidAppear:animated];
    NSLog(@"3. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
    _obj2 = _obj1;
    NSLog(@"4. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
    _weakRefObj = _obj1;
    NSLog(@"5. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
    NSObject *attachObj = [[NSObject alloc] init];
    objc_setAssociatedObject(_obj1, "attachKey", attachObj, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
    NSLog(@"6. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
}
@end

其输出为：


这里写图片描述

直观的可以看到isa_t的内容都是奇数，说明开启了isa优化。（nonpointer == 1）

接下来我们一行行的分析代码以及相应的isa_t内容变化：

首先在viewDidLoad方法中，我们创建了一个MyObj实例，并接着打印出isa_t的内容，这时候，MyObj的引用计数应该是1：

- (void)viewDidLoad {
    ...
    MyObj *obj = [[MyObj alloc] init];
    NSLog(@"1. obj isa_t = %p", *(void **)(__bridge void*)obj);
    ...
}

对应的输出内容为0x1a1000a0ff9:

这里写图片描述

大家可以在图中直观的看到isa_t此时各位的内容，注意到extra_rc此时为0，因为引用计数等于extra_rc + 1，因此，MyObj对象的引用计数为1，和我们的预期一致。

接下来执行

    _obj1 = obj;
    MyObj *tmpObj = obj;
    NSLog(@"2. obj isa_t = %p", *(void **)(__bridge void*)obj);

由于_obj1对MyObj对象是强引用，同时，tmpObj的赋值也默认是强引用，obj的引用计数加2，应该等于3。

输出为0x41a1000a0ff9 ：

这里写图片描述

引用计数等于extra_rc + 1 = 2 + 1 = 3, 符合预期。

然后，程序执行到了viewDidAppear方法，并立刻输出MyObj对象的引用计数。因为此时栈上变量obj ，tmpObj已经释放，因此引用计数应该减2，等于1。

- (void)viewDidAppear:(BOOL)animated {
    [super viewDidAppear:animated];
    NSLog(@"3. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
    ...
}

输出为 0x1a1000a0ff9:

这里写图片描述

引用计数等于extra_rc + 1 = 0 + 1 = 1, 符合预期。

接下来我们又赋值了一个强引用_obj2, 引用计数加1，等于2。

    ...
     _obj2 = _obj1;
    NSLog(@"4. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
    ...

输出为0x21a1000a0ff9 :

这里写图片描述

引用计数等于extra_rc + 1 = 1 + 1 = 2, 符合预期。

接下来，我们又将MyObj对象赋值给一个weak引用，此时，引用计数应该保持不变，但是weakly_referenced位应该置1。

    ...
    _weakRefObj = _obj1;
    NSLog(@"5. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
    ...

输出0x25a1000a0ff9:

这里写图片描述

可以看到引用计数仍是2，但是weakly_referenced位已经置位1，符合预期。

最后，我们向MyObj对象 添加了一个关联对象，此时，isa_t的其他位应该保持不变，只有has_assoc标志位应该置位1。

    ...
    NSObject *attachObj = [[NSObject alloc] init];
    objc_setAssociatedObject(_obj1, "attachKey", attachObj, OBJC_ASSOCIATION_RETAIN_NONATOMIC);
    NSLog(@"6. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
    ...

输出0x25a1000a0ffb：

这里写图片描述

可以看到，其他位保持不变，只有has_assoc被设置为1，符合预期。

OK，通过上面的分析，你现在应该很清楚rumtime里面isa究竟是怎么回事了吧？

PS: 笔者所实验的环境为iPhone5s + iOS 10。

SideTable

其实在绝大多数情况下，仅用优化的isa_t来记录对象的引用计数就足够了。只有在19位的extra_rc盛放不了那么大的引用计数时，才会借助SideTable出马。

SideTable是一个全局的引用计数表，它记录了所有对象的引用计数。

为了弄清extra_rc和sidetable的关系，我们首先看runtime添加对象引用计数时的简化代码。不过在看代码之前，我们需要弄清楚slowpath和fastpath是干啥的。

我们在runtime源码中有时候，有时在if语句中会看到类似下面这些代码：

if (fastpath(cls->canAllocFast())){
...
}

if (slowpath(!newisa.nonpointer)) {
...
}

其实将fastpath和slowpath去掉是完全不影响任何功能的。之所以将fastpath和slowpath 放到if语句中，是为了告诉编译器，if中的条件是大概率(fastpath)还是小概率(slowpath)事件，从而让编译器对代码进行优化。知道了这些，我们就可以来继续看源码了：

#       define RC_HALF  (1ULL<<18)
ALWAYS_INLINE id
objc_object::rootRetain(bool tryRetain, bool handleOverflow)
{
    // 如果是tagged pointer，直接返回this，因为tagged pointer不用记录引用次数
    if (isTaggedPointer()) return (id)this;
    // transcribeToSideTable用于表示extra_rc是否溢出，默认为false
    bool transcribeToSideTable = false;
    
    isa_t oldisa;
    isa_t newisa;
    
    do {
        transcribeToSideTable = false;
        oldisa = LoadExclusive(&isa.bits); // 将isa_t提取出来
        newisa = oldisa;
        if (slowpath(!newisa.nonpointer)) {  // 如果没有采用isa优化, 则返回sidetable记录的内容, 此处slowpath表明这不是一个大概率事件
            return sidetable_retain();
        }
        // 如果对象正在析构，则直接返回nil
        if (slowpath(tryRetain && newisa.deallocating)) {
            return nil;
        }
        // 采用了isa优化，做extra_rc++，同时检查是否extra_rc溢出，若溢出，则extra_rc减半，并将另一半转存至sidetable
        uintptr_t carry;
        newisa.bits = addc(newisa.bits, RC_ONE, 0, &carry);  // extra_rc++
        
        if (slowpath(carry)) { // 有carry值，表示extra_rc 溢出
            // newisa.extra_rc++ overflowed
            if (!handleOverflow) {  // 如果不处理溢出情况，则在这里会递归调用一次，再进来的时候，handleOverflow会被rootRetain_overflow设置为true，从而进入到下面的溢出处理流程
                return rootRetain_overflow(tryRetain);
            }
            
            // 进行溢出处理：逻辑很简单，先在extra_rc中引用计数减半，同时把has_sidetable_rc设置为true，表明借用了sidetable。然后把另一半放到sidetable中
            sideTableLocked = true;
            transcribeToSideTable = true;
            newisa.extra_rc = RC_HALF;
            newisa.has_sidetable_rc = true;
        }
    } while (slowpath(!StoreExclusive(&isa.bits, oldisa.bits, newisa.bits))); // 将oldisa 替换为 newisa，并赋值给isa.bits(更新isa_t), 如果不成功，do while再试一遍
    
    //isa的extra_rc溢出，将一半的refer count值放到sidetable中
    if (slowpath(transcribeToSideTable)) {
        // Copy the other half of the retain counts to the side table.
        sidetable_addExtraRC_nolock(RC_HALF);
    }
    
    return (id)this;
}

添加对象引用计数的源码逻辑还算清晰，重点看当extra_rc溢出后，runtime是怎么处理的。

在iOS中，extra_rc占有19位，也就是最大能够表示2^19-1, 用二进制表示就是19个1。当extra_rc等于2^19时，溢出，此时的二进制位是一个1后面跟19个0， 即10000...00。将会溢出的值2^19除以2，相当于将10000...00向右移动一位。也就等于RC_HALF(1ULL<<18)，即一个1后面跟18个0。

然后，调用

sidetable_addExtraRC_nolock(RC_HALF);

将另一半的引用计数RC_HALF放到sidetable中。

SideTable数据结构

在runtime中，通过SideTable来管理对象的引用计数以及weak引用。<font color=red>这里要注意，一张SideTable会管理多个对象，而并非一个。</font>
而这一个个的SideTable又构成了一个集合，叫SideTables。SideTables在系统中是全局唯一的。

SideTable，SideTables的关系如下图所示（这张图会随着分析的深入逐渐扩充）：

这里写图片描述

SideTables的类型是是template<typename T> class StripedMap，StripedMap<SideTable> 。我们可以简单的理解为一个64 * sizeof(SideTable) 的哈希线性数组。

每个对象可以通过StripedMap所对应的哈希算法，找到其对应的SideTable。StripedMap 的哈希算法如下，其参数是对象的地址。

static unsigned int indexForPointer(const void *p) {
        uintptr_t addr = reinterpret_cast<uintptr_t>(p);
        return ((addr >> 4) ^ (addr >> 9)) % StripeCount; // 这里 %StripeCount 保证了所有的对象对应的SideTable均在这个64长度数组中。
    }

注意到这个SideTables哈希数组是全局的，因此，对于我们APP中所有的对象的引用计数，也就都存在于这64个SideTable中。

具体到每个SideTable， 其中有存储了若干对象的引用计数。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.");
    }
};

SideTable包含三个成员：

  • spinlock_t slock ：自旋锁。防止多线程访问SideTable冲突
  • RefcountMap refcnts：用于存储对象引用计数的map
  • weak_table_t weak_table ： 用于存储对象弱引用的map

这里我们暂且不去管weak_table， 先看存储对象引用计数的成员RefcountMap refcnts。

RefcountMap类型实际是DenseMap，这是一个模板类。

typedef objc::DenseMap<DisguisedPtr<objc_object>,size_t,true> RefcountMap;

关于DenseMap的实际定义，有点复杂，暂时不想看:(

这里只需要将RefcountMap简单的的理解为是一个map，key是DisguisedPtr<objc_object>，value是对象的引用计数。同时，这个map还有个加强版功能，当引用计数为0时，会自动将对象数据清除。

这也是

objc::DenseMap<DisguisedPtr<objc_object>,size_t,true> RefcountMap

的含义，即模板类型分别对应：
key,DisguisedPtr<objc_object>类型。
value，size_t类型。
是否清除为vlaue==0的数据，true。

DisguisedPtr<objc_object>中的采样方法是：

   static uintptr_t disguise(T* ptr) {
        return -(uintptr_t)ptr;
    }
    // 将T按照模板替换为objc_object，即是：
    static uintptr_t disguise(objc_object* ptr) {
        return -(uintptr_t)ptr;
    }

所以，对象引用计数map RefcountMap的key是：-(object *)，就是对象地址取负。value就是该对象的引用计数。

我们来看一下OC是如何获取对象引用计数的：

inline uintptr_t 
objc_object::rootRetainCount()
{
    //case 1： 如果是tagged pointer，则直接返回this，因为tagged pointer是不需要引用计数的
    if (isTaggedPointer()) return (uintptr_t)this;

    // 将objcet对应的sidetable上锁
    sidetable_lock();
    isa_t bits = LoadExclusive(&isa.bits);
    ClearExclusive(&isa.bits);
    // case 2： 如果采用了优化的isa指针
    if (bits.nonpointer) {
        uintptr_t rc = 1 + bits.extra_rc; // 先读取isa.extra_rc
        if (bits.has_sidetable_rc) { // 如果extra_rc不够大， 还需要读取sidetable中的数据
            rc += sidetable_getExtraRC_nolock(); // 总引用计数= rc + sidetable count
        }
        sidetable_unlock();
        return rc;
    }
    // case 3：如果没采用优化的isa指针，则直接返回sidetable中的值
    sidetable_unlock(); // 将objcet对应的sidetable解锁，因为sidetable_retainCount()中会上锁
    return sidetable_retainCount();
}

可以看到，runtime在获取对象引用计数的时候，是考虑了三种情况:(1)tagged pointer, (2)优化的isa, (3)未优化的isa。

我们来看一下(2)优化的isa 的情况下：
首先，会读取extra_rc中的数据，因为extra_rc中存储的是引用计数减一，所以这里要加回去。
如果extra_rc 不够大的话，还需要读取sidetable，调用sidetable_getExtraRC_nolock：

#define SIDE_TABLE_RC_SHIFT 2

size_t 
objc_object::sidetable_getExtraRC_nolock()
{
    assert(isa.nonpointer);
    SideTable& table = SideTables()[this];
    RefcountMap::iterator it = table.refcnts.find(this);
    if (it == table.refcnts.end()) return 0;
    else return it->second >> SIDE_TABLE_RC_SHIFT;
}

注意，这里在返回引用计数前，还做了个右移2位的位操作it->second >> SIDE_TABLE_RC_SHIFT。这是因为在sidetable中，引用计数的低2位不是用来记录引用次数的，而是分别表示对象是否有弱引用计数，以及是否在deallocing，这估计是为了兼容未优化的isa而设计的：

#define SIDE_TABLE_WEAKLY_REFERENCED (1UL<<0)
#define SIDE_TABLE_DEALLOCATING      (1UL<<1)  // MSB-ward of weak bit

所以，在sidetable中做加引用加一操作时，需要在第3位上+1：

#define SIDE_TABLE_RC_ONE            (1UL<<2)  // MSB-ward of deallocating bit
refcntStorage += SIDE_TABLE_RC_ONE;

这里sidetable的引用计数值还有一个SIDE_TABLE_RC_PINNED 状态，表明这个引用计数太大了，连sidetable都表示不出来：

#define SIDE_TABLE_RC_PINNED         (1UL<<(WORD_BITS-1))

OK，到此为止，我们就学习完了runtime中所有的引用计数实现方式。接下来我们还会继续看和引用计数相关的两个概念：弱引用和autorelease。

Weekly reference

再来回看一下sidetable 的定义如下：

struct SideTable {
    spinlock_t slock;           // 自旋锁，防止多线程访问冲突
    RefcountMap refcnts;        // 对象引用计数map
    weak_table_t weak_table;    // 对象弱引用map
}

spinlock_t slock、RefcountMap refcnts的定义我们已经清楚，下面就来看一下weak_table_t weak_table，它记录了所有弱引用对象的集合。

weak_table_t定义如下：

/**
 * The global weak references table. Stores object ids as keys,
 * and weak_entry_t structs as their values.
 */
struct weak_table_t {
    weak_entry_t *weak_entries;        // hash数组，用来存储弱引用对象的相关信息weak_entry_t
    size_t    num_entries;             // hash数组中的元素个数
    uintptr_t mask;                    // hash数组长度-1，会参与hash计算。（注意，这里是hash数组的长度，而不是元素个数。比如，数组长度可能是64，而元素个数仅存了2个）
    uintptr_t max_hash_displacement;   // 可能会发生的hash冲突的最大次数
};

weak_table_t 包含一个weak_entry_t类型的数组，可以通过hash算法找到对应object在数组中的index。这种结构，和sidetables类似，不同的是，weak_table_t是可以动态扩展的，而不是写死的64个。

这里写图片描述

weak_entries实质上是一个hash数组，数组中存储weak_entry_t类型的元素。weak_entry_t的定义如下：

typedef DisguisedPtr<objc_object *> weak_referrer_t;

#define PTR_MINUS_2 62
/**
 * The internal structure stored in the weak references table. 
 * It maintains and stores
 * a hash set of weak references pointing to an object.
 * If out_of_line_ness != REFERRERS_OUT_OF_LINE then the set
 * is instead a small inline array.
 */
#define WEAK_INLINE_COUNT 4

// out_of_line_ness field overlaps with the low two bits of inline_referrers[1].
// inline_referrers[1] is a DisguisedPtr of a pointer-aligned address.
// The low two bits of a pointer-aligned DisguisedPtr will always be 0b00
// (disguised nil or 0x80..00) or 0b11 (any other address).
// Therefore out_of_line_ness == 0b10 is used to mark the out-of-line state.
#define REFERRERS_OUT_OF_LINE 2

struct weak_entry_t {
    DisguisedPtr<objc_object> referent; // 被弱引用的对象
    
    // 引用该对象的对象列表，联合。 引用个数小于4，用inline_referrers数组。 用个数大于4，用动态数组weak_referrer_t *referrers
    union {
        struct {
            weak_referrer_t *referrers;                      // 弱引用该对象的对象列表的动态数组
            uintptr_t        out_of_line_ness : 2;           // 是否使用动态数组标记位
            uintptr_t        num_refs : PTR_MINUS_2;         // 动态数组中元素的个数
            uintptr_t        mask;                           // 用于hash确定动态数组index，值实际上是动态数组空间长度-1（它和num_refs不一样，这里是记录的是数组中位置的个数，而不是数组中实际存储的元素个数）。
            uintptr_t        max_hash_displacement;          // 最大的hash冲突次数（说明了最多做max_hash_displacement次hash冲突，肯定会找到对应的数据）
        };
        struct {
            // out_of_line_ness field is low bits of inline_referrers[1]
            weak_referrer_t  inline_referrers[WEAK_INLINE_COUNT];
        };
    };

    bool out_of_line() {
        return (out_of_line_ness == REFERRERS_OUT_OF_LINE);
    }

    weak_entry_t& operator=(const weak_entry_t& other) {
        memcpy(this, &other, sizeof(other));
        return *this;
    }

    weak_entry_t(objc_object *newReferent, objc_object **newReferrer)
        : referent(newReferent)
    {
        inline_referrers[0] = newReferrer;
        for (int i = 1; i < WEAK_INLINE_COUNT; i++) {
            inline_referrers[i] = nil;
        }
    }
};

根据注释，DisguisedPtr方法返回的hash值得最低2个字节应该是0b00或0b11，因此可以用out_of_line_ness == 0b10来表明当前是否在使用数组或动态数组来保存引用该对象的列表。

这样，sidetable中的weak_table_t weak_table成员的结构如下所示：

这里写图片描述

回头再来看一下，会发现在weak talbe中存在两个hash 表。

一个是weak_table_t 自身。它可以通过对象地址做hash（hash_pointer(objc_object *) & weak_table->mask），直接找到weak_entries中该对象对应的weak_entry_t。

另一个是weak_entry_t中的weak_referrer_t *referrers。它可以通过弱引用该对象的对象指针的指针做hash（w_hash_pointer(objc_object **) & (entry->mask)），直接找到对象指针的指针在referrers中对应的weak_referrer_t *。

虽然weak_table_t和referrers 是表示意义不同的hash表，但他们的实现以是一样的，可以看做是同一种hash表。而且还设计的很有技巧。下面，我们就来详细学习一下hash 表示怎么实现的。

weak table的实现细节

由于weak_entries和referrers中的实现类似，这里我们就以weak_table_t为例，来分析hash表的实现。

weak_table_t定义如下：

/**
 * The global weak references table. Stores object ids as keys,
 * and weak_entry_t structs as their values.
 */
struct weak_table_t {
    weak_entry_t *weak_entries;        // hash数组，用来存储弱引用对象的相关信息weak_entry_t
    size_t    num_entries;             // hash数组中的元素个数
    uintptr_t mask;                    // hash数组长度-1，用于和hash值做位与计算，来确定数组下标。（注意，这里是hash数组的长度，而不是元素个数。比如，数组长度可能是64，而元素个数仅存了2个）
    uintptr_t max_hash_displacement;   // 可能会发生的hash冲突的最大次数
};

hash定位

当向weak_table_t 中插入或查找某个元素时，是通过如下hash算法的(以查找为例)：

static weak_entry_t *
weak_entry_for_referent(weak_table_t *weak_table, objc_object *referent)
{
    assert(referent);

    weak_entry_t *weak_entries = weak_table->weak_entries;

    if (!weak_entries) return nil;

    size_t begin = hash_pointer(referent) & weak_table->mask;
    size_t index = begin;
    size_t hash_displacement = 0;
    while (weak_table->weak_entries[index].referent != referent) {
        index = (index+1) & weak_table->mask;
        if (index == begin) bad_weak_table(weak_table->weak_entries); // 触发bad weak table crash
        hash_displacement++;
        if (hash_displacement > weak_table->max_hash_displacement) {
            return nil;
        }
    }
    
    return &weak_table->weak_entries[index];
}

首先，确定hash值可能对应的数组下标begin：

size_t begin = hash_pointer(referent) & weak_table->mask;

hash_pointer(referent)将会对referent进行hash操作：

static inline uint32_t ptr_hash(uint64_t key)
{
    key ^= key >> 4;
    key *= 0x8a970be7488fda55;
    key ^= __builtin_bswap64(key);
    return (uint32_t)key;
}

这个算法不用深究，知道就是一个hash操作就好了。

有技巧的是后半部分& weak_table->mask，将hash值和mask做位与运算。
之前说过，mask 的值等于数组长度-1。而在下面的小节你会了解到，hash数组的长度会以64，128，256规律递增。总之，数组长度表现为二进制会是1000...0这种形式，即首位1，后面跟n个0。而这个值减1的话，则会变为011...1这种形式，即首位0，后面跟n个1，这即mask的二进制形式。那么用mask & hash_pointer(referent)时，就会保留hash_pointer(referent)的后n位的值，而首位被位与操作置为了0。那么这个值肯定是小于首位是1的数值的，也就是肯定会小于数组的长度。

因此，begin是一个小于数组长度的一个数组下标，且这个下标对应着目标元素的hash值。

确定了初始的数组下标后，就开始尝试确定元素的真正位置：

 while (weak_table->weak_entries[index].referent != referent) {
        index = (index+1) & weak_table->mask; // hash冲突，做index+1，尝试下一个相邻位置，& weak_table->mask 确保了index不会越界，而且会使index自动find数组一圈
        if (index == begin) bad_weak_table(weak_table->weak_entries); // 在数组中转了一圈还没找到目标元素，触发bad weak table crash
        hash_displacement++;
        if (hash_displacement > weak_table->max_hash_displacement) { // 如果hash冲突大于了最大可能的冲突次数，则说明目标对象不存在于数组中，返回nil
            return nil;
        }
  }

这里，产生了hash冲突后，系统会依次线性循环寻找目标对象的位置。直到找了一圈又回到了起点或大于了可能的hash冲突值。这个max_hash_displacement值是在每个元素插入的时候更新的，它总是记录在插入时，所发生的hash冲突的最大值。因此在查找时，hash冲突的次数肯定不会大于这个值。

这里最巧妙的是这条语句：

index = (index+1) & weak_table->mask

<font color=orange>它即会让你向下一个相邻位置寻找，同时当寻找到最后一个位置时，它又会自动让你从数组的第一个位置开始寻找。这一切，都归功于二进制运算的巧妙运用。</font>

hash表自动扩容

这里的weak table的大小是不固定的。当插入新元素时，会调用weak_grow_maybe方法，来判断是否要做hash表的扩容。该方法实现如下：


#define TABLE_SIZE(entry) (entry->mask ? entry->mask + 1 : 0)

// Grow the given zone's table of weak references if it is full.
static void weak_grow_maybe(weak_table_t *weak_table)
{
    size_t old_size = TABLE_SIZE(weak_table);

    // Grow if at least 3/4 full.
    if (weak_table->num_entries >= old_size * 3 / 4) { // 当大于现有长度的3/4时，会做数组扩容操作。
        weak_resize(weak_table, old_size ? old_size*2 : 64);  // 初次会分配64个位置，之后在原有基础上*2
    }
}

这里的扩容会调用weak_resize方法。每次扩容都会是原有长度的一倍。这样，每次扩容的新增空间都会比上一次要大一倍，而不是固定的扩容n个空间。这么做的目的在于，系统认为，当你有扩容需求时，之后又扩容需求的概率就会变大，为了防止频繁的申请内存，所以，每次扩容强度都会比上一次要大。

hash表自动收缩

当从weak table中删除元素时，系统会调用weak_compact_maybe判断是否需要收缩hash数组的空间 :


// Shrink the table if it is mostly empty.
static void weak_compact_maybe(weak_table_t *weak_table)
{
    size_t old_size = TABLE_SIZE(weak_table);

    // Shrink if larger than 1024 buckets and at most 1/16 full.
    if (old_size >= 1024  && old_size / 16 >= weak_table->num_entries) { // 当前数组长度大于1024，且实际使用空间最多只有1/16时，需要做收缩操作
        weak_resize(weak_table, old_size / 8); // 缩小8倍
        // leaves new table no more than 1/2 full
    }
}

hash表resize

无论是扩容还是收缩，最终都会调用到weak_resize方法：

static void weak_resize(weak_table_t *weak_table, size_t new_size)
{
    size_t old_size = TABLE_SIZE(weak_table);

    weak_entry_t *old_entries = weak_table->weak_entries;  // 先把老数据取出来
    weak_entry_t *new_entries = (weak_entry_t *)   // 在为新的size申请内存
        calloc(new_size, sizeof(weak_entry_t));

    // 重置weak_table的各成员
    weak_table->mask = new_size - 1;
    weak_table->weak_entries = new_entries;
    weak_table->max_hash_displacement = 0;
    weak_table->num_entries = 0;  // restored by weak_entry_insert below
    
    if (old_entries) {
        weak_entry_t *entry;
        weak_entry_t *end = old_entries + old_size;
        for (entry = old_entries; entry < end; entry++) {
            if (entry->referent) { // 依次将老的数据插入到新的内存空间
                weak_entry_insert(weak_table, entry);
            }
        }
        free(old_entries); // 释放老的内存空间
    }
}

/** 
 * Add new_entry to the object's table of weak references.
 * Does not check whether the referent is already in the table.
 */
static void weak_entry_insert(weak_table_t *weak_table, weak_entry_t *new_entry)
{
    weak_entry_t *weak_entries = weak_table->weak_entries;
    assert(weak_entries != nil);

    size_t begin = hash_pointer(new_entry->referent) & (weak_table->mask);
    size_t index = begin;
    size_t hash_displacement = 0;
    while (weak_entries[index].referent != nil) {
        index = (index+1) & weak_table->mask;
        if (index == begin) bad_weak_table(weak_entries);
        hash_displacement++;
    }

    weak_entries[index] = *new_entry;
    weak_table->num_entries++;

    if (hash_displacement > weak_table->max_hash_displacement) { // 这里记录最大的hash冲突次数，当查找元素时，hash冲突肯定不会大于这个值
        weak_table->max_hash_displacement = hash_displacement;
    }
}

OK, 上面就是对runtime中weak引用的相关数据结构的分析。关于weak引用数据，是存在于hash表中的。
这关于hash算法映射到数组下标，以及hash表动态的扩容/收缩，还是很有意思的。

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