从下往上看内存

Posted 2021-12-30 一口Linux

1 内存条、总线与DMA

计算机组成中内存或者叫主存是非常重要的部件。内存因为地位太重要，所以和CPU直接相连，通过数据总线进行数据传输，并通过地址总线来进行物理地址的寻址。

除了数据总线、地址总线还有控制总线、IO总线等。IO总线是用来连接各种外设的，例如USB全称就是通用串行总线。再比如PCIE是目前最常见的IO总线之一。这里放一张B站硬件茶谈的一张图。

图1-1 硬件图

图中CPU和左侧内存条直接连，并通过PCIE总线与下方的PCIE插槽连接，在PCIE插槽上可以插显卡，网卡，声卡，硬盘等等。PCIE带宽是共享的，如果某个设备用了x1路带宽，则能用的就少一路，因为本质上每一路都是串行的。南桥和CPU之间也有PCIE通道，主要是提供给一些带宽占用很低的外设。

南桥芯片位于主板上，一般在右下角，有个被动散热下面压着。南桥中有个很重要的设备就是DMA控制器，或者叫DMAC。DMA直接内存访问，意思就是DMAC能够直接访问内存。即一般进行IO的时候，cpu会把总线完全交给DMAC（DMAC和CPU会分时掌控总线），DMAC访问设备如磁盘，将数据读到内存中，因为此时接管了总线，所以可以写内存。在这个过程中CPU可以进行其他的任务。这也是异步IO、非阻塞IO等理论的基础。

计算机常考题：

图1-2-1 题目1

图1-2-2 题目2

2 操作系统内存管理与分类

2.1 虚拟内存（逻辑内存）

win32程序从程序上能操作的逻辑地址空间有4G这么大（虽然实际可能用不了那么多），4G的逻辑地址需要全部映射到物理内存上。映射的最小单位如果是字节的话，映射表将会非常大，且效率低下。提出page概念，即最小的映射单位是一个page，一页一般是4K这样的大小，我的机器是这样的，所以下面程序demo中页大小都是4K。

显然逻辑空间可能比实际要大，但是只要程序没有用那么多内存，就不需要去映射那么多page，且就算用了那么多内存，也可以映射到磁盘上。

逻辑页是抽象的，需要映射到物理的页上，才能完成对内存的操作。我们把逻辑页叫页（page）物理页叫帧（page frame）。页号-帧号的映射表叫页表（page table）。

图2-1 页表映射

因为每个程序看到的逻辑地址空间都很大，所以程序变多了之后，程序使用的内存大于了物理内存，此时一般通过将部分"不着急使用"的页映射到磁盘的方式来解决。所以页表中映射项可能是磁盘。

图2-2 页表映射

同时每个进程都有自己的专属页表，如下：

图2-3 多进程的页表

一种实际情况，4G逻辑地址有32bit地址空间，假设pageSize=4K偏移量占12bit，因而页表的逻辑页号有20bit。再假设实际内存条只有256M 28bit地址空间 12bit偏移量 16bit页号。

逻辑地址0x 00001 1a3，去映射的时候00001就是逻辑页号，去查页表发现映射到真实页帧号00f3，然后偏移量不变还是1a3，最终就找到这个物理内存内容了。

图2-4 页表的映射过程

这个过程中，可能会出现映射的帧号是disk，即映射到了磁盘上。此时会触发缺页异常，进入内核态，内核从磁盘中读取缺的这页内容，将其加载到物理内存中。但是物理内存的帧有可能所有帧都满了，此时就需要逐出不太"重要"的帧。

逐出的过程需要判断当前物理页(帧)是否是脏的（脏：与磁盘中内容不一致，即从磁盘加载到物理内存后被改过就是脏的），如果是脏的还需要更新磁盘中的内容保证一致。

逐出后就腾出了位置给从磁盘中读到的这页的数据，然后需要更新页表的这一项的映射关系，将磁盘改为帧号，然后重新进行查页表这一步。

逻辑层的作用：极大的降低了内存碎片；借助磁盘可以实现"无限的内存"；各个进程间内存的安全性等。

一个地址中“住”的是一字节(8bit)的数据。

2.2 快表TLB、多级页表

上面提到了逻辑-物理页的映射，这就是页表，但是上面的页表其实除了简单的页号映射，还存储了其他一些属性：是否有效，读写权限，修改位，访问位（淘汰算法和TLB中用），是否是脏（被修改过就是脏的，因为他和硬盘上的数据不一致），是否允许被高速缓存等等。

页表存于主存中，每个进程都有自己的页表。

上面可以看到基于页表的寻址，需要两次访问主存（页表是存在主存的），效率低下。为了提高速度，引入了快表，快表是页表项的缓存，将最近一次的映射项存入快表，因为空间有限所以需要逐出最老的那一项。快表的设计是基于经验：程序经常访问的page一般就那几个，不会经常频繁的更换特别多的页。

快表可能存于硬件MMU中（也可能是软件TLB），一般只有8-256条，每个进程都有自己的快表。

另一个值得讨论的话题是页表占用空间太大，上面例子中（32位程序256M机器pageSize4K）页号有20bit即2百万个，所以需要有1百万条，每条大小如果只算逻辑页号(20bit)和物理页号(16bit)的话：

36bit * 2^20 = 4.5MB

如果有64个这样的程序在运行...后果可想而知。

一种很好的解决方法是多级页表，第一级页表用于寻找第二级页表的编号。<20bit-16bit>的单级映射可以改成<10bit-10bit>和<10bit-6bit>两级映射。此时占用内存为

20bit * 2^10 + 16bit * 2^20 = 2M

2.3 分段

严格意义的分段是，每一段的虚拟地址都是从0开始。然后页表是段号+页号来映射帧号的。但是这种形式已经被废弃了，只有x86 32位的intel的cpu还保留了这种段页结合的方式，即严格意义的分段已经用的很少。

那为什么还经常听到段的概念？现在所说的段一般是程序在逻辑层面保留的概念，对逻辑地址有个粗略的划分，便于程序编写，但是并不影响os的内存管理（还是分页管理）。

以32位程序为例，在逻辑空间中最高的0xc0000000 - 0xffffffff这1G的内存是给内核留出的，这部分是所有进程共享的。剩余3G内存从低到高分别是Text、Data、Heap、Lib、Stack。64位程序则远大于这里的值。

Heap是从低往高增长，Stack是从高往低增长，且有个最大限制。Data存储静态变量Text存储程序二进制码，Lib存储库函数需要占用的内存，多个程序如果都使用了相同的库，内存是共用的（共享内存）。各个部分的留有随机的一段偏移量，可以保护程序，这也使得每次重新执行程序的时候变量所在的内存地址总是不同的。

图2-5 32位系统下内存地址的组成

分段是逻辑空间上的，不影响分页的内存管理方式，后面进行分页，映射到物理内存上各部分跨多个页其实并不连续。

2.4 cache

cpu的三级缓存扮演着缓存主存数据的作用，而cache在内存管理中的位置是怎样的呢？

PIPT，物理级cache，cpu分析完映射关系，先到cache找有没有该物理地址的cache。这样会非常的慢，但是所有进程可以共享cache。

VIVT，逻辑级cache，cpu直接通过逻辑地址找cache，miss后再查TLB页表这些。这样很快，但是逻辑地址只能对当期进程使用，其他进程完全不能复用，尤其是库函数这种共享的不能利用好cache。

VIPT，将两者结合，用逻辑地址查找cache，cache中数据部分前面添加一个对应物理地址的tag。这样拿到这个tag后到tlb、页表中查看下这个对应关系是否正确，如果正确就直接读cache。这样速度和共享性都是折中的。

以上三种方式各有优劣，在不同的cpu中可能使用的不一样。

2.5 内存地址大小

很多人想当然的会认为32位系统的虚拟地址是32位，这是没错的，但是64位系统下真正的可用的虚拟地址却不到64位。

#include <stdio.h>
int main()
    int x = 10;
    printf("%p",&x)

图2-6 C语言打印地址

明显看到是48位，虽然这个指针大小是8byte，但是只有48bit是有效的地址位，前面是多个0。通过cat /proc/cpuinfo最后几行能看到物理地址和虚拟地址的大小，这主要是cpu单方面定制的，我的这台机器是13年买的intel 酷睿i5 3230的CPU。当然我的系统内存只有2G，其实物理地址不会有43位，只是cpu最多支持43位物理地址。

图2-7 cpuinfo中的虚拟地址和物理地址

小细节：栈是仅次于内核的高位地址，参考图2-5. 所以看到前面这个地址基本能推算出分给内核的虚拟空间应该是0xffff ffff ffff - 0x8000 0000 0000。

2.6 内存分类

在生活中我们经常看到各种内存的种类，比如在linux调用free -h的时候可以看到图2-6的分类。

在linux中通过free -h可以看到当前系统的内存情况:

图2-8 free指令下的内存分类

mem是物理内存，swap是交换分区，是用来将内存暂时放到磁盘上的。

total总内存大小，used用户使用的内存大小，free空闲的内存大小，shared共享内存大小，buff/cache文件缓存大小，available可用内存大小是free和buff/cache加起来。

total = used（含shared） + free  + buff/cache

这里需要理解buff/cache，他们在老一些的内核中是分开显示的分别是buffer cache和page cache，都是对磁盘的缓存。其中buffer cache是硬件层面，对磁盘块中的数据进行缓存，缓存的单位当然也是块。而page cache是文件系统层面，对文件进行缓存，缓存单位就是页。buffer cache的提出非常的早，两者并存时会遇到重复缓存了相同的内容的情况。

较新的内核已经将两者合并，或者说将buffer cache合到了page cache。虽然也还是能缓存磁盘块，但是存储单位也是页了。并且buffer使用前会先检查page cahce是否已经缓存了对应内容，如果是则直接指过去。在机器维度查看内存的时候也能发现BufferCache都是0，因为都合到了pageCache，有Buffer的都是很老的内核的机器。

buff/cache占用大，会不会影响后续程序申请内存？

不会，一旦用户程序需要申请内存，buff/cache就会释放掉一部分。换句话说buff/cache是在内存比较空闲的时候，尽量利用一下来加速文件读写的。如果有大哥需要用内存，是会拱手让出的。

如果想进一步了解两者的演化，这篇文章从内核源码的角度展示了，几个理成本版本下buff cache 和 page cache的变化。

在windows任务管理器中又可以看到下图的几种状态的内存叫法，而在Jprofile查看jvm内存的时候也有图2-8的一些叫法。

图2-9 windows任务管理器内存分类

图2-10 jprofile内存分类

已提交的意思是已经向操作系统申请了这么多的内存，操作系统可以已经给了这么多内存了，但是也可能没有给那么多。贴一张微软自己的解释如图

图2-11 几种内存的解释

提交的内存因为是虚拟内存，并不一定系统会立刻给这么多，所以可能提交远超过物理内存上限的大小。我之前看过一个视频，小哥用malloc申请了130000+GB的内存程序才退出，而如果在malloc后给申请的地址填写值，事情就不那么顺利了。感兴趣可以去看下这个视频。当然不了解C语言也没关系我在本文后半段会用java的Unsafe同样申请超过物理上限的内存大小做demo。

3 内存相关的系统调用

3.1 内核态和用户态

内核态、用户态、内核空间、用户空间，是经常说起的概念。因为操作系统不允许用户直接操作硬件，所以需要用户程序通知内核，内核帮你下达指令给硬件。在进行读文件的时候，就需要用到磁盘这个设备，所以需要进入内核态，将文件内容读到内核buffer，然后拷贝到用户buffer并从内核态切换为用户态，程序才能真正拿到数据。

用户态进内核态，一般有三种触发条件，中断、异常和系统调用，中断和异常有时候界限比较模糊，例如缺页中断也有地方叫缺页异常。这里我们引出了系统调用，大多数需要主动操作或读写硬件的都是通过系统调用。例如读写文件的open/read/write是系统调用，网络传输常见的select/poll/epoll也是系统调用，申请内存的malloc底层也是通过brk或mmap这俩系统调用实现的。

系统调用伴随了很多设计的优化，例如通过epoll等系统调用实现的IO多路复用提高了网络包的处理效率，mmap、sendfile等系统调用实现的零拷贝，减少了用户空间和内核空间之间的数据拷贝和上下文切换次数等等。在java的NIO中有大量的函数是直接封装了系统调用。

3.2 brk

malloc小于128K（阈值可修改）的内存时，用的是brk申请内存。C语言中sbrk(可函数)是brk(系统调用)的简单封装，下面代码打印的值可以看出first因为申请了0大小，所以和second指针位置相同。而third则表示的是second的尾部地址。可以看到虚拟地址是连续分配的，brk其实就是向上扩展heap的上界，配合查看图2-5。

#include <stdio.h>
#include <unistd.h>
int main()
    void *first = sbrk(0);
    void *second = sbrk(1);
    void *third = sbrk(0);
    printf("%p\\n",first);
    printf("%p\\n",second);
    printf("%p\\n",third);

图3-1 brk代码输出

如果此时在 third+1地址处去初始化一个int值，是可以成功的，并不报错。

#include <stdio.h>
#include <unistd.h>
int main()
    void *first = sbrk(0);
    void *second = sbrk(1);
    void *third = sbrk(0);
    int *p = (int *)third+1;
    *p = 1;

这是因为页大小是4K，sbrk(1)其实也是申请一页，所以third+1位置也是安全的。如果我们将second这行改为4096，那就是另一个故事了,会触发段错误。

void *second = sbrk(4096);

图3-2 brk代码输出2

3.3 mmap

malloc大于128K的内存时，用的是mmap。

// addr传NULL则不关心起始地址，关心地址的话应传个4k的倍数，不然也会归到4k倍数的起始地址。
void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
//释放内存munmap
int munmap(void *addr, size_t length);

mmap用法有两种，一种是将文件映射到内存，另一种空文件映射，也就是把fd传入-1，就会从映射区申请到一块内存。malloc就是调用的第二种实现。

#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
int main()
    int* a =(int *) mmap(NULL, 100 * 4096, PROT_READ| PROT_WRITE, MAP_PRIVATE| MAP_ANONYMOUS, -1, 0);
    int* b =a;
    for(int i=0;i<100;i++)
       b = (void *)a + (i*4096);
       *b =1;
    
    while(1)
        sleep(1);
    

这里提交400K内存的申请，并且在每页中都进行内存的使用。可以看到不映射文件的话触发的是minflt次数是100次。

图3-3 进程的内存minflt

这里是mmap内存的惰性加载，一开始mmap100页时其实都没有分配给进程，在用到的时候开始真正拿到内存，此时触发minflt缺页，因为不是映射的文件，不用从磁盘中调内存，所以是小错误。但是仍是消耗性能的。

如果mmap是映射的磁盘文件，也会惰性加载，在初次加载或者页被逐出后再加载的时候，也会缺页，这个时候就不是小错误minflt了，而是majflt。例如下面使用mmap来读文件。

#include <sys/types.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <stdio.h>
#include <sys/stat.h>
#include <unistd.h>

int main()
        sleep(4);
        int fd = open("./1.txt", O_RDONLY, S_IRUSR|S_IWUSR);
        struct stat sb;
        if(fstat(fd, &sb) == -1)
                perror("cannot get file size\\n");
        
        printf("file size is %ld\\n",sb.st_size);
        char *file_in_memory = mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);

        for(int i=0;i<sb.st_size;i++)
                printf("%c", file_in_memory[i]);
        

        munmap(file_in_memory, sb.st_size);
        close(fd);

下图是线程监听的结果，为了方便观察我在开始读之前sleep 4s。可以看到红框第一行，有一次majflt，这是第一次去读文件，直接触发了缺页异常，且指向磁盘。是最耗时的错误。

图3-3-2 进程mmap读文件引发majflt

read和mmap都可以读文件，前者有状态转换和多次拷贝，但是后者有缺页中断。在单纯读磁盘文件场景，两者其实没法在孰优孰劣上有定论。

3.4 共享内存

共享内存是进程间通信的一种方式，（管道 信号 信号量 套接字也是进程通信的方式）。共享内存的例子比比皆是，windows下最明显，比如这个上传文件的对话框就是共享内存里的,同一时间windows下不会弹出两个该对话框。再比如动态链接库，也是共享内存中的，多个进程可以共享，两个进程mmap相同文件的方式可以实现共享内存，shmget则是更广泛的共享内存的系统调用。

图3-4 共享内存的典型例子

共享内存原理就是两个进程中页，映射到了相同的帧。代码这里不写了，直接参考geeks这篇的代码。

4 java中的内存

4.1 java内存概述

jvm内存结构主要如图4-1.本文不想对“常考”的知识点再次进行讲解，网上有大量的文章来讲内存结构各自的用途和GC相关的内容，这里我就不展开讲了。下面几节会讲一些比较"冷门"的知识。

图4-1 java的内存五区

4.2 对象头与指针压缩

在另一篇讲计算java对象大小的文章中提到，java对象是由对象头，对象内容组成，并且是8字节对齐的。其中对象头有以下三部分组成：

• Mark Word(64bits) 当前对象一些运行时数据如锁
• Klass Word(开压缩32bits，不开64bits) 类型指针，指向类元数据Klass地址
• array length(32bits) 数组对象才有

我们这里来看下Klass，有没有想过我们反射的时候操作的都是Class对象而不是这里的Klass，两者关系是:

Klass是C++对象InstanceKlass，里面有个_java_mirror字段指向对应的Class对象。

图4-2 java对象头指向metaspace

这里还提到了指针压缩，64位系统，如果jvm堆内存小于32GB是可以开启指针压缩的，此时Klass指针只需要4个字节，同时对象指针也只需要4个字节。这里会衍生出两个问题：

第一个就是4字节最多表示2^32个地址，每个地址里住的是一个字节，所以只能表示4GB，怎么还说32G下都能压缩呢？

因为：上面提到对象都是8字节对齐，所以每个地址里住的是8字节，所以可以表示32GB，实际地址移3位。

第二个问题就是普通对象指针压缩Compressed Object Pointers (“CompressedOops”)，压缩的是java堆上的对象的指针(引用)大小，而对象头指向的是Klass，这是个C++的结构，这个指针也压缩了吗？

是的，CompressOops和CompressKlass是相伴而生，默认同时开启的，Klass这部分需要连续的<4G的内存，因为是C++结构，没有8字节对齐限制，所以4字节只能在4G内存上寻址，默认大小是1G。

4.3 metaspace

metaspace存储的是类的元数据信息，上面提到的Klass就是在metaspace中的，一般开启压缩的metaspace有CompressClassSpace和NonClassSpace两部分组成，其中前者内存占用较少，是后者的5-100分之一，前者又叫压缩类空间，实际上这部分内存本身并没有压缩，只是对象头中记录的指向这里的指针进行了压缩。

图4-3 metaspace两部分：非类区和压缩类空间

压缩类空间中Klass是c++的对象有着很多元数据字段，vtable是记录虚方法指针，itable是接口方法指针。Non-class中则记录了更详细的元数据信息。开启指针压缩后，如果设置MaxMetaspaceSize参数实际上是限定的Non-class部分的大小，而不包括压缩类空间。通过Jprofile中也能发现Metaspace只包括Non-class部分，那为什么我上来说Metaspace有两部分呢，主要是从概念上讲两者都是元数据，在国外很多文章中也都归为了Metaspace。这里只需要注意这个小细节就可以了。设置MaxMetaspaceSize参数也可以对压缩类空间起到间接的限制，因为前面说了Non-class部分是class部分的n倍。

图4-4 指针压缩开启时 非堆

将压缩类空间和非类空间分开的原因之一，就是压缩类空间是对象关联的，只有4G上限，而将更多其他元数据剥离出去后，元空间可以远超过4G。而如果不开启指针压缩，其实两者就没必要分开了。关闭指针压缩后，-XX:-UseCompressedOops 两部分会合为一个。统称Metaspace

图4-5 指针压缩关闭时非堆

Q1：元空间内存什么时候分配？

一个新的类在需要被加载的时候，会使用ClassLoader在元空间申请内存，并存储类的元数据信息。

Q2：元空间什么时候释放内存？

元空间的内存是ClassLoader持有的，所以说只有对应的ClassLoader卸载掉的时候才会释放。ClassLoader又是需要他所加载的类都消失的时候才能消失。一般是伴随在一次GC的过程中进行这个释放。另外元空间如果超过了上限也会导致OOM。

Q3：metaspace溢出会不会导致OOM?

当然会导致OOM，所以metaspace限制大小的配置，需要根据程序谨慎定制。一般通过不断创建新的类，如加载新类（如hsf配置中下发groovy文件就会动态的加载新的class），或者动态代理类（spring中的增强类都是动态代理类）都会导致metaspace的增长。

<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>3.2.4</version>
</dependency>

//设置metaspace大小：-XX:MaxMetaspaceSize=200m
public class T 
    public static void main(String[] args) 
        while (true) 
            Enhancer enhancer = new Enhancer();
            enhancer.setSuperclass(Object.class);
            enhancer.setUseCache(false);
            enhancer.setCallback((FixedValue)()->":)");
            enhancer.create();
        
    

监视会发现压缩类空间和非类空间都在增大，后者在200M上有道红线，在2分钟左右溢出，程序挂掉，这个程序中压缩类空间大概是分类的六分之一。

图4-5a 压缩类空间

图4-5b 非类空间

4.4 堆外内存

上面的CodeCache和Metaspace毫无疑问是jvm管理下的堆外空间。但是除了这些常规的堆外空间，jvm还可以使用一些native方法，直接申请堆外内存。

例如做这么个demo，我们设置一个简单的java程序的堆大小是10M，此时用jprofile查看内存堆提交了10M实际使用9M多，堆外提交了12M实际使用11M左右。所以算下来是20M+。直接查看进程内存会略大于这个值，因为这个20M是虚拟机内部的内存，本身运行还是需要一些额外内存的，进程提交的内存有90M，实际使用内存47M

图4-6 进程的提交内存和实际内存

接下来我们使用Unsafe申请1G堆外内存（也可以用NIO中的ByteBuffer.allocateDirect()）

public static void main(String[] args) throws InterruptedException, IllegalAccessException, NoSuchFieldException 
    Field f = Unsafe.class.getDeclaredField("theUnsafe");
    f.setAccessible(true);
    Unsafe us = (Unsafe) f.get(null);
    long addr = us.allocateMemory(1024 * 1024 * 1024);
    System.out.println("Hello World");
    System.out.println(addr);
    while(true)
        Thread.sleep(1000L);
    

可以看到提交的内存1G多，实际使用内存也是47M。

图4-7 进程的提交内存和实际内存2

我甚至可以调整申请65G的内存，要知道我的电脑也只有64G的内存，但这仍不会报错，可以看到提交的内存已经超过了物理内存上限，但是得益于前面讲的虚拟内存的管理模式，使得应用申请了超过物理大小的内存，而如果真的使用起来的话，会有页置换来协调。

图4-8 进程可以提交超过现实存在的内存

上面的提交内存很大但是实际使用内存却并不大：

图4-9 任务管理器此时的状态

Unsafe是很危险的一个类，不建议使用。但是可以帮助我们理解有些框架是如何工作的。比如前一阵子看的Ehcache就提供了堆外缓存就是用类似Unsafe申请的。堆外缓存需要自己实现序列化，因为Unsafe设置内存只能设置01字节码不能设置为java对象。

堆外缓存的好处：缓存一般是短时间不需要清理的，如果在堆上则肯定会进入老年代，占用固定的一大块空间，使得触发full GC的门槛降低了，很容易到了那个门限值。而且GC过程中还要去遍历这些对象，效率较低。

堆外内存的坏处：序列化需要自己实现，清理也需要自己实现，访问速度比heap要慢。