内存管理

上一篇文章《 TCMalloc优化MySQL、Nginx、Redis内存管理 》，下 面来看下 jemalloc jemalloc源于Jason Evans 2006年在BSDcan conference发表的论文：《 A Scalable Concurrent malloc Implementation for FreeBSD 》。 jason认为phkmalloc（FreeBSD’s previous malloc implementation by Kamp (1998)）没有考虑多处理器的情况，因此在多线程并发下性能低下(事实如此)，而jemalloc适合多线程下内存分配管理。从2007年开始以 FreeBSD标准引进来。软件技术革新很多是FreeBSD发起，在FreeBSD应用广泛的技术会慢慢导入到 Linux 中。 Redis 2.4版本之后，默认使用jemalloc来做内存管理；tengine也整合jemalloc 。jemalloc从各方评测的结果可见与google tcmalloc都不相伯仲，皆为内存管理器领域最高水平。如下图： 图片来源： facebook 最左边的就是glibc的malloc，最右边的就是jemalloc。从图表上可以看出，jemalloc的性能有glibc的两倍以上。非常压 倒性的性能差异。因此，使用了jemalloc的应用程序自然会快很多

内存 内存使用： 将程序放到内存中，PC指向开始地址，然后取指执行。 物理内存： 实际内存。 虚拟内存： 1. 每一个运行的进程，都会获得一个内存地址空间，这就是所谓的虚拟内存。 2. 这里面的所有地址都是虚拟的，和物理内存并不直接挂钩。 3. 这些虚拟地址所映射到的实际地址，可以是物理内存地址，也可以是页面文件的地址。 4. 如果物理内存小于这个虚拟地址的范围， 使用的时候可以将内存数据写入页面文件，通过清空内存数据，以提高物理内存的利用效率。 页面文件： 硬盘上的一块空间，在Windows下表现为一个文件。 这个页面文件存在的意义就是在物理内存被占用满以后， 将物理内存中的东西移动到硬盘上，腾出物理内存给需要的应用程序来使用。 内存管理 内存管理和虚拟内存管理： 内存管理包括： 程序装入等概念、 交换技术、 连续分配管理方式、 非连续分配管理方式（分页、分段、段页式）。 虚拟内存管理包括： 虚拟内存概念、 请求分页管理方式、 页面置换算法、页 面分配策略、 工作集、 抖动。 程序装入和链接 编译： 由编译程序将用户源代码编译成若干个目标模块。 链接： 由链接程序将编译后形成的一组目标模块，以及所需库函数链接在一起，形成一个完整的装入模块。 装入： 由装入程序将装入模块装入内存运行。 重定向（修改程序中的相对地址）： 1. 编译时重定位的程序只能放在内存固定位置 2.

一、什么是Java中的内存泄露？ 　　在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点， 　　首先，这些对象是 可达的 ，即在有向图中， 存在通路可以与其相连 ；其次，这些对象是 无用的 ， 即程序以后不会再使用这些对象 。 　　如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。 　　在C++中，内存泄漏的范围更大一些。有些对象被分配了内存空间，然后却不可达，由于C++中没有GC，这些内存将永远收不回来。 　　 在Java中，这些不可达的对象都由GC负责回收 ，因此程序员不需要考虑这部分的内存泄露。 　　通过分析，我们得知，对于C++，程序员需要自己管理边和顶点，而对于Java程序员只需要管理边就可以了(不需要管理顶点的释放)。 　　通过这种方式，Java提高了编程的效率。 来源： https://www.cnblogs.com/mww-NOTCOPY/p/11683303.html

近期在解决一个编译问题时，一直在考虑一个问题，那就是Linux下可执行程序执行时内存是什么状态，是依照什么方式分配内存并执行的。 linux下内存管理是通过虚存管理的，在分配内存时并不是在物理内存开辟了一段空间，而是在使用时才分配的。并且是通过段页式管理。 linux下内存分配是以页为单位的。而页是通过段管理。各个段之间是独立的，方便管理。linux程序执行时能够分为下面几个内存段： text、rodata、data、bss、stack、heap。 一、各内存区段的介绍 系统内的程序分为程序段和数据段，具体又可细分为一下几个部分： （1）text段-代码段 text段存放程序代码，运行前就已经确定（编译时确定），通常为只读，可以直接在ROM或Flash中执行，无需加载到RAM。 在嵌入式开发中，有时为了特别的需求（例如加速），也可将某个模块搬移到RAM中执行。 （2）rodata段（read-only-data）-常量区 rodata段存储常量数据，比如程序中定义为const的全局变量，#define定义的常量，以及诸如“Hello World”的字符串常量。只读数据，存储在ROM中。 注意：有些立即数与指令编译在一起，放在text段。 const修饰的全局变量在常量区；const修饰的局部变量只是为了防止修改，没有放入常量区。 编译器会去掉重复的字符串常量

背景 Read the fucking source code! --By 鲁迅 A picture is worth a thousand words. --By 高尔基 说明： Kernel版本：4.14 ARM64处理器，Contex-A53，双核 使用工具：Source Insight 3.5， Visio 1. 概述 本文将分析 Buddy System 。 Buddy System 伙伴系统，是通过将物理内存划分为页面来进行管理的系统，支持连续的物理页面分配和释放。此外，使用与碎片相关的算法来确保最大的连续页面。 先通过一个例子大体介绍一下原理吧： 空闲的物理页框按大小分组成 0~MAX_ORDER 个链表，每个链表存放页框的大小为2的n次幂，其中n在 0 ~ MAX_ORDER-1 中取值。 假设请求分配 2^8 = 256 个页框块： 检查 n = 8 的链表，检查是否有空闲块，找到了则直接返回； 没有找到满足需求的，则查找 n = 9 的链表，找到 512大小 空闲块，拆分成两个 256大小 块，将其中一个 256大小 块返回，另一个 256大小 块添加到 n = 8 的链表中； 在 n = 9 的链表中没有找到合适的块，则查找 n = 10 的链表，找到1024大小空闲块，将其拆分成 512 + 256 + 256 大小的块，返回需要获取的 256大小 的块

目录 一、存储器管理 1.1存储器的层次结构 1.2程序的装入和链接 1.2.1程序装入 1.2.2程序链接 1.3交换 1.4连续分配管理方式 1.4.1单一连续分配 1.4.2固定分区分配 1.4.3动态分区分配(含顺序和索引算法) 1.4.4动态可重定位分区分配 1.5非连续分配管理方式 1.5.1分页存储管理方式 1.5.2分段存储管理方式 1.5.3段页式存储管理方式 二、虚拟存储器 2.1基本概念 2.2请求分页存储管理方式 2.2.1请求分页中的硬件支持 2.2.2请求分页中的内存分配 2.2.3页面调入策略 2.3页面置换算法 2.4“抖动”与工作集 一、存储器管理 1.1存储器的层次结构 1、多层结构的存储器系统 1）存储器的多层结构 通用计算机存储层次有三级：CPU寄存器，主存，辅存 主存包括：高速缓存、主存储器、磁盘缓存 辅存包括：固定磁盘、可移动存储介质 寄存器、高速缓存、主存储器和磁盘缓存属于 操作系统存储管理 的管辖范畴，断电后存储信息丢失；固定磁盘、可移动存储介质属于 设备管理 的管辖范畴，存储信息被长期保存 2）可执行存储器 寄存器和主存储器被称为可执行存储器 进程可以在很少的时钟周期内使用 load和 store指令访问可执行存储器，但对辅存的访问需要通过 I/O设备实现，耗费时间远超前者 2、主存储器与寄存器 1）主存储器 简称内存或主存，用于

本专栏专注分享大型Bat面试知识，后续会持续更新，喜欢的话麻烦点击一个关注 面试官: AMS在Android起到什么作用，简单的分析下Android的源码 心理分析：这道题在发生在大多数场景下。面对这道题 很多求职很茫然，不知道该如何说起。AMS本身比较复杂难以理解。工作多年也很难弄清AMS的作用，其实我们大可从以下几点入手组件启动、进程切换、Crash异常入手 求职者:AMS难以表述 我们就从最熟知 的Activity启动入手，逐步深入和分析，用定力告诉面试官，我层深入研究过。接下来我们从五条线分析AMS作用及机制 概述 相信大多数动脑同学对文章中提到的ActivityManagerService（以后简称AMS）都有所耳闻。 AMS是Android中最核心的服务，主要负责系统中四大组件的启动、切换、调度及应用进程的管理和调度等工作，其职责与操作系统中的进程管理和调度模块相类似，因此它在Android中非常重要。 AMS是碰到的第一块难啃的骨头[①]，涉及的知识点较多。为了帮助读者更好地理解AMS，接下来将带小伙伴么按五条不同的线来分析它。 第一条线：同其他服务一样，将分析SystemServer中AMS的调用轨迹。 第二条线：以am命令启动一个Activity为例，分析应用进程的创建、Activity的启动，以及它们和AMS之间的交互等知识。 第三条线和第四条线

关于objective-c的内存管理，我们都知道一个原则就是“谁创建，谁释放”，换句话说，不是我们创建的，就不用我们去释放。但是实际上objective-c的内存管理远远没那么简单，我的情况是这样的： 如果场景切换的时候dealloc没有调用，说明你这个场景的内存有问题。有可能被某个对象retain了，其retainCount在 replaceScene的时候没有减少到0，所以dealloc方法是不会调用的。如果dealloc方法都没有调掉，那么这其实就是一种内存泄露。 最后的最后才发现实际上是performSelector延时调用的问题，经查找资料，performSelector关于内存管理的执行原理是这 样的执行 [self performSelector:@selector(method1:) withObject:self.tableLayer afterDelay:3]; 的时候，系统会将tableLayer的引用计数加1，执行完这个方法时，还会将tableLayer的引用计数减1，而在我的游戏里这个延时执行函数是 被多次调用的，有时切换场景时延时函数已经被调用但还没有执行，这时tableLayer的引用计数没有减少到0，也就导致了切换场景dealloc方法 没有被调用，出现了内存泄露。 所以最后我的解决办法就是取消那些还没有来得及执行的延时函数，代码很简单：

在Android应用里，最耗费内存的就是图片资源。而且在Android系统中，读取位图Bitmap时，分给虚拟机中的图片的堆栈大小只有8M，如果超出了，就会出现OutOfMemory异常。所以，对于图片的内存优化，是Android应用开发中比较重要的内容。 1) 要及时回收Bitmap的内存 Bitmap类有一个方法recycle()，从方法名可以看出意思是回收。这里就有疑问了，Android系统有自己的垃圾回收机制，可以不定期的回收掉不使用的内存空间，当然也包括Bitmap的空间。那为什么还需要这个方法呢？ Bitmap类的构造方法都是私有的，所以开发者不能直接new出一个Bitmap对象，只能通过BitmapFactory类的各种静态方法来实例化一个Bitmap。仔细查看BitmapFactory的源代码可以看到，生成Bitmap对象最终都是通过JNI调用方式实现的。所以，加载Bitmap到内存里以后，是包含两部分内存区域的。简单的说，一部分是Java部分的，一部分是C部分的。这个Bitmap对象是由Java部分分配的，不用的时候系统就会自动回收了，但是那个对应的C可用的内存区域，虚拟机是不能直接回收的，这个只能调用底层的功能释放。所以需要调用recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到，recycle()方法里也的确是调用了JNI方法了的。

本文读者： 遭遇应用启动速度慢问题的朋友 希望保持应用启动速度快的朋友 对操作系统知识感兴趣的朋友 内容概览 理论部分 Mach-O 相关知识 虚拟内存相关知识 Mach-O 映像加载过程 从 exec() 到 main() 实践部分 如何度量 优化启动时间 理论部分 Mach-O 相关知识 Mach-O 术语 文件类型： 可执行文件，应用程序主要的二进制文件 Dylib，动态库（也叫做 DSO 或 DLL） Bundle，不可以被链接的 Dylib，只可以进行 dlopen() ，比如：插件 映像：一个可执行文件 或者 dylib 或者 bundle。 框架：带有目录的 dylib ，其目录中包含资源和头文件。 Mach-O Image File 文件被分割为段(segment)，并采用大写命名 所有段的大小都是页大小的整数倍（arm64 架构为16KB，其他架构是4KB） 组是段内的子范围，并采用小写命名 常见的段： __TEXT，包含头文件、代码和只读常量(比如C语言字符串常量) __DATA，包含所有读写内容：全局变量、静态变量等 __LINKEDIT，包含如何加载程序的元数据（方法名和地址等信息） Mach-O Universal Files Fat Header 占用一页的大小 列出所有支持的架构和其对应的偏移量 你可能比较好奇，为什么段的大小是页的整数倍？ 为什么