runtime-闲聊内存管理
（点击上方公众号，可快速关注）
来源：伯乐在线 - 林欣达
如需转载，发送「转载」二字查看说明
ARC作为一个老生常谈的话题，基本被网上的各种博客说尽了。但是前段时间朋友通过某些手段对YYModel进行了优化，提高了大概1/3左右的效率，在观赏过他改进的源码之后我又重新看了一遍ARC相关的实现源码，主要体现ARC机制的几个方法分别是retain、release以及dealloc，主要与strong和weak两者相关
ARC的内存管理
来看看一段ARC环境下的代码
- (void)viewDidLoad{
NSArray *titles= @[@"title1",@"title2"];
在编译期间，代码就会变成这样：
- (void)viewDidLoad{
NSArray *titles= @[@"title1",@"title2"];
[titles retain];
/// .......
[titles release];
简单来说就是ARC在代码编译阶段，会自动在代码的上下文中成对插入retain以及release，保证引用计数能够正确管理内存。如果对象不是强引用类型，那么ARC的处理也会进行相应的改变
下面会分别说明在这几个与引用计数相关的方法调用中发生了什么
强引用有retain、strong以及__strong三种修饰，默认情况下，所有的类对象会自动被标识为__strong强引用对象，强引用对象会在上下文插入retain以及release调用，从runtime源码处可以下载到对应调用的源代码。在retain调用的过程中，总共涉及到了四次调用：
id _objc_rootRetain(id obj)对传入对象进行非空断言，然后调用对象的rootRetain()方法
id objc_object::rootRetain()断言非GC环境，如果对象是TaggedPointer指针，不做处理。TaggedPointer是苹果推出的一套优化方案，具体可以参考深入了解Tagged Pointer一文
id objc_object::sidetable_retain()增加引用计数，具体往下看
id objc_object::sidetable_retain_slow(SideTable& table)增加引用计数，具体往下看
在上面的几步中最重要的步骤就是最后两部的增加引用计数，在NSObject.mm中可以看到函数的实现。这里笔者剔除了部分不相关的代码：
#define SIDE_TABLE_WEAKLY_REFERENCED (1UL,size_t,true& RefcountM
structSideTable{
spinlock_t slock;
RefcountMap refcnts;
weak_table_t weak_table;
id objc_object::sidetable_retain()
// 获取对象的table对象
SideTable& table= SideTables()[this];
if(table.trylock()){
// 获取 引用计数的引用
size_t& refcntStorage= table.refcnts[this];
if(! (refcntStorage& SIDE_TABLE_RC_PINNED)){
// 如果引用计数未越界，则引用计数增加
refcntStorage+= SIDE_TABLE_RC_ONE;
table.unlock();
return(id)this;
returnsidetable_retain_slow(table);
SideTable这个类包含着一个自旋锁slock来防止操作时可能出现的多线程读取问题、一个弱引用表weak_table以及引用计数表refcnts。另外还提供一个方法传入对象地址来寻找对应的SideTable对象
RefcountMap对象通过散列表的结构存储了对象持有者的地址以及引用计数，这样一来，即便对象对应的内存出现错误，例如Zombie异常，也能定位到对象的地址信息
每次retain后以后引用计数的值实际上增加了(1 而不是我们所知的1，这是由于引用计数的后两位分别被弱引用以及析构状态两个标识位占领，而第一位用来表示计数是否越界。
由于引用计数可能存在越界情况（SIDE_TABLE_RC_PINNED位的值为1），因此散列表refcnts中应该存储了多个引用计数，sidetable_retainCount()函数也证明了这一点：
#define SIDE_TABLE_RC_SHIFT 2
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()){
refcnt_result+= it-&second&& SIDE_TABLE_RC_SHIFT;
table.unlock();
returnrefcnt_result;
引用计数总是返回1 + 计数表总计这个数值，这也是为什么经常性的当对象被释放后，我们获取retainCount的值总不能为0。至于函数sidetable_retain_slow的实现和sidetable_retain几乎一样，就不再介绍了
release调用有着跟retain类似的四次调用，前两次调用的作用一样，因此这里只放上引用计数减少的函数代码：
uintptr_t objc_object::sidetable_release(boolperformDealloc)
#if SUPPORT_NONPOINTER_ISA
assert(!isa.indexed);
SideTable& table= SideTables()[this];
booldo_dealloc= false;
if(table.trylock()){
RefcountMap::iterator it= table.refcnts.find(this);
if(it== table.refcnts.end()){
do_dealloc= true;
table.refcnts[this]= SIDE_TABLE_DEALLOCATING;
}elseif(it-&second second|= SIDE_TABLE_DEALLOCATING;
}elseif(! (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);
returndo_dealloc;
returnsidetable_release_slow(table,performDealloc);
在release中决定对象是否会被dealloc有两个主要的判断
如果引用计数为计数表中的最后一个，标记对象为正在析构状态，然后执行完成后发送SEL_dealloc消息释放对象
即便计数表的值为零，sidetable_retainCount函数照样会返回1的值。这时计数小于宏定义SIDE_TABLE_DEALLOCATING == 1，就不进行减少计数的操作，直接标记对象正在析构
看到release的代码就会发现在上面代码中宏定义SIDE_TABLE_DEALLOCATING体现出了苹果这个心机婊的用心之深。通常而言，即便引用计数只有8位的占用，在剔除了首位越界标记以及后两位后，其最大取值为2^5-1 == 31位。通常来说，如果不是项目中block不加限制的引用，是很难达到这么多的引用量的。因此占用了SIDE_TABLE_DEALLOCATING位不仅减少了额外占用的标记变量内存，还能以作为引用计数是否归零的判断
最开始的时候没打算讲weak这个修饰，不过因为dealloc方法本身涉及到了弱引用对象置空的操作，以及retain过程中的对象也跟weak有关系的情况下，简单的说说weak的操作
boolobjc_object::sidetable_isWeaklyReferenced()
boolresult= false;
SideTable& table= SideTables()[this];
table.lock();
RefcountMap::iterator it= table.refcnts.find(this);
if(it!= table.refcnts.end()){
result= it-&second& SIDE_TABLE_WEAKLY_REFERENCED;
table.unlock();
returnresult;
weak和strong共用一套引用计数设计，因此两者的赋值操作都要设置计数表，只是weak修饰的对象的引用计数对象会被设置SIDE_TABLE_WEAKLY_REFERENCED位，并且不参与sidetable_retainCount函数中的计数计算而已
voidobjc_object::sidetable_setWeaklyReferenced_nolock()
#if SUPPORT_NONPOINTER_ISA
assert(!isa.indexed);
SideTable& table= SideTables()[this];
table.refcnts[this]|= SIDE_TABLE_WEAKLY_REFERENCED;
另一个弱引用设置方法，相比上一个方法去掉了自旋锁加锁操作
dealloc是重量级的方法之一，不过由于函数内部调用层次过多，这里不多阐述。实现代码在objc-object.h的798行，可以自行到官网下载源码后研读
__unsafe_unretained
其实写了这么多，终于把本文的主角给讲出来了。在iOS5的时候，苹果正式推出了ARC机制，伴随的是上面的weak、strong等新修饰符，当然还有一个不常用的__unsafe_unretained
weak修饰的对象在指向的内存被释放后会被自动置为nil
strong持有指向的对象，会让引用计数+1
__unsafe_unretained不引用指向的对象。但在对象内存被释放掉后，依旧指向内存地址，等同于assign，但是只能修饰对象
在机器上保证应用能保持在55帧以上的速率会让应用看起来如丝绸般顺滑，但是稍有不慎，稍微降到50~55之间都有很大的可能展现出卡顿的现象。这里不谈及图像渲染、数据大量处理等耳闻能详的性能恶鬼，说说Model所造成的损耗。
如前面所说的，在ARC环境下，对象的默认修饰为strong，这意味着这么一段代码：
@protocol RegExpCheck
@property(nonatomic,copy)NSString *regExp;
- (BOOL)validRegExp;
- (BOOL)valid: (NSArray& *)params{
for(id item inparams){
if(![item validRegExp]){returnNO;}
returnYES;
把这段代码改为编译期间插入retain和release方法后的代码如下：
- (BOOL)valid: (NSArray& *)params{
for(id item inparams){
[item retain];
if(![item validRegExp]){
[item release];
[item release];
returnYES;
遍历操作在项目中出现的概率绝对排的上前列，那么上面这个方法在调用期间会调用params.count次retain和release函数。通常来说，每一个对象的遍历次数越多，这些函数调用的损耗就越大。如果换做__unsafe_unretained修饰对象，那么这部分的调用损耗就被节省下来，这也是笔者朋友改进的手段
首先要承认，相比起其他性能恶鬼改进的优化，使用__unsafe_unretained带来的收益几乎微乎其微，因此笔者并不是很推荐用这种高成本低回报的方式优化项目，起码在性能恶鬼大头解决之前不推荐，但是去学习内存管理底层的知识可以帮助我们站在更高的地方看待开发。最后送上朋友的轮子
觉得本文对你有帮助？请分享给更多人
关注「 iOS大全 」
看更多精选 iOS 技术文章
责任编辑：
声明：该文观点仅代表作者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。
今日搜狐热点java面试题(2)--JVM
1.JVM内存管理的机制
　　内存空间划分为：Sun JDK在实现时遵照JVM规范，将内存空间划分为堆、JVM方法栈、方法区、本地方法栈、PC寄存器。
堆： 堆用于存储对象实例及数组值，可以认为Java中所有通过new创建的对象的内存都在此分配，Heap中对象所占用的内存由GC进行回收，在32位操作系统上最大为2GB，在64位操作系统上则没有限制，其大小可通过-Xms和-Xmx来控制，-Xms为JVM启动时申请的最小Heap内存，默认为物理内存的1/64但小于1GB；-Xmx为JVM可申请的最大Heap内存，默认为物理内存的1/4但小于1GB，默认当空余堆内存小于40%时，JVM会增大Heap到-Xmx指定的大小，可通过-XX:MinHeapFreeRatio=来指定这个比例；当空余堆内存大于70%时，JVM会减小Heap的大小到-Xms指定的大小，可通过-XX:MaxHeapFreeRatio=来指定这个比例，对于运行系统而言，为避免在运行时频繁调整Heap 的大小，通常将-Xms和-Xmx的值设成一样。
JVM方法栈： 为线程私有，其在内存分配上非常高效。当方法运行完毕时，其对应的栈帧所占用的内存也会自动释放。当JVM方法栈空间不足时，会抛出StackOverflowError的错误，在Sun JDK中可以通过-Xss来指定其大小。
方法区： 要加载的类的信息（名称、修饰符等）、类中的静态变量、类中定义为final类型的常量、类中的Field信息、类中的方法信息。方法区域也是全局共享的，在一定条件下它也会被GC，当方法区域要使用的内存超过其允许的大小时，会抛出OutOfMemory的错误信息。在Sun JDK中这块区域对应Permanet Generation，又称为持久代，默认最小值为16MB，最大值为64MB，可通过-XX:PermSize及-XX:MaxPermSize来指定最小值和最大值。
本地方法栈： 用于支持native方法的执行，存储了每个native方法调用的状态。在Sun JDK的实现中，和JVM方法栈是同一个。
PC寄存器： 占用的可能为CPU寄存器或操作系统内存。
2.Java堆和栈的区别
　　Java把内存划分成两种：一种是栈内存，一种是堆内存。
　　在函数中定义的一些基本类型的变量和对象的引用变量都在函数的栈内存中分配。当在一段代码块定义一个变量时，Java就在栈中为这个变量分配内存空间，当超过变量的作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。
　　堆内存用来存放由new创建的对象和数组。在堆中分配的内存，由Java虚拟机的自动垃圾回收器来管理。在堆中产生了一个数组或对象后，还可以在栈中定义一个特殊的变量，让栈中这个变量的取值等于数组或对象在堆内存中的首地址，在栈中的这个特殊的变量就变成了数组或者对象的引用变量，以后就可以在程序中使用栈内存中的引用变量来访问堆中的数组或者对象，引用变量相当于为数组或者对象起的一个别名，或者代号。
　　引用变量是普通变量，定义时在栈中分配内存，引用变量在程序运行到作用域外释放。而数组＆对象本身在堆中分配，即使程序运行到使用new产生数组和对象的语句所在地代码块之外，数组和对象本身占用的堆内存也不会被释放，数组和对象在没有引用变量指向它的时候，才变成垃圾，不能再被使用，但是仍然占着内存，在随后的一个不确定的时间被垃圾回收器释放掉。这个也是java比较占内存的主要原因。但是在写程序的时候，可以人为的控制。
3.Java内存泄露和内存溢出
　　内存泄漏：分配出去的内存回收不了
　　内存溢出：指系统内存不够用了
4.Java类加载机制
　　JVM将类加载过程划分为三个步骤：装载、链接和初始化。
装载（Load）：装载过程负责找到二进制字节码并加载至JVM中，JVM通过类的全限定名（com.bluedavy. HelloWorld）及类加载器（ClassLoaderA实例）完成类的加载；
链接（Link）：链接过程负责对二进制字节码的格式进行校验、初始化装载类中的静态变量及解析类中调用的接口、类；
初始化（Initialize）：执行类中的静态初始化代码、构造器代码及静态属性的初始化。
5.内存回收
　　收集器：引用计数收集器、跟踪收集器
引用计数收集器：对于Java这种面向对象的会形成复杂引用关系(如ObjectB和ObjectC互相引用)的语言而言，引用计数收集器不是非常适合，Sun JDK在实现GC时也未采用这种方式。
跟踪收集器实现算法：复制（Copying）、标记-清除（Mark-Sweep）和标记-压缩（Mark-Compact）
　　复制：当要回收的空间中存活对象较少时，复制算法会比较高效，其带来的成本是要增加一块空的内存空间及进行对象的移动。
　　标记-清除：在空间中存活对象较多的情况下较为高效，但由于标记-清除采用的为直接回收不存活对象所占用的内存，因此会造成内存碎片。
　　标记-压缩：在标记-清除的基础上还须进行对象的移动，成本相对更高，好处则是不产生内存碎片。
阅读(...) 评论() &把自己当成别人，把别人当成自己，把别人当成别人，把自己当成自己
iOS高级面试题(一)内存管理篇--runtime(一)
runtime:运行时机制
1. 是什么？
1.1 runtime是一套比较底层的纯C语言的API，runtime就是一个库，一个C语言库，包含了许多底层的C语言API
1.2平时我们编写的OC代码，在程序运行过程中，其实最终都是转成了runtime的C语言代码，runtime算是OC的幕后工作者，是整个OC的底层
- 1.3举个例子
oc中的代码：[Student alloc] init]经过runtime后，其实最终在底层生成C语言代码：
objc_msgSend(objc_msgSend("Student","alloc"), "init")
objc_msgSend其实就是想某个对象发送什么消息，这个函数第一个参数是类型或对象名，第二个参数是消息的名字，这些代码比较底层
2. 用过吗？怎么用？
- 2.1 runtime是属于OC的底层，可以进行一些非常底层的操作（用OC无法实现的，或者说不好实现）eg
- *在程序运行过程中，动态创建一个类，（比如KVO和KVC的底层实现）
- *在程序运行过程中，动态为某个类添加属性／方法，修改属性值，修改方法
- *遍历一个类中所有的属性和实例变量和所有方法
3.1相关的头文件
- #import //消息发送机制，可以直接用底层函数，进行消息发送
3.2相关应用
- *NSCoding（归档和解挡）
*字典转模型（利用runtime遍历模型对象的所有属性，根据属性名从字典中取出对应的值，设置到模型的属性上）
- *kvo（利用runtime动态产生一个类）
- 3.3相关函数
msg_send:给对象发送消息，来自
class_copyMethodList,遍历某个类中所有的方法，来自
class_copyIvarList,遍历某个类中所有的实例变量的方法，来自
运行时必备常识：
1.Ivar：成员变量的意思
2.Method：成员方法的意思
3.property:属性
你使用过Objective-C的运行时编程（Runtime Programming）么？如果使用过，你用它做了什么？你还能记得你所使用的相关的头文件或者某些方法的名称吗？
runtime 运行时的动态添加属性方法，
动态添加 set 方法
OBJC_EXPORT void objc_setAssociatedObject(id object, const void *key, id value, objc_AssociationPolicy policy)
动态添加 get 方法
OBJC_EXPORT id objc_getAssociatedObject(id object, const void *key) __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_1);
具体方法使用如下
#import &UIKit/UIKit.h&
@interface UIControl (ReName)
@property (nonatomic, copy) NSString *reN
UIControl+ReName.m
#import "UIControl+ReName.h"
#import &objc/runtime.h&
static const char * RENAME_CONST = "RECONST";
@implementation UIControl (ReName)
-(void)setReName:(NSString *)reName
objc_setAssociatedObject(self, RENAME_CONST, reName, OBJC_ASSOCIATION_COPY_NONATOMIC);
-(NSString *)reName
return objc_getAssociatedObject(self, RENAME_CONST);
使用方法如下
- (void)viewDidLoad {
[super viewDidLoad];
UIButton *button = [UIButton buttonWithType:UIButtonTypeCustom];
button.reName = @"my name is new button";
NSLog(@"%@",button.reName);
常用的方法使用名称
// 1.获得类中的所有成员变量
Ivar*ivarList =class_copyIvarList([selfclass], &count);
//2.获得方法的名字的字符串
NSSelectorFromString(_cmd)
//3.发送消息函数
objc_msgSend（）
runtim 运行时 动态归档方法代码如下
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
Student *student = [[Student alloc] init];
student.name1 = @"sunlin";
student.age = 18;
student.name2 = @"sunlin";
student.name3 = @"sunlin";
student.name4 = @"sunlin";
student.name5 = @"sunlin";
student.name6 = @"sunlin";
student.name7 = @"sunlin";
NSString *filePath = [NSHomeDirectory()stringByAppendingPathComponent:@"person.archiver"];
if (![[NSFileManager defaultManager]fileExistsAtPath:filePath]) {
NSMutableData *data = [NSMutableData data];
NSKeyedArchiver *archiver = [[NSKeyedArchiver alloc]initForWritingWithMutableData:data];
[archiver encodeObject:student forKey:@"student"];
[archiver finishEncoding];
BOOL success = [data writeToFile:filePath atomically:YES];
if (success) {
NSLog(@"归档成功！");
NSData *data = [NSData dataWithContentsOfFile:filePath];
NSKeyedUnarchiver *unArchiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:data];
Student *studentFromSaving = [unArchiver decodeObjectForKey:@"student"];
NSLog(@"%@, %lu", studentFromSaving.name7, studentFromSaving.age);
return YES;
#import &Foundation/Foundation.h&
@interface Student : NSObject&NSCoding&
@property (nonatomic, assign) NSInteger
@property (nonatomic, copy) NSString *name1;
@property (nonatomic, copy) NSString *name2;
@property (nonatomic, copy) NSString *name3;
@property (nonatomic, copy) NSString *name4;
@property (nonatomic, copy) NSString *name5;
@property (nonatomic, copy) NSString *name6;
@property (nonatomic, copy) NSString *name7;
#import "Student.h"
#import &objc/runtime.h&
@implementation Student
-(void)encodeWithCoder:(NSCoder *)aCoder
unsigned int count = 0;
Ivar *ivars = class_copyIvarList([self class], &count);
for (int i = 0; i & i++) {
Ivar ivar = ivars[i];
const char *name =ivar_getName(ivar);
NSString *nameStr = [NSString stringWithCString:name encoding:NSUTF8StringEncoding];
id value = [self valueForKey:nameStr];
[aCoder encodeObject:value forKey:nameStr];
free(ivars);
-(instancetype)initWithCoder:(NSCoder *)aDecoder{
if (self = [super init]) {
unsigned int count = 0;
Ivar *ivars = class_copyIvarList([self class], &count);
for (int i = 0; i & i++) {
Ivar ivar = ivars[i];
const char *name = ivar_getName(ivar);
NSString *key = [NSString stringWithCString:name encoding:NSUTF8StringEncoding];
id value = [aDecoder decodeObjectForKey:key];
[self setValue:value forKey:key];
free(ivars);
return self;
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！志在千里 始于跬步
Objective-C runtime机制(5)——iOS 内存管理
当我们创建一个对象时：
SWHunter *hunter = [[SWHunter alloc] init];
上面这行代码在栈上创建了hunter指针，并在堆上创建了一个SWHunter对象。目前，iOS并不支持在栈上创建对象。
iOS 内存分区
iOS的内存管理是基于虚拟内存的。虚拟内存能够让每一个进程都能够在逻辑上“独占”整个设备的内存。关于虚拟内存，可以参考这里。
iOS又将虚拟内存按照地址由低到高划分为如下五个区：
- 代码区： 存放APP二进制代码
- 常量区：存放程序中定义的各种常量， 包括字符串常量，各种被const修饰的常量
- 全局/静态区: 全局变量，静态变量就放在这里
- 堆区：在程序运行时调用alloc，copy，mutablecopy，new会在堆上分配内存。堆内存需要程序员手动释放，这在ARC中是通过引用计数的形式表现的。堆分配地址不连续，但整体是地址从低到高地址分配
- 栈区：存放局部变量，当变量超出作用域时，内存会被系统自动释放。栈上的地址连续分配，在内存地址由高向低增长
在程序运行时，代码区，常量区以及全局静态区的大小是固定的，会变化的只有栈和堆的大小。而栈的内存是有操作系统自动释放的，我们平常说所的iOS内存引用计数，其实是就堆上的对象来说的。
下面，我们就来看一下，在runtime中，是如何通过引用计数来管理内存的。
首先，来想这么一个问题，在平常的编程中，我们使用的NSNumber对象来表示数字，最大会有多大？几万？几千万？甚至上亿？
我相信，对于绝大多数程序来说，用不到上亿的数字。同样，对于字符串类型，绝大多数时间，字符个数也在8个以内。
再想另一个方面，自2013年苹果推出iphone5s之后，iOS的寻址空间扩大到了64位。我们可以用63位来表示一个数字（一位做符号位），这是一个什么样的概念？2^31=，也达到了20多亿，而2^63这个数字，用到的概率基本为零。比如NSNumber *num=@10000的话，在内存中则会留下很多无用的空位。这显然浪费了内存空间。
苹果当然也发现了这个问题，于是就引入了tagged pointer。tagged pointer是一种特殊的“指针”，其特殊在于，其实它存储的并不是地址，而是真实的数据和一些附加的信息。
在引入tagged pointer 之前，iOS对象的内存结构如下所示（摘自唐巧博客）：
显然，本来4字节就可以表示的数值，现在却用了8字节，明显的内存浪费。而引入了tagged pointer 后, 其内存布局如下
可以看到，利用tagged pointer后，“指针”又存储了对本身，也存储了和对象相关的标记。这时的tagged pointer里面存储的不是地址，而是一个数据集合。同时，其占用的内存空间也由16字节缩减为8字节。
我们可以在WWDC2013的《Session 404 Advanced in Objective-C》视频中，看到苹果对于Tagged Pointer特点的介绍：
Tagged Pointer专门用来存储小的对象，例如NSNumber, NSDate, NSString。
Tagged Pointer指针的值不再是地址了，而是真正的值。所以，实际上它不再是一个对象了，它只是一个披着对象皮的普通变量而已。所以，它的内存并不存储在堆中，也不需要malloc和free。
在内存读取上有着3倍的效率，创建时比以前快106倍。
运行如下代码：
NSMutableString *mutableStr = [NSMutableString string];
NSString *immutable =
#define _OBJC_TAG_MASK (1UL&&63)
char c = 'a';
[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。也就是说，标志位是2的tagger pointer表示这是一个NSString对象。
在runtime源码的objc-internal.h中，有关于标志位的定义如下：
OBJC_TAG_NSAtom
OBJC_TAG_1
OBJC_TAG_NSString
OBJC_TAG_NSNumber
OBJC_TAG_NSIndexPath
OBJC_TAG_NSManagedObjectID = 5,
OBJC_TAG_NSDate
OBJC_TAG_RESERVED_7
OBJC_TAG_First60BitPayload = 0,
OBJC_TAG_Last60BitPayload
OBJC_TAG_First52BitPayload = 8,
OBJC_TAG_Last52BitPayload
OBJC_TAG_RESERVED_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 的概念就好了。有兴趣的同学可以看，但其内容也有些过时了，和我们的实验结果并不一致。
我们顺便看一下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的值，而对于最后一位，应该是一个标志位，具体作用，笔者也不是很清楚。
由于一个tagged pointer所指向的并不是一个真正的OC对象，它其实是没有isa属性的。
在runtime中，可以这样获取isa的内容：
#define _OBJC_TAG_SLOT_SHIFT 60
#define _OBJC_TAG_EXT_SLOT_MASK 0xff
inline Class
objc_object::getIsa()
if (!isTaggedPointer()) return ISA();
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& {
OBJC_ISA_AVAILABILITY;
typedef struct objc_class *C
struct objc_class : objc_object {
class_data_bits_
struct objc_object {
union isa_t
isa_t() { }
isa_t(uintptr_t value) : bits(value) { }
# if __arm64__
define ISA_MASK
0x0000000ffffffff8ULL
define ISA_MAGIC_MASK
0x000001ULL
define ISA_MAGIC_VALUE 0x000001ULL
uintptr_t nonpointer
uintptr_t has_assoc
uintptr_t has_cxx_dtor
uintptr_t shiftcls
uintptr_t magic
uintptr_t weakly_referenced : 1;
uintptr_t deallocating
uintptr_t has_sidetable_rc
uintptr_t extra_rc
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来访问。
联合的作用在于，用更少的空间，表示了更多的可能的类型，虽然这些类型是不能够共存的。
将注意力集中在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，则完全是逻辑上的区分，在内存空间上，其实是一个东西。
即uintptr_t bits 和 struct 是一个东西的两种表现形式。
实际上在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位的指针表示一个类型，显然不划算。
因此，绝大多数情况下，苹果采用了优化的isa策略，即，isa_t类型并不等同而Class cls, 而是struct。这种情况对于我们自己创建的类对象以及系统对象都是如此，稍后我们会对这一结论进行验证。
先让我们集中精力来看一下struct的结构 ：
# if __arm64__
define ISA_MASK
0x0000000ffffffff8ULL
define ISA_MAGIC_MASK
0x000001ULL
define ISA_MAGIC_VALUE 0x000001ULL
uintptr_t nonpointer
uintptr_t has_assoc
uintptr_t has_cxx_dtor
uintptr_t shiftcls
uintptr_t magic
uintptr_t weakly_referenced : 1;
uintptr_t deallocating
uintptr_t has_sidetable_rc
uintptr_t extra_rc
define RC_ONE
(1ULL&&45)
define RC_HALF
(1ULL&&18)
struct共占用64位，从低位到高位依次是nonpointer到extra_rc。成员后面的：表明了该成员占用几个bit。成员的含义如下：
nonpointer
标志位。1(奇数)表示开启了isa优化，0(偶数)表示没有启用isa优化。所以，我们可以通过判断isa是否为奇数来判断对象是否启用了isa优化。
标志位。表明对象是否有关联对象。没有关联对象的对象释放的更快。
has_cxx_dtor
标志位。表明对象是否有C++或ARC析构函数。没有析构函数的对象释放的更快。
类指针的非零位。
固定为0x1a，用于在调试时区分对象是否已经初始化。
weakly_referenced
标志位。用于表示该对象是否被别的对象弱引用。没有被弱引用的对象释放的更快。
deallocating
标志位。用于表示该对象是否正在被释放。
has_sidetable_rc
标志位。用于标识是否当前的引用计数过大，无法在isa中存储，而需要借用sidetable来存储。（这种情况大多不会发生）
对象的引用计数减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万多，相信绝大多数情况下，都够用了。
现在，我们来真正的验证一下，我们上述的结论。注意，做验证试验时，必须要使用真机，因为模拟器默认是不开启isa优化的。
要做验证试验，我们必须要得到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 :
isa_t isa;
因此，我们又可以将objc_object 替换为isa_t。得到：
obj == isa_t **
最终，得出结论：
obj是一个指向isa_t类型指针的指针。
得出了这个结论，我们就可以通过obj打印出isa_t中存储的内容了：
NSLog(@"isa_t = %p", *(void **)(__bridge void*)obj);
我们的实验代码如下：
@interface MyObj : NSObject
@implementation MyObj
@interface ViewController ()
@property(nonatomic, strong) MyObj *obj1;
@property(nonatomic, strong) MyObj *obj2;
@property(nonatomic, weak) MyObj *weakRefO
@implementation ViewController
- (void)viewDidLoad {
[super viewDidLoad];
MyObj *obj = [[MyObj alloc] init];
NSLog(@"1. obj isa_t = %p", *(void **)(__bridge void*)obj);
MyObj *tmpObj =
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);
其输出为：
直观的可以看到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);
对应的输出内容为0x1a:
大家可以在图中直观的看到isa_t此时各位的内容，注意到extra_rc此时为0，因为引用计数等于extra_rc + 1，因此，MyObj对象的引用计数为1，和我们的预期一致。
接下来执行
MyObj *tmpObj =
NSLog(@"2. obj isa_t = %p", *(void **)(__bridge void*)obj);
由于_obj1对MyObj对象是强引用，同时，tmpObj的赋值也默认是强引用，obj的引用计数加2，应该等于3。
输出为0x41a ：
引用计数等于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);
输出为 0x1a:
引用计数等于extra_rc + 1 = 0 + 1 = 1, 符合预期。
接下来我们又赋值了一个强引用_obj2, 引用计数加1，等于2。
_obj2 = _obj1;
NSLog(@"4. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
输出为0x21a :
引用计数等于extra_rc + 1 = 1 + 1 = 2, 符合预期。
接下来，我们又将MyObj对象赋值给一个weak引用，此时，引用计数应该保持不变，但是weakly_referenced位应该置1。
_weakRefObj = _obj1;
NSLog(@"5. obj isa_t = %p", *(void **)(__bridge void*)_obj1);
输出0x25a:
可以看到引用计数仍是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。
其实在绝大多数情况下，仅用优化的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)
if (isTaggedPointer()) return (id)this;
bool transcribeToSideTable = false;
transcribeToSideTable = false;
oldisa = LoadExclusive(&isa.bits);
if (slowpath(!newisa.nonpointer)) {
return sidetable_retain();
if (slowpath(tryRetain && newisa.deallocating)) {
return nil;
newisa.bits = addc(newisa.bits, RC_ONE, 0, &carry);
if (slowpath(carry)) {
if (!handleOverflow) {
return rootRetain_overflow(tryRetain);
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)) {
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中。
在runtime中，通过SideTable来管理对象的引用计数以及weak引用。这里要注意，一张SideTable会管理多个对象，而并非一个。
而这一个个的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)) % StripeC
注意到这个SideTables哈希数组是全局的，因此，对于我们APP中所有的对象的引用计数，也就都存在于这64个SideTable中。
具体到每个SideTable， 其中有存储了若干对象的引用计数。SideTable 的定义如下：
struct SideTable {
weak_table_t weak_
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类型。
value，size_t类型。
是否清除为vlaue==0的数据，true。
DisguisedPtr中的采样方法是：
static uintptr_t disguise(T* ptr) {
return -(uintptr_t)
static uintptr_t disguise(objc_object* ptr) {
return -(uintptr_t)
所以，对象引用计数map RefcountMap的key是：-(object *)，就是对象地址取负。value就是该对象的引用计数。
我们来看一下OC是如何获取对象引用计数的：
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();
sidetable_unlock();
return sidetable_retainCount();
可以看到，runtime在获取对象引用计数的时候，是考虑了三种情况:(1)tagged pointer, (2)优化的isa, (3)未优化的isa。
我们来看一下(2)优化的isa 的情况下：
首先，会读取extra_rc中的数据，因为extra_rc中存储的是引用计数减一，所以这里要加回去。
如果extra_rc 不够大的话，还需要读取sidetable，调用sidetable_getExtraRC_nolock：
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
// MSB-ward of weak bit
所以，在sidetable中做加引用加一操作时，需要在第3位上+1：
#define SIDE_TABLE_RC_ONE
// 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 {
weak_table_t weak_
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_
uintptr_t max_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
#define WEAK_INLINE_COUNT 4
#define REFERRERS_OUT_OF_LINE 2
struct weak_entry_t {
DisguisedPtr&objc_object&
weak_referrer_t *
out_of_line_ness : 2;
num_refs : PTR_MINUS_2;
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] = newR
for (int i = 1; i & WEAK_INLINE_COUNT; i++) {
inline_referrers[i] =
根据注释，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_
uintptr_t max_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_
if (!weak_entries) return
size_t begin = hash_pointer(referent) & weak_table-&
size_t index =
size_t hash_displacement = 0;
while (weak_table-&weak_entries[index].referent != referent) {
index = (index+1) & weak_table-&
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 &weak_table-&weak_entries[index];
首先，确定hash值可能对应的数组下标begin：
size_t begin = hash_pointer(referent) & weak_table-&
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)
这个算法不用深究，知道就是一个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-&
if (index == begin) bad_weak_table(weak_table-&weak_entries);
hash_displacement++;
if (hash_displacement & weak_table-&max_hash_displacement) {
这里，产生了hash冲突后，系统会依次线性循环寻找目标对象的位置。直到找了一圈又回到了起点或大于了可能的hash冲突值。这个max_hash_displacement值是在每个元素插入的时候更新的，它总是记录在插入时，所发生的hash冲突的最大值。因此在查找时，hash冲突的次数肯定不会大于这个值。
这里最巧妙的是这条语句：
index = (index+1) & weak_table-&mask
它即会让你向下一个相邻位置寻找，同时当寻找到最后一个位置时，它又会自动让你从数组的第一个位置开始寻找。这一切，都归功于二进制运算的巧妙运用。
hash表自动扩容
这里的weak table的大小是不固定的。当插入新元素时，会调用weak_grow_maybe方法，来判断是否要做hash表的扩容。该方法实现如下：
#define TABLE_SIZE(entry) (entry-&mask ? entry-&mask + 1 : 0)
static void weak_grow_maybe(weak_table_t *weak_table)
size_t old_size = TABLE_SIZE(weak_table);
if (weak_table-&num_entries &= old_size * 3 / 4) {
weak_resize(weak_table, old_size ? old_size*2 : 64);
这里的扩容会调用weak_resize方法。每次扩容都会是原有长度的一倍。这样，每次扩容的新增空间都会比上一次要大一倍，而不是固定的扩容n个空间。这么做的目的在于，系统认为，当你有扩容需求时，之后又扩容需求的概率就会变大，为了防止频繁的申请内存，所以，每次扩容强度都会比上一次要大。
hash表自动收缩
当从weak table中删除元素时，系统会调用weak_compact_maybe判断是否需要收缩hash数组的空间 :
static void weak_compact_maybe(weak_table_t *weak_table)
size_t old_size = TABLE_SIZE(weak_table);
if (old_size &= 1024
&& old_size / 16 &= weak_table-&num_entries) {
weak_resize(weak_table, old_size / 8);
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_
weak_entry_t *new_entries = (weak_entry_t *)
calloc(new_size, sizeof(weak_entry_t));
weak_table-&mask = new_size - 1;
weak_table-&weak_entries = new_
weak_table-&max_hash_displacement = 0;
weak_table-&num_entries = 0;
if (old_entries) {
weak_entry_t *
weak_entry_t *end = old_entries + old_
for (entry = old_ entry & 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_
assert(weak_entries != nil);
size_t begin = hash_pointer(new_entry-&referent) & (weak_table-&mask);
size_t index =
size_t hash_displacement = 0;
while (weak_entries[index].referent != nil) {
index = (index+1) & weak_table-&
if (index == begin) bad_weak_table(weak_entries);
hash_displacement++;
weak_entries[index] = *new_
weak_table-&num_entries++;
if (hash_displacement & weak_table-&max_hash_displacement) {
weak_table-&max_hash_displacement = hash_
OK, 上面就是对runtime中weak引用的相关数据结构的分析。关于weak引用数据，是存在于hash表中的。
这关于hash算法映射到数组下标，以及hash表动态的扩容/收缩，还是很有意思的。
autoreleasepool
在iOS中，除了需要手动retain，release（现在已经交给了ARC自动生成）外，我们还可以将对象扔到自动释放池中，由自动释放池来自动管理这些对象。我们可以这样使用autoreleasepool：
int main(int argc, char * argv[]) {
@autoreleasepool {
NSString *a =
[NSString stringWithFormat:@"%d", 1];
用clang -rewrite-objc 重写后，得到：
int main(int argc, char * argv[]) {
{ __AtAutoreleasePool __
NSString *a = ((NSString * _Nonnull (*)(id, SEL, NSString * _Nonnull, ...))(void *)objc_msgSend)((id)objc_getClass("NSString"), sel_registerName("stringWithFormat:"), (NSString *)&__NSConstantStringImpl__var_folders_8k_3pbszhls2czcmz0w335cvc0w0000gn_T_main_1a8fc0_mi_1, 1);
这时会发现，
@autoreleasepool 被改写为了
__AtAutoreleasePool __autoreleasepool这样一个对象。__AtAutoreleasePool的定义为：
struct __AtAutoreleasePool {
__AtAutoreleasePool() {atautoreleasepoolobj = objc_autoreleasePoolPush();}
~__AtAutoreleasePool() {objc_autoreleasePoolPop(atautoreleasepoolobj);}
于是，关于@autoreleasepool的代码可以被改写为：
objc_autoreleasePoolPush();
objc_autoreleasePoolPop(atautoreleasepoolobj);
置于@autoreleasepool的{}中的代码实际上是被一个push和pop操作所包裹。当push时，会压栈一个autoreleasepage，在{}中的所有的autorelease对象都会放到这个page中。当pop时，会出栈一个autoreleasepage，同时，所有存储于这个page的对象都会做release操作。这就是autoreleasepool的实现原理。
objc_autoreleasePoolPush()和objc_autoreleasePoolPop(atautoreleasepoolobj)的实现如下：
objc_autoreleasePoolPush(void)
return AutoreleasePoolPage();
objc_autoreleasePoolPop(void *ctxt)
AutoreleasePoolPage(ctxt);
它们都分别调用了AutoreleasePoolPage类的静态方法push和pop。AutoreleasePoolPage 是runtime中autoreleasepool的核心实现，下面，我们就来了解一下它。
AutoreleasePoolPage
AutoreleasePoolPage在runtime中的定义如下：
class AutoreleasePoolPage
magic_t const
pthread_t const
AutoreleasePoolPage * const parent;
AutoreleasePoolPage *
uint32_t const
每个AutoreleasePoolPage的大小为一个SIZE，即内存管理中一个页的大小。这在Mac中是4KB，而在iOS中，这里没有相关代码，估计差不多。
对象指针栈
由源码可用看出，在AutoreleasePoolPage 类中共有7个成员属性，大小为56Bytes，按照一个Page是4KB计算，显然还有4040Bytes没有用。而这4040Bytes空间，就用来存储AutoreleasePoolPage所管理的对象指针。因此，一个AutoreleasePoolPage的内存布局如下图(摘自)：
在autoreleasepool中的对象指针是按照栈的形式存储的，栈低是一个POOL_BOUNDARY哨兵，之后对象指针依次入栈存储。
POOL_BOUNDARY
在图中可用看到，除了AutoreleasePoolPage 类中的7个成员之外，还有一个叫POOL_BOUNDARY, 其实这是一个nil指针，AutoreleasePoolPage中的next指针用来指向栈中下一个入栈位置。
define POOL_BOUNDARY nil
它作为一个哨兵，当需要将AutoreleasePoolPage 中存储的对象指针依次出栈时，会执行到POOL_BOUNDARY为止。
在图中也可以看出，单个的AutoreleasePoolPage是以栈的形式存储的。
当加入到autoreleasepool中的元素太多时，一个AutoreleasePoolPage 就不够用的了。这时候我们需要新创建一个AutoreleasePoolPage ，多个AutoreleasePoolPage之间通过双向链表的形式串起来。
成员parent和child就是用来构造双向链表的。
下面我们就结合具体的代码，来看一下AutoreleasePoolPage是如何在系统中发挥作用的。
当用户调用@autoreleasepool{}的时候，系统首先会调用AutoreleasePoolPage::push()方法，来创建或获取当前的hotPage，并向对象栈中插入一个POOL_BOUNDARY。
static inline void *push()
dest = autoreleaseFast(POOL_BOUNDARY);
assert(dest == EMPTY_POOL_PLACEHOLDER || *dest == POOL_BOUNDARY);
我们也可以调用autorelease(id obj)方法将某个特定的对象指针插入到AutoreleasePoolPage中：
static inline id autorelease(id obj)
assert(obj);
assert(!obj-&isTaggedPointer());
id *dest __unused = autoreleaseFast(obj);
assert(!dest
dest == EMPTY_POOL_PLACEHOLDER
*dest == obj);
可以看到，无论是push还是autorelease方法，最后都是调用了autoreleaseFast(obj)，该方法会将一个id放入到autoreleasePage中。：
static inline id *autoreleaseFast(id obj)
AutoreleasePoolPage *page = hotPage();
if (page && !page-&full()) {
return page-&add(obj);
} else if (page) {
return autoreleaseFullPage(obj, page);
return autoreleaseNoPage(obj);
可以看到方法实现逻辑也很简单：
首先取出当前的hotPage，所谓hotPage，就是在autoreleasePage链表中正在使用的autoreleasePage节点。
如果有hotPage，且hotPage还没满，这将obj加入到page中。
如果有hotPage，但是已经满了，则进入page full逻辑（autoreleaseFullPage）。
如果没有hotPage，进入no page逻辑autoreleaseNoPage。
hotPage是autoreleasePage链表中正在使用的autoreleasePage节点。实质上是指向autoreleasepage的指针，并存储于线程的TSD(线程私有数据：Thread-specific Data)中：
static inline AutoreleasePoolPage *hotPage()
AutoreleasePoolPage *result = (AutoreleasePoolPage *)
tls_get_direct(key);
if ((id *)result == EMPTY_POOL_PLACEHOLDER) return
if (result) result-&fastcheck();
return result;
从这段代码可以看出，
autoreleasepool是和线程绑定的，一个线程对应一个autoreleasepool。而autoreleasepool虽然叫做自动释放池，其实质上是一个双向链表。
在介绍runloop的时候，我们也曾提到过，runloop和线程也是一一对应的，并且在当前线程的runloop指针，也会存储到线程的TSD中。这是runtime对于TSD的一个应用。
add object
如果有hot page，先判断page 是否已经full了，判断逻辑是next*是否等于end()：
bool full() {
return next == end();
关于begin()和end()，定义如下，结合page的图示，应该比较容易理解：
id * begin() {
return (id *) ((uint8_t *)this+sizeof(*this));
id * end() {
return (id *) ((uint8_t *)this+SIZE);
如果page没有满，这调用page的add方法：
id *add(id obj)
assert(!full());
id *ret = next;
// faster than `return next-1` because of aliasing
逻辑比较简单，就是将obj置于next的位置，next++，然后返回obj的位置。
autoreleaseFullPage
如果hot page满了，就需要在链表中‘加页’，同时将新页置为hot page：
static __attribute__((noinline))
id *autoreleaseFullPage(id obj, AutoreleasePoolPage *page)
assert(page == hotPage());
assert(page-&full()
DebugPoolAllocation);
if (page-&child) page = page-&
else page = new AutoreleasePoolPage(page);
} while (page-&full());
setHotPage(page);
return page-&add(obj);
这一段代码重点需要关注的是寻找可用page的do while逻辑。
其实注释中已经写得很清楚，系统会首先尝试在hot page的child pages中挑出第一个没有满的page，如果没有符合要求的child page，则只能创建一个新的new AutoreleasePoolPage(page)。
最后，将挑选出的page作为当前线程的hot page （实际上存储到了TSD中），并将obj存到新的hot page中。
autoreleaseNoPage
若当前线程没有hot Page，则说明当前的线程还未建立起autorelease pool 。这时，就会调用autoreleaseNoPage：
static __attribute__((noinline))
id *autoreleaseNoPage(id obj)
assert(!hotPage());
bool pushExtraBoundary = false;
if (haveEmptyPoolPlaceholder()) {
pushExtraBoundary = true;
}else if (obj == POOL_BOUNDARY
!DebugPoolAllocation) {
return setEmptyPoolPlaceholder();
AutoreleasePoolPage *page = new AutoreleasePoolPage(nil);
setHotPage(page);
if (pushExtraBoundary) {
page-&add(POOL_BOUNDARY);
return page-&add(obj);
当系统发现当前线程没有对应的autoreleasepool时，我们自然的想到需要为线程创建一个page。但是苹果其实在这里是耍了一个小心机的，当在创建第一个page时，苹果并不会真正创建一个page，因为它害怕创建了page后，并没有真正的object需要插入page，这样就造成了无谓的内存浪费。
在没有第一个真正的object入栈之前，苹果是这样做的：仅仅在线程的TSD中做了一个EMPTY_POOL_PLACEHOLDER标记，并返回它。这里没有真正的new 一个AutoreleasePoolPage。
当autoreleasepool需要被释放时，会调用Pop方法。而Pop方法需要接受一个void *token参数，来告诉池子，需要一直释放到token对应的那个page：
static inline void pop(void *token)
AutoreleasePoolPage *
if (token == (void*)EMPTY_POOL_PLACEHOLDER) {
if (hotPage()) {
pop(coldPage()-&begin());
setHotPage(nil);
page = pageForPointer(token);
stop = (id *)
if (*stop != POOL_BOUNDARY) {
if (stop == page-&begin()
!page-&parent) {
return badPop(token);
page-&releaseUntil(stop);
if (page-&child) {
if (page-&lessThanHalfFull()) {
page-&child-&kill();
else if (page-&child-&child) {
page-&child-&child-&kill();
何时需要autoreleasePool
OK，以上就是autoreleasepool的内容。那么在ARC的环境下，我们何时需要用@autoreleasepool呢？
一般的，有下面两种情况：
创建子线程。当我们创建子线程的时候，需要将子线程的runloop用@autoreleasepool包裹起来，进而达到自动释放内存的效果。因为系统并不会为子线程自动包裹一个@autoreleasepool，这样加入到autoreleasepage中的元素就得不到释放。
在大循环中创建autorelease对象。当我们在一个循环中创建autorelease对象(不是用alloc创建的对象)，该对象会加入到autoreleasepage中，而这个page中的对象，会等到外部池子结束才会释放。在主线程的runloop中，会将所有的对象的释放权都交给了RunLoop 的释放池，而RunLoop的释放池会等待这个事件处理之后才会释放，因此就会使对象无法及时释放，堆积在内存造成内存泄露。关于这一点，可以参考博客
没有更多推荐了，
加入CSDN，享受更精准的内容推荐，与500万程序员共同成长！