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要慢。