iOS开发基础之内存管理

使用引用计数的方式对创建的对象进行内存的管理操作；有强引用指向（retain）那么引用计数+1，强引用被置为nil(release)那么引用计数-1；对象超过作用域该对象的引用计数如果为0，则系统会清理对象占用的内存空间，目前内存管理的方式分为MRC和ARC两种.

站在用户的角度思考问题，与客户深入沟通，找到绛县网站设计与绛县网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：成都网站建设、网站制作、企业官网、英文网站、手机端网站、网站推广、空间域名、虚拟主机、企业邮箱。业务覆盖绛县地区。

当开发中遇到在某个作用域内部产生大量的autorelease对象导致内存激增，需要考虑手动创建autoreleasepool来释放局部变量的情况！

遇到这种情况，就需要排查控制器中出现的内存泄露了；

iOS面试题-内存管理篇（必问系列）

浅拷贝只是对指针的拷贝，拷贝后两个指针指向同一个内存空间，深拷贝不但对指针进行拷贝，而且对指针指向的内容进行拷贝，经深拷贝后的指针是指向两个不同地址的指针。

当对象中存在指针成员时，除了在复制对象时需要考虑自定义拷贝构造函数，还应该考虑以下两种情形：

copy方法:如果是非可扩展类对象，则是浅拷贝。如果是可扩展类对象，则是深拷贝。

mutableCopy方法:无论是可扩展类对象还是不可扩展类对象，都是深拷贝。

简单说是双向链表，每张链表头尾相接，有 parent、child指针

每创建一个池子，会在首部创建一个 哨兵 对象,作为标记

最外层池子的顶端会有一个next指针。当链表容量满了，就会在链表的顶端，并指向下一张表。

访问了悬垂指针，比如对一个已经释放的对象执行了release、访问已经释放对象的成员变量或者发消息。 死循环

CADisplayLink、NSTimer会造成循环引用，可以使用YYWeakProxy或者为CADisplayLink、NSTimer添加block方法解决循环引用

循环引用的实质：多个对象相互之间有强引用，不能释放让系统回收。

如何解决循环引用？

1、避免产生循环引用，通常是将 strong 引用改为 weak 引用。 比如在修饰属性时用weak 在block内调用对象方法时，使用其弱引用，这里可以使用两个宏

#define WS(weakSelf) __weak __typeof(*self)weakSelf = self; // 弱引用

#define ST(strongSelf) __strong __typeof(*self)strongSelf = weakSelf; //使用这个要先声明weakSelf 还可以使用__block来修饰变量 在MRC下，__block不会增加其引用计数，避免了循环引用 在ARC下，__block修饰对象会被强引用，无法避免循环引用，需要手动解除。

2、在合适时机去手动断开循环引用。 通常我们使用第一种。

3、block循环引用

一个简单的例子：

由于block会对block中的对象进行持有操作,就相当于持有了其中的对象，而如果此时block中的对象又持有了该block，则会造成循环引用。 解决方案就是使用__weak修饰self即可

并不是所有block都会造成循环引用。 只有被强引用了的block才会产生循环引用 而比如dispatch_async(dispatch_get_main_queue(), ^{}),[UIView animateWithDuration:1 animations:^{}]这些系统方法等 或者block并不是其属性而是临时变量,即栈block

还有一种场景，在block执行开始时self对象还未被释放，而执行过程中，self被释放了，由于是用weak修饰的，那么weakSelf也被释放了，此时在block里访问weakSelf时，就可能会发生错误(向nil对象发消息并不会崩溃，但也没任何效果)。 对于这种场景，应该在block中对 对象使用__strong修饰，使得在block期间对 对象持有，block执行结束后，解除其持有。

=======

深入浅出iOS系统内核（3）— 内存管理

本文参考《Mac OS X and iOS Internals: To the Apple’s Core》 by Jonathan Levin

文章内容主要是阅读这本书的读书笔记，建议读者掌握《操作系统》，了解现代操作系统的技术特点，再阅读本文可以事半功倍。

虽然iOS系统内核使用极简的微内核架构，但内容依然十分庞大，所以会分

系统架构 、 进程调度 、 内存管理 和 文件系统 四个部分进行阐述。

操作系统管理所有的硬件资源，操作系统内核管理最核心的资源CPU和内存。上一篇阐述了Mach通过进程管理CPU，本文主要阐述XNU和Mach如何高效的管理内存

按照传统，栈一般都是保存自动变量，正常情况栈由系统管理，但是在iOS中某些情况下，程序员也可以选择用栈来动态分配内存，方法是使用鲜为人知的alloca( ) 这个函数的原型和malloc( )是一样的，区别在于这个函数返回的指针是栈上的地址而不是堆中的地址。

从实现角度，alloca( )从两方面优于malloc( )

堆是由C语言运行时维护的用户态数据结构，通过堆的使用，程序可以不用直接在页面的层次处理内存分配。Darwin的libC 采用了一个基于分配区域（allocation zone）的特殊分配算法

在iOS中内存的管理是由在Mach层中进行的，BSD只是对Mach接口进行了POSIX封装，方便用户态进程调用。

XNU内存管理的核心机制是虚拟内存管理，在Mach 层中进行的，Mach 控制了分页器，并且向用户态导出了各种 vm_ 和 mach_vm_ 消息接口。 为方便用户态进程使用BSD对Mach 调用进行了封装，通过current_map( ) 获得当前的Mach 内存映射，最后再调用底层的Mach 函数。

BSD 的malloc 系列函数bsd/sys/malloc.h 头文件中。函数名为_MALLOC、_FREE、_REALLOC、_MALLOC_ZONE、_FREE_ZONE

mcache机制是BSD 提供的基于缓存的非常高效的内存分配方法。默认实现基于mach zone，通过mach zone提供预分配好的缓存内存。

mcache具有可扩展架构，可以使用任何后端 slab 分配器。

使用mcache 机制的主要优点是速度：内存分配和维护是在每一个 CPU 自有的cache中进行的，因此可以映射到CPU的物理cache，从而极大地提升访问速度。

Mach VM层支持VM pressure 的机制，这个机制是可用RAM量低到危险程度的处置，下面我们会详细讲，这里不展开。

当RAM量低到危险时，Mach的pageout 守护程序会查询一个进程列表，查询驻留页面数，然后向驻留页面数最高的进程发送NOTE_VM_PRESSURE ，会在进程队列中发出一个事件。被选中的进程会响应这个压力通知，iOS中的运行时会调用 didReceiveMemoryWarning 方法。

然而有些时候这些操作没有效果，当内存压力机制失败之后，** 非常时间要用非常手段 **， Jetsam机制介入。

当进程不能通过释放内存缓解内存压力时，Jestam机制开始介入。这是iOS 实现的一个低内存清理的处理机制。也称为Memorystatus，这个机制有点类似于Linux的“Out-of-Memory”杀手，最初的目的就是杀掉消耗太多内存的进程。Memorystatus维护了两个列表：

在iOS的用户态可以通过 sysctl(2)查询这些列表，优先级列表可以在用户态进行设置。

在iOS 5中，Jestsam/Memorystatus 和默认的freezer 结合在一起，实现了对进程的冷冻而不是杀死。通过这种方式可以提供更好的用户体验，因为数据不会丢失，而且当内存情况好转时进程可以安全恢复。(感谢@易步指出本段错误)

用户态也可以通过pid_suspend( ) 和 pid_resume( )控制进程的休眠。

iOS 定义了 pid_hibernate，通过发送kern_hibernation_wakeup信号唤醒kernel_hibernation_thread 线程，这个线程专用于对进程冷冻操作。

实际的进程休眠操作是由jestsam_hibernate_top_proc 完成的，这个函数通过task_freeze冷冻底层的任务。

冷冻操作需要遍历任务的vm_map，然后将vm_map 传递给默认的 freezer。

VM是Darwin系统内存管理的核心机制。

VM 机制主要通过内存对象（memory object）和分页器（pager）的形式管理内存。

Mach 虚拟内存的实现非常全面而且通用。这部分由两个层次构成：一层是和硬件相关的部分，另一层构建在这一层之上和硬件无关的公共层。OS X 和 iOS 使用的几乎一样的底层机制，硬件无关层以及之上的BSD 层中的机制都是一样的。

Mach 的 VM子系统可以说是和其要管理的内存一样复杂和充满了各种细节。然后从高层次看，可以看到两个层次：

虚拟内存这一层完全以一种机器无关的方式来管理虚拟内存。这一层通过几种关键的抽象表示虚拟内存：

Mach 允许使用多个分页器。事实上，默认就存在3~4个分页器。Mach 的分页器以外部实体的形式存在：是专业的任务，有点类似于其他系统上的内核交换（kernel-swapping）线程。Mach 的设计允许分页器和内核任务隔离开，设置允许用户态任务作为分页器。类似地，底层的后备存储也可以驻留在磁盘交换文件中（通过OS X 中的 default_pager 处理），可以映射到一个文件（由vnode_pager处理），可以是一个设备（由device_pager 处理）。注意：在Mach 中，每一个分页器处理的都是属于这个分页器的页面的请求，但是这些请求必须通过pageout 守护程序发出。这些守护程序（实际上就是内核线程）维护内核的页面表，并且判定哪些页面需要被清除出去。因此，这些守护程序维护的分页策略和分页器实现的分页操作是分开的。

物理内存的页面处理的是虚拟内存到物理内存的映射，因为虚拟内存中的内容最终总要存储在某个地方。这一层面只有一个抽象，那就是pmap，不过这个抽象非常重要，因为提供了机器无关的接口。这个接口隐藏了底层平台的细节，底层的细节需要在处理器层次进行分页操作，其中要处理的对象包括硬件页表项（page table entry，PTE）、翻译查找表（translation lookaside buffer，TLB）等。

每一个Mach 任务都要自己的虚拟内存空间，任务的struct task 中的 map 字段保存的就是这个虚拟内存空间。

vm_page_entry 中最关键的元素是vm_map_object，这是一个联合体，既可以包含另一个vm_map（作为子映射），也可以包含一个vm_object_t（由于这是一个联合体，所以具体的内容需要用布尔字段is_sub_map 来判断）。vm_object 是一个巨大的数据结构，其中包含了处理底层虚拟内存所需要的所有数据。vm_object的数据结构中的大部分字段都是用位表示的标志。这些字段表示了底层的内存状态（联动、物理连续和持久化等状态）和一些计数器（引用计数、驻留计数和联动计数等）。不过有3个字段需要特别注意：

memq：vm_page 对象的链表，每一项都表示一个驻留内存的虚拟内存页面。尽管一个对象可以表示一个单独的页面，但是多数情况下一个对象可以包含多个页面，所以每一个页面关联到一个对象时都会有一个偏移值

page：memory_object 对象，这是指向分页器的Mach 端口。分页器将未驻留内存的页面关联到后备存储，后备存储可以是内存映射的文件、设备和交换文件，后备存储保存了没有驻留内存的页面。换句话说，分页器（可以有多个）负责将数据从后备存储移入内存以及将数据从内存移出到后备存储。分页器对于虚拟内存子系统来说极为重要

internal：vm_page 中众多标志位之一，如果这个位为真，那么表示这个对象是由内核内部使用的。这个标志位的值决定了对象中的页面会进入哪一个pageout队列

尽管内核和用户空间一样，基本上只在虚拟地址空间内操作，但是虚拟内存最终还是要翻译为物理地址的。机器的RAM 实际上是虚拟内存中开的窗口，允许程序访问虚拟内存是有限的，而且通常是不连续的区域，这些区域的上线就是机器上安装的内存。而虚拟内存中其他部分则要么延迟分配，要么共享，要么被交换到外部存储中，外部存储通常是磁盘。

然而虚拟内存和具体的底层架构相关。尽管虚拟内存和物理内存的概念在所有架构上本周都是一样的，但是具体的实现细节则各有千秋。XNU 构建与Mach 的物理内存抽象层之上，这个的抽象层成为pmap。pmap 从设计上对物理内存提供了一个统一的接口，屏蔽了架构相关的区别。这对于XNU来说非常有用，因为XNU支持的物理内存的架构包括以前的PowerPC，现在主要是Intel，然后在iOS 中还支持ARM。

Mach 的pmap 层逻辑上由一下两个子层构成：

Mach Zone的概念相当于Linux的内存缓存（memory cache）和Windows 的Pool。Zone 是一种内存区域，用于快速分配和是否频繁使用的固定大小的对象。Zone的API是内核内部使用的，在用户态不能访问。Mach中Zone的使用非常广泛。

所有的zone 内存实际上都是在调用zinit( )时预先分配好的（zinit( )通过底层内存分配器kernel_memory_allocate( )分配内存）zalloc( )实际上是对REMOVE_FROM_ZONE 宏的封装，作用是返回zone的空闲列表中的下一个元素（如果zone已满，则调用kernel_memory_allocate( )分配这个zone在定义的alloc_size字节）。zfree( ) 使用的是相反功能的宏 ADD_TO_ZONE。这两个函数都会执行合理数量的参数检查，不过这些检查帮助不大：过去zone分配相关的bug已经导致了数据可以被黑客利用的内存损坏。zalloc( ) 最重要的客户是内核中的kalloc( )，这个函数从kalloc.*系列zone中分配内存。BSD的mcache机制也会从自己的zone中分配内存。BSD内核zone也是如此，BSD内核zone直接构建与Mach的zone之上。

进程的内存需求早晚会超过可用的RAM，系统必须有一种方法能够将不活动的页面备份起来，并且从RAM中删除，腾出更多的RAM给活动的页面使用，至少暂时能够满足活动页面的需求。在其他操作系统中，这个工作专门是由专门的内核线程完成的。在Mach 中，这些专门的任务称为分页器（pager），分页器可以是内核线程，设置建议是外部的用户态服务程序。

Mach分页器是一个内存管理器，负责将虚拟内存备份到某个特定类型的后备存储中。当内存容量不足，内存页面需要被交换出内存是，后备存储保存内存页面的内容：当换出的内存页面需要被使用时，将内存的页面恢复到RAM中。只有“脏”页面才需要进行上述的换出和换入，因为“脏”页面是在内存中修改过的页面，要从RAM中剔除时必须保存到磁盘中防止数据丢失。

要注意的是，这里提到的分页器仅仅实现了各自负责的内存对象的分页操作，这些分页器不会控制系统的分页策略。分页策略是有vm_pageout 守护线程负责的。

iOS 和 OS X 中XNU 包含的分页器种类都是一样的。下表是XNU中的内存分页器的多种类型：

pageout 守护程序其实不是一个真的守护程序，而是一个线程。而且不是一般的线程：当kernel_bootstarp_thread( ) 完成内核初始化工作并且没有其他事情可做时，就调用vm_pageout( ) 成为了pageour 守护程序， vm_pageout( ) 永远不返回。这个线程管理页面交换的策略，判断哪些页面需要写回到其后备存储。

vm_pageout( ) 函数讲kernel_bootstrap_thread 线程转变为pageout 守护程序，这个函数实际上重新设置了这个线程。设置完成后，调用vm_pageout_continute( )，这个函数周期性地唤醒并执行vm_page_scan( )，维护4个页面表（称为页面队列）。系统中的每一个vm_page 都通过pageq字段绑定这4个队列中的一个：

垃圾回收线程(vm_pageout_garbage_collect( ))偶尔会被vm_pageout_scan( ) 通过其续体唤醒。垃圾回收机制线程处理4个方面的垃圾回收工作：

vm_pageout( ) 守护程序处理的只是交换的一个方向，从物理内存换出到后备存储。而另外一个方向是页面换入，则是发生在页面错误的时候处理的。这个逻辑非常复杂，简化为一下步骤：

页错误有很多种，上述只是其中一种，其他类型的也错误还包括：

VM系统是Mach中最重要最复杂而且最不好理解的子系统。Mach的内存管理核心是分页器，分页器允许将虚拟内存扩展到各种后背存储介质上：交换文件、内存映射文件、设备、甚至远程主机。

iOS中提高内存使用率的Freezer，以及处理内存耗尽的pageout守护程序。

;qid=1331298923sr=8-2

iOS 管理内存的方式 - 内存管理系统

虚拟地址空间是指虚拟的、人们想象出来的地址空间，其实它并不存在，每个进程都有自己独立的虚拟空间，每个进程只能访问自己的地址空间，这样就能有效的做到了进程的 隔离 。

注： 虚拟储存的实现需要依赖硬件的支持，对于不同的CPU来说不同，但是几乎所有的硬件都采用MMU（Memory Management Unit）的部件来进行页映射。

把一段与程序所需要的内存空间大小的虚拟空间映射到某个地址空间。

当一个程序运行时，在某个时间段内，它只是频繁的用到了一小部分数据，程序的很多数据其实在一个时间段内都不会被用到。人们很自然的想到了更小粒度的内存分割和映射的方法，使得程序的局部性原理得到充分的利用，大大提高了内存的使用率。

原先的32位地址只能访问最多4GB的物理内存，但是自从扩展至36位地址线以后，Intel修改了页映射方式，使得新的映射方式可以访问到更多的物理内存，Intel把这个地址扩展方式叫做PAE（Physical Address Extension）

应用程序可以根据需求来选择申请和映射，比如一个应用程序0x10000000 ～0x20000000这一段256MB的虚拟地址空间用来做窗口，程序可以从高4GB的物理空间申请多个大小为256MB的物理空间，编号成A、B、C的等，然后根据需要将这个窗口映射到不同物理空间块，用到A时映射到A，用到B、C时再映射过去，叫做AWE（Address Windowing Extension），而Linux等UNIX类操作系统则采用mmap（）系统调用来实现

一些存储在磁盘中的数据，在CPU执行这个地址指令时，发现页面是一个空的页面，于是他就认为这是一个 页错误 ，CPU将控制权交给操作系统，操作系统有专门处理例程来处理，操作系统将查询这个数据结构，然后找到空页面所在的VMA，计算相应的页面在可执行文件中的偏移，然后再物理内存中分配一个物理页面，将进程中该虚拟页与分配的物理页之间建立映射，然后再交给进程去执行。

ELF文件被映射时，是以页长度为单位的，每个段在映射时的长度应该是系统页长度的整倍数，如果不是，多余的部分页将占领一个页，造成了内存空间的大量浪费。而在ELF文件中，段的权限直邮为数不多的几种组合：

那么对于相同的段，我们把他们合并在一起当成一个段来映射，ELF可执行文件引入一个概念叫做Segment，一个segment包含一个或多个section，这样很明显的减少了页面内部的碎片，节省了空间

假设一个ELF执行文件，它有三个段需要装载，SEG0 、SEG1、SEG2，如图:

可以看到这种对齐方式在文件段的内部会有很多内部碎片，浪费磁盘空间，可执行文件总长度只有12014字节，却占了5个页。为了解决这个问题，UNIX系统采用了让那些个个段接壤的部分共用一个物理页面，将该物理页面映射两次，系统将它们映射两份到虚拟地址空间，其他的都按照正常的页粒度进行映射。

本文标题：ios开发内存管理,ios内存管理机制 高级
转载来源：http://hbruida.cn/article/dsccsip.html