linux之内存

by 刘凯

问题

  • RAM为什么不能持久化？
  • 内存管理的最小单位是什么？
  • pagecache是什么？
  • pagecache与buffercache的区别？
  • 线程的内存大小？
  • tmpfs是做什么的？
  • 内存对齐的作用？

内存

概述

内存是计算机的主存储器。内存为进程开辟出进程空间，让进程在其中保存数据。

内存的大小

内存有一个最小的存储单位，大多数都是一个字节。内存用内存地址（memory address）来为每个字节的数据顺序编号。因此，内存地址说明了数据在内存中的位置。内存地址从0开始，每次增加1。这种线性增加的存储器地址称为线性地址（linear address）。为了方便，我们用十六进制数来表示内存地址，比如0x00000003、0x1A010CB0。这里的“0x”用来表示十六进制。“0x”后面跟着的，就是作为内存地址的十六进制数。

内存地址的编号有上限。地址空间的范围和地址总线（address bus）的位数直接相关。CPU通过地址总线来向内存说明想要存取数据的地址。以英特尔32位的80386型CPU为例，这款CPU有32个针脚可以传输地址信息。每个针脚对应了一位。如果针脚上是高电压，那么这一位是1。如果是低电压，那么这一位是0。32位的电压高低信息通过地址总线传到内存的32个针脚，内存就能把电压高低信息转换成32位的二进制数，从而知道CPU想要的是哪个位置的数据。用十六进制表示，32位地址空间就是从0x00000000 到0xFFFFFFFF（由于内存的最小单位为byte，即能操作的最大内存为2的32次方byte即2的22次方KB,2的12次方MB,2的平方GB）。

随机读取

内存的存储单元采用了随机读取存储器（RAM， Random Access Memory）。所谓的“随机读取”，是指存储器的读取时间和数据所在位置无关。与之相对，很多存储器的读取时间和数据所在位置有关。就拿磁带来说，我们想听其中的一首歌，必须转动带子。如果那首歌是第一首，那么立即就可以播放。如果那首歌恰巧是最后一首，我们快进到可以播放的位置就需要花很长时间。我们已经知道，进程需要调用内存中不同位置的数据。如果数据读取时间和位置相关的话，计算机就很难把控进程的运行时间。因此，随机读取的特性是内存成为主存储器的关键因素。

内存的作用

内存提供的存储空间，除了能满足内核的运行需求，还通常能支持运行中的进程。即使进程所需空间超过内存空间，内存空间也可以通过少量拓展来弥补。换句话说，内存的存储能力，和计算机运行状态的数据总量相当。内存的缺点是不能持久地保存数据。一旦断电，内存中的数据就会消失。因此，计算机即使有了内存这样一个主存储器，还是需要硬盘这样的外部存储器来提供持久的储存空间。

RAM为什么是易失的

RAM依赖电容器存储数据。电容器充满电后代表1(二进制)，未充电的代表0。

这样的话，就依靠电容的刷新来储存数据，比如内存条，这样的话，速度就非常快，只要满电荷和无电荷就能代表计算机二进制里面的0和1。

所以，一停止通电后，RAM里的数据就没了，电就是用来表示数据的。

虚拟内存

内存的一项主要任务，就是存储进程的相关数据。我们之前已经看到过进程空间的程序段、全局数据、栈和堆，以及这些这些存储结构在进程运行中所起到的关键作用。有趣的是，尽管进程和内存的关系如此紧密，但进程并不能直接访问内存。在Linux下，进程不能直接读写内存中地址为0x1位置的数据。进程中能访问的地址，只能是虚拟内存地址（virtual memory address）。操作系统会把虚拟内存地址翻译成真实的内存地址。这种内存管理方式，称为虚拟内存（virtual memory）。

每个进程都有自己的一套虚拟内存地址，用来给自己的进程空间编号。进程空间的数据同样以字节为单位，依次增加。从功能上说，虚拟内存地址和物理内存地址类似，都是为数据提供位置索引。进程的虚拟内存地址相互独立。因此，两个进程空间可以有相同的虚拟内存地址，如0x10001000。虚拟内存地址和物理内存地址又有一定的对应关系，如图1所示。对进程某个虚拟内存地址的操作，会被CPU翻译成对某个具体内存地址的操作。

应用程序对物理内存地址一无所知。它只可能通过虚拟内存地址来进行数据读写。程序中表达的内存地址，也都是虚拟内存地址。进程对虚拟内存地址的操作，会被操作系统翻译成对某个物理内存地址的操作。由于翻译的过程由操作系统全权负责，所以应用程序可以在全过程中对物理内存地址一无所知。因此，C程序中表达的内存地址，都是虚拟内存地址。比如在C语言中，可以用下面指令来打印变量地址：

int v = 0;
printf("%p", (void*)&v);

本质上说，虚拟内存地址剥夺了应用程序自由访问物理内存地址的权利。进程对物理内存的访问，必须经过操作系统的审查。因此，掌握着内存对应关系的操作系统，也掌握了应用程序访问内存的闸门。借助虚拟内存地址，操作系统可以保障进程空间的独立性。只要操作系统把两个进程的进程空间对应到不同的内存区域，就让两个进程空间成为“老死不相往来”的两个小王国。两个进程就不可能相互篡改对方的数据，进程出错的可能性就大为减少。

另一方面，有了虚拟内存地址，内存共享也变得简单。操作系统可以把同一物理内存区域对应到多个进程空间。这样，不需要任何的数据复制，多个进程就可以看到相同的数据。内核和共享库的映射，就是通过这种方式进行的。每个进程空间中，最初一部分的虚拟内存地址，都对应到物理内存中预留给内核的空间。这样，所有的进程就可以共享同一套内核数据。共享库的情况也是类似。对于任何一个共享库，计算机只需要往物理内存中加载一次，就可以通过操纵对应关系，来让多个进程共同使用。IPC中的共享内存，也有赖于虚拟内存地址。

内存分页

虚拟内存地址和物理内存地址的分离，给进程带来便利性和安全性。但虚拟内存地址和物理内存地址的翻译，又会额外耗费计算机资源。在多任务的现代计算机中，虚拟内存地址已经成为必备的设计。那么，操作系统必须要考虑清楚，如何能高效地翻译虚拟内存地址。

记录对应关系最简单的办法，就是把对应关系记录在一张表中。为了让翻译速度足够地快，这个表必须加载在内存中。不过，这种记录方式惊人地浪费。如果1GB物理内存的每个字节都有一个对应记录的话，那么光是对应关系就要远远超过内存的空间。由于对应关系的条目众多，搜索到一个对应关系所需的时间也很长。这样的话，会让内存陷入瘫痪。

因此，Linux采用了分页（paging）的方式来记录对应关系。所谓的分页，就是以更大尺寸的单位页（page）来管理内存。在Linux中，通常每页大小为4KB。如果想要获取当前的内存页大小，可以使用命令：

$getconf PAGE_SIZE

得到结果，即内存分页的字节数：

4096

返回的4096代表每个内存页可以存放4096个字节，即4KB。Linux把物理内存和进程空间都分割成页。

内存分页，可以极大地减少所要记录的内存对应关系。我们已经看到，以字节为单位的对应记录实在太多。如果把物理内存和进程空间的地址都分成页，内核只需要记录页的对应关系，相关的工作量就会大为减少。由于每页的大小是每个字节的4000倍。因此，内存中的总页数只是总字节数的四千分之一。对应关系也缩减为原始策略的四千分之一。分页让虚拟内存地址的设计有了实现的可能。

无论是虚拟页，还是物理页，一页之内的地址都是连续的。这样的话，一个虚拟页和一个物理页对应起来，页内的数据就可以按顺序一一对应。这意味着，虚拟内存地址和物理内存地址的末尾部分应该完全相同。大多数情况下，每一页有4096个字节。由于4096是2的12次方，所以地址最后12位的对应关系天然成立。我们把地址的这一部分称为偏移量（offset）。偏移量实际上表达了该字节在页内的位置。地址的前一部分则是页编号。操作系统只需要记录页编号的对应关系。

多级分页表

为什么要多级分页

页表中所有页表项必须提前建好，并且要求是连续的。如果不连续，就没有办法通过虚拟地址里面的页号找到对应的页表项了。

32 位环境下，虚拟地址空间共 4GB。如果分成 4KB 一个页，那就是 1M 个页。每个页表项需要 4 个字节来存储，那么整个 4GB 空间的映射就需要 4MB 的内存来存储映射表。如果每个进程都有自己的映射表，100 个进程就需要 400MB 的内存。对于内核来讲，有点大了 。

多级分页过程

内存分页制度的关键，在于管理进程空间页和物理页的对应关系。操作系统把对应关系记录在分页表（page table）中。这种对应关系让上层的抽象内存和下层的物理内存分离，从而让Linux能灵活地进行内存管理。由于每个进程会有一套虚拟内存地址，那么每个进程都会有一个分页表。为了保证查询速度，分页表也会保存在内存中。分页表有很多种实现方式，最简单的一种分页表就是把所有的对应关系记录到同一个线性列表中，即如图2中的“对应关系”部分所示。

这种单一的连续分页表，需要给每一个虚拟页预留一条记录的位置。但对于任何一个应用进程，其进程空间真正用到的地址都相当有限。我们还记得，进程空间会有栈和堆。进程空间为栈和堆的增长预留了地址，但栈和堆很少会占满进程空间。这意味着，如果使用连续分页表，很多条目都没有真正用到。因此，Linux中的分页表，采用了多层的数据结构。多层的分页表能够减少所需的空间。

我们来看一个简化的分页设计，用以说明Linux的多层分页表。我们把地址分为了页编号和偏移量两部分，用单层的分页表记录页编号部分的对应关系。对于多层分页表来说，会进一步分割页编号为两个或更多的部分，然后用两层或更多层的分页表来记录其对应关系，如图3所示。

在图3的例子中，页编号分成了两级。第一级对应了前8位页编号，用2个十六进制数字表示。第二级对应了后12位页编号，用3个十六进制编号。二级表记录有对应的物理页，即保存了真正的分页记录。二级表有很多张，每个二级表分页记录对应的虚拟地址前8位都相同。比如二级表0x00，里面记录的前8位都是0x00。翻译地址的过程要跨越两级。我们先取地址的前8位，在一级表中找到对应记录。该记录会告诉我们，目标二级表在内存中的位置。我们再在二级表中，通过虚拟地址的后12位，找到分页记录，从而最终找到物理地址。

多层分页表就好像把完整的电话号码分成区号。我们把同一地区的电话号码以及对应的人名记录同通一个小本子上。再用一个上级本子记录区号和各个小本子的对应关系。如果某个区号没有使用，那么我们只需要在上级本子上把该区号标记为空。同样，一级分页表中0x01记录为空，说明了以0x01开头的虚拟地址段没有使用，相应的二级表就不需要存在。正是通过这一手段，多层分页表占据的空间要比单层分页表少了很多。
多层分页表还有另一个优势。单层分页表必须存在于连续的内存空间。而多层分页表的二级表，可以散步于内存的不同位置。这样的话，操作系统就可以利用零碎空间来存储分页表。还需要注意的是，这里简化了多层分页表的很多细节。最新Linux系统中的分页表多达3层，管理的内存地址也比本章介绍的长很多。不过，多层分页表的基本原理都是相同。

综上，我们了解了内存以页为单位的管理方式。在分页的基础上，虚拟内存和物理内存实现了分离，从而让内核深度参与和监督内存分配。应用进程的安全性和稳定性因此大为提高。

多级分页使用目录页，岂不使用内存更大

当然如果页是满的，当时是更大了，但是，我们往往不会为一个进程分配那么多内存

假设只给这个进程分配了一个数据页。如果只使用页表，也需要完整的 1M 个页表项共 4M 的内存，但是如果使用了页目录，页目录需要 1K 个全部分配，占用内存 4K，但是里面只有一项使用了。到了页表项，只需要分配能够管理那个数据页的页表项页就可以了，也就是说，最多 4K，这样内存就节省多了

page cache&& buffer && swap

作用

缓存（cached）是把读取过的数据保存起来，重新读取时若命中（找到需要的数据）就不要去读硬盘了，若没有命中就读硬盘。其中的数据会根据读取频率进行组织，把最频繁读取的内容放在最容易找到的位置，把不再读的内容不断往后排，直至从中删除。

Cache并不是缓存文件的，而是缓存块的(块是I/O读写最小的单元)；Cache一般会用在I/O请求上，如果多个进程要访问某个文件，可以把此文件读入Cache中，这样下一个进程获取CPU控制权并访问此文件直接从Cache读取，提高系统性能。

page cache策略

  • 通常，刚被访问的数据在短时间内再次被访问的概率很高（这也叫“时间局部性”原理），用 PageCache 缓存最近访问的数据，当空间不足时淘汰最久未被访问的缓存（即 LRU 算法）
  • 读取磁盘数据时，需要先找到数据所在的位置，对于机械磁盘来说，就是旋转磁头到数据所在的扇区，再开始顺序读取数据。其中，旋转磁头耗时很长，为了降低它的影响，PageCache 使用了预读功能。虽然 read 方法只读取了 0-32KB 的字节，但内核会把其后的 32-64KB 也读取到 PageCache，这后 32KB 读取的成本很低。如果在 32-64KB 淘汰出 PageCache 前，进程读取到它了，收益就非常大。

PageCache 不起作用

传输大文件的时候。比如，你有很多 GB 级的文件需要传输，每当用户访问这些大文件时，内核就会把它们载入到 PageCache 中，这些大文件很快会把有限的 PageCache 占满。然而，由于文件太大，文件中某一部分内容被再次访问到的概率其实非常低。这带来了 2 个问题：首先，由于 PageCache 长期被大文件占据，热点小文件就无法充分使用 PageCache，它们读起来变慢了；其次，PageCache 中的大文件没有享受到缓存的好处，但却耗费 CPU（或者 DMA）多拷贝到 PageCache 一次。所以，高并发场景下，为了防止 PageCache 被大文件占满后不再对小文件产生作用，大文件不应使用 PageCache，进而也不应使用零拷贝技术处理。

linux上的跳过PageCache的方式有

  • mmap
    mmap的系统调用，可以直接将磁盘和内存映射，省去了从内核态copy到用户态，看起来要比直接IO更加高效
    实际mmap与直接io应用场景不一样，直接IO更底层点，mmap还需要保证内存与磁盘的数据一致性。
  • open("", O_DIRECT)

高并发下大文件的处理方式

linux下可通过异步io+同步io的方式处理大文件。

异步 IO 并没有拷贝到 PageCache 中，这其实是异步 IO 实现上的缺陷。经过 PageCache 的 IO 我们称为缓存 IO，它与虚拟内存系统耦合太紧，导致异步 IO 从诞生起到现在都不支持缓存 IO。

直接 IO 的应用场景并不多，主要有两种：第一，应用程序已经实现了磁盘文件的缓存，不需要 PageCache 再次缓存，引发额外的性能消耗。比如 MySQL 等数据库就使用直接 IO；第二，高并发下传输大文件，我们上文提到过，大文件难以命中 PageCache 缓存，又带来额外的内存拷贝，同时还挤占了小文件使用 PageCache 时需要的内存，因此，这时应该使用直接 IO。

当然，直接 IO 也有一定的缺点。除了缓存外，内核（IO 调度算法）会试图缓存尽量多的连续 IO 在 PageCache 中，最后合并成一个更大的 IO 再发给磁盘，这样可以减少磁盘的寻址操作；另外，内核也会预读后续的 IO 放在 PageCache 中，减少磁盘操作。直接 IO 绕过了 PageCache，所以无法享受这些性能提升。

有了直接 IO 后，异步 IO 就可以无阻塞地读取文件了。现在，大文件由异步 IO 和直接 IO 处理，小文件则交由零拷贝处理，至于判断文件大小的阈值可以灵活配置（参见 Nginx 的 directio 指令）。

page buffer

缓冲（buffers）是根据磁盘的读写设计的，把分散的写操作集中进行，减少磁盘碎片和硬盘的反复寻道，从而提高系统性能。当存储速度快的设备与存储速度慢的设备进行通信时，存储慢的数据先把数据存放到buffer，达到一定程度存储快的设备再读取buffer的数据，在此期间存储快的设备CPU可以干其他的事情。

linux有一个守护进程定期清空缓冲内容（即写入磁盘），也可以通过sync命令手动清空缓冲。

修改/etc/sysctl.conf中的vm.swappiness右边的数字可以在下次开机时调节swap使用策略。该数字范围是0～100，数字越大越倾向于使用swap。默认为60，可以改一下试试。–两者都是RAM中的数据。

swap

当物理内存不足时，拿出部分硬盘空间当SWAP分区（虚拟成内存）使用，从而解决内存容量不足的情况。

当程序向OS请求内存资源时，OS发现内存不足，则会把内存中暂时不用的数据交换出去，放在SWAP分区中，这个过程称为SWAP OUT。当程序又需要这些数据且OS发现还有空闲物理内存时，又会把SWAP分区中的数据交换回物理内存中，这个过程称为SWAP IN。

那么我们在使用 docker 和 K8s 的时候，为什么要关闭 swap 特性呢？主要还是希望获取更高的性能。kubernetes的思想是将实例紧密打包为尽可能接近100％的利用率。所有部署都应固定有CPU /内存限制。因此，如果调度程序将Pod发送到计算机，则绝对不要使用swap。

查看内存映射关系

当前进程的内存映射关系，通过读该文件的内容可以得到内存代码段基址。

[root@k8s-master ~]# cat /proc/self/maps
00400000-0040b000 r-xp 00000000 fd:01 16957547                           /usr/bin/cat
0060b000-0060c000 r--p 0000b000 fd:01 16957547                           /usr/bin/cat
0060c000-0060d000 rw-p 0000c000 fd:01 16957547                           /usr/bin/cat
0079e000-007bf000 rw-p 00000000 00:00 0                                  [heap]
7f274171e000-7f2747c45000 r--p 00000000 fd:01 50767640                   /usr/lib/locale/locale-archive
7f2747c45000-7f2747dfb000 r-xp 00000000 fd:01 33649185                   /usr/lib64/libc-2.17.so
7f2747dfb000-7f2747ffb000 ---p 001b6000 fd:01 33649185                   /usr/lib64/libc-2.17.so

注意地址的单位是 16 进制

linux 内存池

通过malloc申请内存

C 库内存池工作时，会预分配比你申请的字节数更大的空间作为内存池。比如说，当主进程下申请 1 字节的内存时，Ptmalloc2 会预分配 132K 字节的内存（Ptmalloc2 中叫 Main Arena），应用代码再申请内存时，会从这已经申请到的 132KB 中继续分配。

当我们释放这 1 字节时，Ptmalloc2 也不会把内存归还给操作系统。Ptmalloc2 认为，与其把这 1 字节释放给操作系统，不如先缓存着放进内存池里，仍然当作用户态内存留下来，进程再次申请 1 字节的内存时就可以直接复用，这样速度快了很多。

多线程内存预分配策略

多线程与单线程的预分配策略并不相同.

每个子线程预分配的内存是 64MB（Ptmalloc2 中被称为 Thread Arena，32 位系统下为 1MB，64 位系统下为 64MB）。如果有 100 个线程，就将有 6GB 的内存都会被内存池占用。当然，并不是设置了 1000 个线程，就会预分配 60GB 的内存，子线程内存池最多只能到 8 倍的 CPU 核数，比如在 32 核的服务器上，最多只会有 256 个子线程内存池，但这也非常夸张了，16GB（64MB * 256 = 16GB）的内存将一直被 Ptmalloc2 占用。

Linux 下的 JVM 编译时默认使用了 Ptmalloc2 内存池，因此每个线程都预分配了 64MB 的内存，这造成含有上百个 Java 线程的 JVM 多使用了 6GB 的内存。在多数情况下，这些预分配出来的内存池，可以提升后续内存分配的性能。

然而，Java 中的 JVM 内存池已经管理了绝大部分内存，确实不能接受莫名多出来 6GB 的内存，那该怎么办呢？既然我们知道了 Ptmalloc2 内存池的存在，就有两种解决办法。

首先可以调整 Ptmalloc2 的工作方式。通过设置 MALLOC_ARENA_MAX 环境变量，可以限制线程内存池的最大数量，当然，线程内存池的数量减少后，会影响 Ptmalloc2 分配内存的速度。不过由于 Java 主要使用 JVM 内存池来管理对象，这点影响并不重要。

其次可以更换掉 Ptmalloc2 内存池，选择一个预分配内存更少的内存池，比如 Google 的 TCMalloc。

这并不是说 Google 出品的 TCMalloc 性能更好，而是在特定的场景中的选择不同。而且，盲目地选择 TCMalloc 很可能会降低性能，否则 Linux 系统早把默认的内存池改为 TCMalloc 了。

TCMalloc

TCMalloc对多线程下小内存的分配特别友好

在 2GHz 的 CPU 上分配、释放 256K 字节的内存，Ptmalloc2 耗时 32 纳秒，而 TCMalloc 仅耗时 10 纳秒。差距超过了 3 倍，为什么呢？这是因为，Ptmalloc2 假定，如果线程 A 申请并释放了的内存，线程 B 可能也会申请类似的内存，所以它允许内存池在线程间复用以提升性能。

因此，每次分配内存，Ptmalloc2 一定要加锁，才能解决共享资源的互斥问题。然而，加锁的消耗并不小。如果你监控分配速度的话，会发现单线程服务调整为 100 个线程，Ptmalloc2 申请内存的速度会变慢 10 倍。TCMalloc 针对小内存做了很多优化，每个线程独立分配内存，无须加锁，所以速度更快！

而且，线程数越多，Ptmalloc2 出现锁竞争的概率就越高。比如我们用 40 个线程做同样的测试，TCMalloc 只是从 10 纳秒上升到 25 纳秒，只增长了 1.5 倍，而 Ptmalloc2 则从 32 纳秒上升到 137 纳秒，增长了 3 倍以上。

下图是 TCMalloc 作者给出的性能测试数据，可以看到线程数越多，二者的速度差距越大。所以，当应用场景涉及大量的并发线程时，换成 TCMalloc 库也更有优势！

Ptmalloc2

Ptmalloc2 更擅长大内存的分配。

比如，单线程下分配 257K 字节的内存，Ptmalloc2 的耗时不变仍然是 32 纳秒，但 TCMalloc 就由 10 纳秒上升到 64 纳秒，增长了 5 倍以上！现在 TCMalloc 反过来比 Ptmalloc2 慢了 1 倍！这是因为 TCMalloc 特意针对小内存做了优化。

多少字节叫小内存呢？TCMalloc 把内存分为 3 个档次，小于等于 256KB 的称为小内存，从 256KB 到 1M 称为中等内存，大于 1MB 的叫做大内存。TCMalloc 对中等内存、大内存的分配速度很慢，比如我们用单线程分配 2M 的内存，Ptmalloc2 耗时仍然稳定在 32 纳秒，但 TCMalloc 已经上升到 86 纳秒，增长了 7 倍以上。

所以，如果主要分配 256KB 以下的内存，特别是在多线程环境下，应当选择 TCMalloc；否则应使用 Ptmalloc2，它的通用性更好。

Linux 中通过 LD_PRELOAD 环境变量，在程序启动时修改动态库来更换内存池

从堆还是栈上分配内存

由于每个线程都有独立的栈，所以分配内存时不需要加锁保护，而且栈上对象的尺寸在编译阶段就已经写入可执行文件了，执行效率更高！性能至上的 Golang 语言就是按照这个逻辑设计的，即使你用 new 关键字分配了堆内存，但编译器如果认为在栈中分配不影响功能语义时，会自动改为在栈中分配。

当然，在栈中分配内存也有缺点，它有功能上的限制。一是， 栈内存生命周期有限，它会随着函数调用结束后自动释放，在堆中分配的内存，并不随着分配时所在函数调用的结束而释放，它的生命周期足够使用。二是，栈的容量有限，如 CentOS 7 中是 8MB 字节，如果你申请的内存超过限制会造成栈溢出错误（比如，递归函数调用很容易造成这种问题），而堆则没有容量限制。

所以，当我们分配内存时，如果在满足功能的情况下，可以在栈中分配的话，就选择栈。

内存对齐

CPU访问内存时，并不是逐个字节访问，而是以字长（word size）为单位访问。比如32位的CPU，字长为4字节，那么CPU访问内存的单位也是4字节。

这么设计的目的，是减少CPU访问内存的次数，加大CPU访问内存的吞吐量。比如同样读取8个字节的数据，一次读取4个字节那么只需要读取2次。

下面我们来看看，编写程序时，变量在内存中是否按内存对齐的差异。假设我们有如下结构体：

struct Foo {
    uint8_t  a;
    uint32_t b;
}


我们假设CPU以4字节为单位读取内存。

如果变量在内存中的布局按4字节对齐，那么读取a变量只需要读取一次内存，即word1；读取b变量也只需要读取一次内存，即word2。

而如果变量不做内存对齐，那么读取a变量也只需要读取一次内存，即word1；但是读取b变量时，由于b变量跨越了2个word，所以需要读取两次内存，分别读取word1和word2的值，然后将word1偏移取后3个字节，word2偏移取前1个字节，最后将它们做或操作，拼接得到b变量的值。

显然，内存对齐在某些情况下可以减少读取内存的次数以及一些运算，性能更高。

另外，由于内存对齐保证了读取b变量是单次操作，在多核环境下，原子性更容易保证。

但是内存对齐提升性能的同时，也需要付出相应的代价。由于变量与变量之间增加了填充，并没有存储真实有效的数据，所以占用的内存会更大。这也是一个典型的空间换时间的应用场景。

tmpfs

我们通过df可以看到tmpfs是挂载到/dev/下的shm目录，tmpfs是什么呢?

其实是一个临时文件系统，驻留在内存中，所以/dev/shm/这个目录不在硬盘上，而是在内存里。因为是在内存里，所以读写非常快，可以提供较高的访问速度。linux下，tmpfs默认最大为内存的一半大小，使用df -h命令刚才已经看到了，但是这个df查看到的挂载内存大小的数值，如果没有使用，是没有去真正占用的，只有真正在tmpfs存储数据了，才会去占用。比如，tmpfs大小是499M,用了10M大小，内存里就会使用真正使用10M，剩余的489M是可以继续被服务器其他程序来使用的。但是因为数据是在内存里，所以断电后文件会丢失，内存数据不会和硬盘中数据一样可以永久保存。了解了tmpfs这个特性可以用来提高服务器性能，把一些对读写性能要求较高，但是数据又可以丢失的这样的数据保存在/dev/shm中，来提高访问速度。

总结

32系统cpu访问内存的过程

  • 访问虚拟地址为n的字节数据
  • 通过该进程的页目录及虚拟地址映射匹配物理地址
  • 找到ram中该物理地址所在的byte数据
  • 由于32位系统可响应4个byte,固虽然只访问一个byte,但是会将该byte及后续的3个byte同时响应
  • 将获取到的数据保存至cpu cache中

附