---

1.线程/协程/异步

左边3个线程交叉运行完。DMA过程中cpu一段时间不被线程阻塞。DMA进行数据读取时可复用，因为cpu的总线程具有多条线路，所以DMA可充分利用这些线路，最终实现并行读取这些文件。通过以上两点大大提高了cpu利用率。线程想提高效率和io密切相关，程序往往都含有io。CPU上下文切换就是先把前一个任务的CPU上下文(也就是CPU寄存器和程序计数器)保存起来，然后加载新任务的上下文，到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。



线程是操作系统级别概念，程序中想要开辟多线程需调用系统底层API才能进行多线程的开辟，在多线程开辟过程中浪费时间，并且在线程运行中上下文切换部分（左边切换多次，右边切换三次）有用户态和内核态转换耗时，所以一部分效率浪费在cpu切换时间点上。所以有了协程：协程是编程语言级别的线程，底层协程不是线程并不告诉操作系统我是新开辟的线程，因而全程处于用户态即协程是用户自定义的线程，协程可大量开辟不用担心用户态和内核态转换，一台机器上几百上千线程可能是极限，但用go语言开辟协程随便几千万

2.IO多路复用select/poll/epoll

select返回后（如下最后5行）再遍历fd集合中5个fd并判断哪一个fd被set置位了，被set的那个有数据将它数据读出来并puts（处理），和上面用程序判断fd有无数据再处理思路一致。rset被内核set置位了需要每次while回来FD_ZERO赋空值再FD_SET将fd赋到rset中

system是一个C/C++的库函数，select是系统函数以下是4个缺点

如下pollfds数组里有5个pollfd结构体

epfd是共享内存不需要用户态切换到内核态，最后只遍历nfds，不需要轮询，时间复杂度为O(1)。epoll解决select的1，2，3，4

redis，nginx，javaNIO(linux)都用的是epoll。多路io复用借助了硬件上优势DMA

1、SSD与传统磁盘相比，第一是没有机械装置，第二是由磁介质改为了电介质。SSD没有传统磁盘的寻道时间和延迟时间。
2、基于SSD的优化就是解决erase-before-write产生的写入放大的问题。
3、优化原理：a.将sequential logging修改为In-page logging，避免对相同位置的反复擦写。b.通过缓存写入的方式将大量的in-place update随机写入合并为少量顺序写入。c.利用SSD随机读写能力高的特点，减少写增加读，从而达到整体性能的提升。

4.操作系统内存管理

用户态与内核态：程序处于的状态，切换触发条件就是程序需要申请外部资源。brk和mmap申请的都是虚拟内存，不是物理内存，想真拿到物理内存空间还要第一次访问时发现虚拟内存地址未映射到物理内存地址，于是促发一个缺页中断（异常）。java和c++中new对象申请内存空间，也是经过这么过程

man syscalls

逻辑地址：程序自身看到的内存地址空间，是抽象地址。逻辑地址需要映射到物理内存才能完成对内存操作，那为什么程序操作是虚拟的逻辑地址，不能直接操作物理地址即对内存条操作？因为程序是写死的，这样操作的地址是固定的，而硬件可用的地址是变化的：内存条哪些地址被占用了是一直在变化的。操作系统多进程，当前进程需操作的地址可能其他进程在使用，这样的话不能使用这块地址了，所以说除非是单进程机器，否则为了进程安全必须做出逻辑地址和物理地址的映射，所以必须要有逻辑地址，必须要有映射。如下程序1的偏移量是0，程序2的偏移量200。如果程序1操作的逻辑地址是100，那么映射的物理地址也100（因为偏移量0）。如果程序2操作的逻辑地址是50，映射到物理内存250（因为偏移量50）

固定偏移量做法看上去简单高效，但存在两个重大缺陷，第一个缺陷：程序使用的内存其实无法计算的，随时间的推移，进程使用的内存不断变化的。这里我们说程序1使用200的内存，这种说法本身不太对的，因为我们没法去限定一个程序使用的内存大小，当然你可以说我估算了这程序使用的最大内存就是200，但这也代表整个200的一段内存中，程序使用的内存绝大多数时间都小于200的，以及这蓝色区域中内存使用率并不高，其中存在很多没有利用起来的内存，我们把没利用起来的内存叫内碎片。第二个缺陷：当程序运行完，内存被释放，比如程序1执行完后，0-200这块地址被释放出来了，此时程序3使用了内存大小是201，这时程序3没法直接使用0-200这段内存了，假设很长一段时间内都没有占用200以内的内存这样的程序被创建，那么0-200一直被闲置，称这段内存为外碎片

为了减少碎片问题，于是提出了分页思想：将内存空间包括逻辑内存（左）和物理内存（右）都进行切分，分成固定大小很多片，每一片称它为页（逻辑地址：页，物理地址：帧）。页到帧的映射需要有个表来维系，这个表就叫页表即pagetable（pagetable存了页号帧号，还有当前这一页读写权限等等）。页表是每个进程都需要维护的，因为每个进程映射关系是互相独立的，所以不能共用映射表，每个进程有自己的pagetable



操系内存管理主要使用虚拟内存（左），即我们的程序看到的内存地址是虚拟地址（这些地址连续），但实际映射到真正物理地址（右）可能不连续，散落在各个页中。如下左边1，2，3…每一块叫页，虚拟地址可能比物理地址大，盛不下时多出来部分可将虚拟地址的页映射到磁盘上，但映射到磁盘上导致下一次读映射到磁盘上这一页内存时会触发一个缺页中断进入到内核态，整个会产生一个大（major）错误

下面分析OX000011a3这个逻辑地址映射到物理地址过程。0-9999的数，你需要用多少位数表示啊，是4位就行对吧，9999就是256M，4就是28

硬盘数据加载到内存帧中（磁盘换进物理内存），如果当前所有帧满了，那这时加载到哪个帧中呢？有一个页/帧置换算法，将最少使用的一帧逐出放到磁盘中，所以linux下这磁盘部分又叫swapping

如下帧号不冲突就能保证安全性。第四点是缺点：页表存在我们主存中即存在内存中，如果我们要对某一个内存进行访问的话其实要读取两次内存。因为先读取页表，从页表中拿到对应帧号，再拿帧号去内存中再查询一遍，对内存操作有两次读取。页表存在主存中其实也比较占空间，所以要在时间和空间上优化


比如堆区，栈区就是程序的段，早期纯的分段其实将程序分成多个大的内存区，比如分成4个段，每个段分别对应很多页，每一段所看到的逻辑地址都从0开始，比如一个程序分为4个段，每个段都从0开始的逻辑地址。分段和分页可结合，一个段都有对应页表的部分即我们的页表可设计成含3项：段号，页号，帧号，原来是页号对应帧号，现在使用段号+页号才能对应一个固定帧号，这种方式其实效率低，目前被大多数软硬件抛弃了，完全意义上分段现在不太存在了，X86_64这些架构的cpu种不再使用这种段页结合式了只使用分页。这么说好像分段已经被淘汰了，但现在还是听到和段相关的如：C语言中段错误，如写程序中用到堆栈这样的段概念，这是为什么呢？原来段保留了逻辑上意义但并不在内存管理中起到作用

如上是一个C语言分段形式，如果是一个32位程序，它的虚拟地址就是4GB，分段就是对虚拟地址分成了多个段，从低到高，最高1G空间留给内核（kernel space），不同程序是共享这1G空间的。最下面有两个段是text，data，text：存程序本身二进制字节码，data存程序中一些静态的变量。再往上是堆Heap，堆是向上增长的（也就是地址往上增长的），看高区stack栈区从高往低增长。中间是Libraries函数库区，如linux中C常见的函数库so文件，windows下的dll动态链接库都放到堆和栈中间一段区域的（malloc若申请>128k的内存会调用mmap，在堆和栈之间区域申请内存和这里lib区其实是相同位置，因为他们都是页，映射磁盘【mmap就是文件映射内存的系统调用】）。进程是可共享这段Libraries函数库，这就是之前讲的进程间通信的共享内存方式。共享内存极其常见，例如windows下选择文件的那个对话框

如下内核区这部分内存大家是共享的，大家都映射到kernel区。栈区各自有自己映射的栈区（堆区也是），库区（libraries）可能是多个进程共享一个或多个库，蓝紫相间库区是2个进程所共享的


并发（线程）之可见性





发生场景：线程2不能立即读到线程1写后的最新变量值，多线程不可见性

如何解决多线程不可见性：加volatile关键字使a在主存和localcache间强制刷新一致

5.从下到上看内存

5.1 内存条/总线/DMA

硬件–>OS–>用户程序系统调用，内核帮我们调内存–>jvm。io总线最常见的USB（通用串行总线），PCIE总线也是io总线


Nodejs是单线程，但在读文件时，文件还没读完却可以执行下面几行程序，文件读完后触发一个回调，因为单线程按理来说cpu直接读磁盘中文件的话，应该一直读取这文件，读完前不能进行其他操作，它怎么做到执行其他操作的呢？需要有硬件支持即DMA，读文件操作是非常机械劳动，cpu资源宝贵不能干这种活

5.2 OS内存管理与分类

free和available什么关系呢？目前能用的内存到底206M还是1.6G呢？是1.6G，一般used包含shared，free是真正的空闲，没有任何东西在使用的大小。文件磁盘缓存指读过的文件暂时帮我们缓存到内存中下次再读的时候直接从内存中拿出来就能加速对文件读写操作，但这部分内存并不是强制需要保留的，比如说现在free的空间只有206M，我有个程序要用1G内存，能好用吗？能，buffer/cache这边1.6G有800M扔出去释放掉给程序用，也就是说buff尽量缓存一些文件，如果其他程序要用了，buff优先级很低立马释放掉了，所以一般要看能用的内存有多大，一般看available，不是去关注free。

buff/cache中间为什么有个/，较早内核中free-h看分buffcache（以磁盘扇区为单位直接对磁盘缓存，从硬件扇区看缓存）和pagecache（以页为单位对磁盘文件缓存，从文件系统看缓存）两项。两项有重复的地方，文件本质也是磁盘，如缓存一文件，如果有buffercache再缓存pagecache重复，所以较新的内核中看就是合起来的buff/cache。上面是linux内存，下面看window内存，虚拟内存映射到物理内存也能映射到磁盘中（linux中看到的mem和swap两个分区），已提交的69.2G是mem（物理内存64G）+swap（windows下不是swap分区，而是.sys文件，文件管理器下看不到受系统保护）

已提交：目前电脑上运行的所有程序向操系os申请了58G内存，但使用只有34G，原因：你申请了这么多，OS不一定给你这么多，比如C用malloc申请1G内存，假如只使用了1M，这时程序实际占用内存就是1M，剩下1023M你用到再给你，所以已提交大于使用中量，甚至说已提交的量可以大于整个OS内存大小如1T（物理内存一共才64G）。已缓冲对应linux中buffer/cache即对文件的缓冲，已缓冲29.4G等于可用的29.4G，可用的内存全用来缓冲磁盘的文件了

5.3 内存相关的系统调用

系统调用是用户态切内核态方式之一，申请内存就需要使用系统调用。用户无法操作硬件如内存条，必须交给内核帮我们操作完了再把结果给我们，malloc是C库函数当小于128k调用brk，大于128k调用mmap。C语言中有sbrk库函数是对brk的一个封装，如下brk申请内存，内存是连续的，并不是说在堆空间随便找内存就把空间给你，换句话说：brk是提高了堆Heap部分上界

(first+1) 前面的星号对它赋值，赋一个int值，也就是说当前我们是对第5，6，7，8四个字节赋int值123，只有第一个字节通brk申请出，却给第5-8字节赋值，这样会不会报错呢？不会，主要原因是在上节讲到的操系内存的分页管理所导致的，也就是说brk申请内存申请最小单位为1页，一般系统中页大小4k，所以brk看似申请1字节其实申请了一页（4096个字节），所以第5-8字节也属于4096字节里，也是当前进程所能支配的内存，所以不报错




如下触发大错误因为对文件的映射，将文件映射到内存，但也是惰性的，这文件没有直接读到内存里，而是当真正需读文件里内容时才会映射到内存里，如上for循环里打印文件内容时，这时它会取到内存中读，发现这一页在查页表时对应是磁盘就触发一个缺页错误，并且对应是磁盘，触发majflt，将磁盘内容加载到内存中，之后就是一些小错误了（大错误后文件全部加载到了物理内存，后面小错误是要把虚拟内存对应到物理内存上）

mmap和普通的fread（库函数）或read（系统调用）读文件有什么区别呢？read过程：调用read系统调用进入内核态，内核态将文件内容加载到内核空间（kernel space），内核空间给它复制到用户空间，再从内核态切换到用户态，然后用户的程序就可读到文件的内容了，有个文件-内核空间-用户空间周转过程。mmap直接将文件进行了映射，一开始在页表中填充的是磁盘，一开始mmap是惰性的直接对应磁盘文件，真正读取时触发缺页将文件加载到内存中（页/绿色）
这里的共享是简单的共享，只是说内核空间对应页表中的k对应value和用户空间k对应value是同一个值且都映射文件所对应的物理内存，看似达到共享效果但跟进程间共享内存不是一个东西，这过程好处：在缺页异常触发完成后，就可看到文件内容直接映射到用户空间一分区中，虽然也是堆和栈间区域但不是lib区（lib区应该是专门放动态链接库）。用户空间并不需要通过内核空间周转可直接对文件操作，省去了内核空间到用户空间拷贝过程
所以mmap也是实现0拷贝技术一种方式（sendfile），mmap这么牛干嘛还用read函数？mmap虽减少了内核空间到用户空间拷贝，但mmap没法利用前面讲的buffer/cache对文件缓冲这么一块空间，而且mmap第一次触发的缺页异常不是很稳定，并没有一个绝对性能比read好