图解操作系统笔记

硬件基础 CPU是如何执行程序的？ 程序执行的基本过程 第一步，CPU 读取「程序计数器」的值，这个值是指令的内存地址，然后 CPU 的「控制单元」操作「地址总线」指定需要访问的内存地址，接着通知内存设备准备数据，数据准备好后通过「数据总线」将指令数据传给 CPU，CPU 收到内存传来的数据后，将这个指令数据存入到「指令寄存器」。第二步，「程序计数器」的值自增&#x 0 Comments

硬件基础

CPU是如何执行程序的？

程序执行的基本过程

  • 第一步，CPU 读取「程序计数器」的值，这个值是指令的内存地址，然后 CPU 的「控制单元」操作「地址总线」指定需要访问的内存地址，接着通知内存设备准备数据，数据准备好后通过「数据总线」将指令数据传给 CPU，CPU 收到内存传来的数据后，将这个指令数据存入到「指令寄存器」。
  • 第二步，「程序计数器」的值自增，表示指向下一条指令。这个自增的大小，由 CPU 的位宽决定，比如 32 位的 CPU，指令是 4 个字节，需要 4 个内存地址存放，因此「程序计数器」的值会自增 4；
  • 第三步，CPU 分析「指令寄存器」中的指令，确定指令的类型和参数，如果是计算类型的指令，就把指令交给「逻辑运算单元」运算；如果是存储类型的指令，则交由「控制单元」执行；

简单总结：一个程序执行的时候，CPU 会根据程序计数器里的内存地址，从内存里面把需要执行的指令读取到指令寄存器里面执行，然后程序计数器根据指令长度自增，开始顺序读取下一条指令。

  • 在指令寄存器中，CPU会分析指令寄存器中的指令，确定指令的类型和参数，如果是计算类型的指令，就把指令交给「逻辑运算单元」运算；如果是存储类型的指令，则交由「控制单元」执行；
  • 程序计数器自增的长度与CPU位宽决定，比如 32 位的 CPU，指令是 4 个字节，需要 4 个内存地址存放，因此「程序计数器」的值会自增 4；

CPU 从程序计数器读取指令、到执行、再到下一条指令，这个过程会不断循环，直到程序执行结束，这个不断循环的过程被称为 CPU 的指令周期。

  • 冯诺依曼模型定义了计算机基本结构：运算器、控制器、存储器、输入输出设备。
  • 内存
    我们的程序和数据都是存储在内存，存储的区域是线性的。
    在计算机数据存储中，存储数据的基本单位是字节（byte），1 字节等于 8 位（8 bit）。每一个字节都对应一个内存地址。
  • 中央处理器（CPU）
    中央处理器也就是我们常说的 CPU，32 位和 64 位 CPU 最主要区别在于一次能计算多少字节数据。这里的32位和64位，通常表示CPU的位宽。
    • 32 位 CPU 一次可以计算 4 个字节；（4个字节就是32位 4 * 8）
    • 64 位 CPU 一次可以计算 8 个字节；

CPU内部还有一些组件，常见的有寄存器，控制单元和逻辑运算单元

  • 控制单元：负责控制CPU的工作。
  • 逻辑运算单元：负责运算。
  • 寄存器：存储计算时的数据，由于内存离CPU太远了，而寄存器就在CPU内部，计算速度更快。寄存器有以下几种：
    • 通用寄存器：存放需要运算的数据。
    • 程序计数器：存储CPU要执行的下一条指令的地址。
    • 指令寄存器：存放当前正在执行的指令。
  • 总线
    负责各种设备之间的通信。比如CPU读取内存数据时，要通过三个总线：
    1. 先通过地址总线来指定内存的地址。
    2. 再通过控制总线来指定读或写的命令。
    3. 最后通过数据总线来传递数据。
  • 线路位宽与CPU位宽
    • 线路位宽：数据在线路中传输，其实是通过操作电压，低电压表示0，高电压表示1。这样一位一位进行传输的方式称为串行，想要一次性多传输数据，可以增加线路的位宽。比如CPU 想要操作内存地址就需要地址总线，可以通过增加线路位宽的方式，增加CPU能操作的最大内存地址数量。（注意，不是说同时操作的最大内存地址数量）
      • 如果地址总线有 2 条，那么能表示 00、01、10、11 这四种地址，所以 CPU 能操作的内存地址最大数量为 4（2^2）个。那么，想要 CPU 操作 4G 大的内存，那么就需要 32 条地址总线，因为 2 ^ 32 = 4G。（32位对应有232 个地址，对应的内存数是232 * 8bit=4Gbyte即4GB）
    • CPU位宽：CPU 的位宽最好不要小于线路位宽，否则工作起来会非常复杂且麻烦。如果计算的数额不超过 32 位数字的情况下，32 位和 64 位 CPU 之间没什么区别的，只有当计算超过 32 位数字的情况下，64 位的优势才能体现出来。
      • 另外，32 位 CPU 最大只能操作 4GB 内存，就算你装了 8 GB 内存条，也没用。而 64 位 CPU 寻址范围则很大，理论最大的寻址空间为 2^64。
  • a = 1 + 2的执行具体过程
    • 程序—>汇编语言—>计算机指令
      CPU 是不认识 a = 1 + 2 这个字符串，这些字符串只是方便我们程序员认识，要想这段程序能跑起来，还需要把整个程序翻译成汇编语言的程序，这个过程称为编译成汇编代码。针对汇编代码，我们还需要用汇编器翻译成机器码，这些机器码由 0 和 1 组成的机器语言，这一条条机器码，就是一条条的计算机指令，这个才是 CPU 能够真正认识的东西。
    • 程序编译过程中，编译器分析代码，发现1和2是数据，所以放在内存中的「数据段」，编译器会把a = 1 + 2翻译成4条指令，存放到正文段中。
    • 编译完成后，具体执行程序的时候，程序计数器会被设置为 0x100 地址，然后依次执行这 4 条指令。
  • 上面的例子中，由于是在 32 位 CPU 执行的，因此一条指令是占 32 位大小，所以你会发现每条指令间隔 4 个字节。而数据的大小是根据你在程序中指定的变量类型，比如 int 类型的数据则占 4 个字节，char 类型的数据则占 1 个字节。
  • 你知道软件的 32 位和 64 位之间的区别吗？再来 32 位的操作系统可以运行在 64 位的电脑上吗？64 位的操作系统可以运行在 32 位的电脑上吗？如果不行，原因是什么？
    • 64 位和 32 位软件，实际上代表指令是 64 位还是 32 位的：
      • 如果 32 位指令在 64 位机器上执行，需要一套兼容机制，就可以做到兼容运行了。但是如果 64 位指令在 32 位机器上执行，就比较困难了，因为 32 位的寄存器存不下 64 位的指令；
      • 操作系统其实也是一种程序，我们也会看到操作系统会分成 32 位操作系统、64 位操作系统，其代表意义就是操作系统中程序的指令是多少位，比如 64 位操作系统，指令也就是 64 位，因此不能装在 32 位机器上。

总之，硬件的 64 位和 32 位指的是 CPU 的位宽，软件的 64 位和 32 位指的是指令的位宽。

  • CPU时钟频率：1GHz表示该CPU的时钟频率是1G，表示1秒会发出1G次数的脉冲信号，每一次脉冲信号的高低电平就是一个时钟周期。时钟周期时间越短，CPU运算的越快。

磁盘比内存慢几万倍？

  • 机械硬盘、固态硬盘、内存这三个存储器，到底和 CPU L1 Cache 相比速度差多少倍呢？
    • CPU L1 Cache 随机访问延时是 1 纳秒，内存则是 100 纳秒，所以 CPU L1 Cache 比内存快 100 倍左右。
    • SSD 随机访问延时是 150 微秒，所以 CPU L1 Cache 比 SSD 快 150000 倍左右。
    • 最慢的机械硬盘随机访问延时已经高达 10 毫秒，CPU L1 Cache 比机械硬盘快 10000000 倍左右；
  • 寄存器
    寄存器用来存储计算的数据，是最靠近 CPU 的控制单元和逻辑计算单元的存储器。
    寄存器的价格很贵，数量通常在几十到几百之间，每个寄存器可以用来存储一定的字节（byte）的数据。比如：
    • 32 位 CPU 中大多数寄存器可以存储 4 个字节；
    • 64 位 CPU 中大多数寄存器可以存储 8 个字节。

寄存器的访问速度非常快，一般要求在半个 CPU 时钟周期内完成读写，CPU 时钟周期跟 CPU 主频息息相关，比如 2 GHz 主频的 CPU，那么它的时钟周期就是 1/2G，也就是 0.5ns（纳秒）。

  • CPU Cache
    CPU Cache 用的是一种叫 SRAM（Static Random-Access Memory，静态随机存储器） 的芯片。静态，说明有电时数据一直存在，但掉电数据丢失。
    在 SRAM 里面，一个 bit 的数据，通常需要 6 个晶体管，所以 SRAM 的存储密度不高，同样的物理空间下，能存储的数据是有限的，不过也因为 SRAM 的电路简单，所以访问速度非常快。
    CPU 的高速缓存，通常可以分为 L1、L2、L3 三层高速缓存，也称为一级缓存、二级缓存、三级缓存。
    • L1 高速缓存是每个CPU Core独有的，访问速度快，只需要 2~4 个时钟周期。大小在几十 KB 到几百 KB 不等。
      L1 高速缓存的指令和数据是分开存放的，所以 L1 高速缓存通常分成指令缓存和数据缓存。
    • L2 高速缓存同样每个 CPU 核心都有，但是 L2 比L1 距离 CPU 核心更远，访问速度则更慢，速度在 10~20 个时钟周期。但大小比 L1 更大，通常大小在几百 KB 到几 MB不等，
    • L3 高速缓存通常是多个 CPU 核心共用的，位置比 L2 高速缓存距离 CPU 核心 更远，访问速度相对也比较慢一些，访问速度在 20~60 个时钟周期。大小也会更大些，通常大小在几 MB 到几十 MB 不等。
  • 内存
    内存用的芯片和 CPU Cache 有所不同，它使用的是一种叫作 DRAM （Dynamic Random Access Memory，动态随机存取存储器） 的芯片。动态，因为数据会被存储在电容里，电容会不断漏电，所以需要定时刷新电容，才能保证数据不会被丢失。
    相比 SRAM，DRAM 的密度更高，功耗更低，有更大的容量，而且造价比 SRAM 芯片便宜很多。存储一个 bit 数据，只需要一个晶体管和一个电容就能存储。
    DRAM 的数据访问电路和刷新电路都比 SRAM 更复杂，所以访问的速度会更慢，内存速度大概在 200~300 个 时钟周期之间。
  • SSD/HDD硬盘
    固态硬盘（Solid-state disk，SSD） 结构和内存类似。相比寄存器/Cache/内存的优点是断电后数据还存在；缺点是读写速度很慢。
    机械硬盘（Hard Disk Drive, HDD），通过物理读写的方式来访问数据的，因此它访问速度是非常慢的，它的速度比内存慢 10W 倍左右。由于 SSD 的价格快接近机械硬盘了，因此机械硬盘已经逐渐被 SSD 替代了。
  • 存储器的层次关系
    CPU 并不会直接和每一种存储器设备直接打交道，而是每一种存储器设备只和它相邻的存储器设备打交道。比如，CPU Cache 的数据是从内存加载过来的，写回数据的时候也只写回到内存，再从内存写回到硬盘中。
    • 另外，当 CPU 需要访问内存中某个数据的时候，如果寄存器有这个数据，CPU 就直接从寄存器取数据即可，如果寄存器没有这个数据，CPU 就会查询 L1 高速缓存，如果 L1 没有，则查询 L2 高速缓存，L2 还是没有的话就查询 L3 高速缓存，L3 依然没有的话，才去内存中取数据，并把内存中的数据读入到 Cache 中，CPU 再从 CPU Cache 读取数据。

不同的存储器之间性能差距很大，构造存储器分级很有意义，分级的目的是要构造缓存体系。这样的访问机制，跟我们使用「内存作为硬盘的缓存」的逻辑是一样的。

如何写出让CPU跑的更快的代码？

  • CPU Cache有多快？
    根据摩尔定律，CPU 的访问速度每 18 个月就会翻倍，相当于每年增长 60% 左右，内存的速度当然也会不断增长，但是增长的速度远小于 CPU，平均每年只增长 7% 左右。于是，CPU 与内存的访问性能的差距不断拉大。到现在，一次内存访问所需时间是 200~300 多个时钟周期，这意味着 CPU 和内存的访问速度已经相差 200~300 多倍了。
    为了弥补 CPU 与内存两者之间的性能差异，就在 CPU 内部引入了 CPU Cache，也称高速缓存。
  • CPU Cache 数据结构？
    CPU Cache 是由很多个 Cache Line 组成的，Cache Line （缓存块）是 CPU 从内存读取数据的基本单位。
    Cache Line 结构
    • 有效位（Valid bit）：标记对应Cache Line 中数据是否有效的有效位。
    • 组标记（Tag）：为了区分不同的内存块，在对应的CPU Cache LIne中会存储一个组标记，用来记录当前CPU Cache Line 中存储的数据对应的内存块，区分不同的内存块。
    • 数据（Data）：从内存加载过来的数据。
  • 内存地址与Cache Line的直接映射
    CPU 访问内存数据时，是一小块一小块数据读取的，具体这一小块数据的大小，取决于 coherency_line_size 的值，一般 64 字节。在内存中，这一块的数据我们称为内存块（Block），读取的时候我们要拿到数据所在内存块的地址。
    一个内存的访问地址，包括组标记、CPU Cache Line 索引、偏移量这三种信息，于是 CPU 就能通过这些信息，在 CPU Cache 中找到缓存的数据。
    • 对于直接映射 Cache 采用的策略，就是把内存块的地址始终映射在一个 CPU Cache Line 的地址，至于映射关系实现方式，则是使用取模运算，取模运算的结果就是内存块地址对应的 CPU Cache Line（缓存块） 的地址。
    • 使用偏移量，可以在CPU Cache Line 中的数据块找到对应的字。
  • CPU Cache 读写过程？
    1. 根据内存地址中索引信息，计算在 CPU Cache 中的索引，也就是找出对应的 CPU Cache Line 的地址；
    2. 找到对应 CPU Cache Line 后，判断 CPU Cache Line 中的有效位，确认 CPU Cache Line 中数据是否是有效的，如果是无效的，CPU 就会直接访问内存，并重新加载数据，如果数据有效，则往下执行；
    3. 对比内存地址中组标记和 CPU Cache Line 中的组标记，确认 CPU Cache Line 中的数据是我们要访问的内存数据，如果不是的话，CPU 就会直接访问内存，并重新加载数据，如果是的话，则往下执行；
    4. 根据内存地址中偏移量信息，从 CPU Cache Line 的数据块中，读取对应的字。
    • CPU 在从 CPU Cache 读取数据的时候，并不是读取 CPU Cache Line 中的整个数据块，而是读取 CPU 所需要的一个数据片段，这样的数据统称为一个字（Word）。
  • 写出让CPU跑得更快的程序
    CPU操作L1 Cache的速度是很快的，提升CPU运行速度，可以提升访问L1 Cache的速度。
    那么L1 Cache 通常分为「数据缓存」和「指令缓存」，因此要分别提高「数据缓存」和「指令缓存」的缓存命中率。
    • 提升数据缓存的命中率
      CPU会一次从内存中加载多少元素到 CPU Cache ，可以在Linux 里通过 coherency_line_size 配置查看 它的大小，通常是 64 个字节。
      如果遇到遍历数组之类的情况时，按照内存布局顺序访问，将可以有效的利用 CPU Cache 带来的好处，这样我们代码的性能就会得到很大的提升。
    • 提升指令缓存的命中率
      使用显式分支预测工具，如果分支预测可以预测到接下来要执行 if 里的指令，还是 else 指令的话，就可以「提前」把这些指令放在指令缓存中，这样 CPU 可以直接从 Cache 读取到指令，于是执行速度就会很快。
      • 比如：如果你肯定代码中的 if 中的表达式判断为 true 的概率比较高，我们可以使用显示分支预测工具，比如在 C/C++ 语言中，如果 if 条件为 ture 的概率大，则可以用 likely 宏把 if 里的表达式包裹起来。

还可以提升多核CPU的缓存命中率

  • L2 Cache和L1 Cache 是每个核心独有的，如果一个线程在不同核心来回切换，各个核心的缓存命中率就会受到影响，可以把线程绑定到某一个CPU核心上。
    在 Linux 上提供了 sched_setaffinity 方法，来实现将线程绑定到某个 CPU 核心这一功能。

CPU 缓存一致性

事实上，数据不光是只读操作，还有写回操作。当数据写入Cache， 内存与Cache中的数据将会不同，这种情况下Cache和内存数据都不一致，所以要把Cache 中的数据同步到内存里。
针对写入数据的方法有两种：

  • 写直达（Write Through）
    将数据同时写入Cache和内存中。写入之前，会先判断数据是否存在Cache中，如果数据没有在Cache中，则直接写到内存，否则先更新Cache中的数据，之后再写入到内存中。
    写直达中，CPU每次执行写操作都会将数据写回到内存，影响性能，于是出现了写回操作。
  • 写回（Write Back）
    写回机制中，当发生写操作时，新的数据仅仅被写入Cache Block 中，并且Cache Block被标记为脏，只有脏的Cache Block被替换时，才需要将新的数据写入到内存中。具体执行过程如下：
    • 当发生写操作时，如果缓存命中，则把数据更新到CPU Cache中，并且标记CPU Cache中的Cache Block为脏。
      • 设置为脏，代表 Cache Block 的数据和内存不一致，但是不把数据写入到内存。
    • 如果缓存未命中，要先检查Cache Block 中的数据有没有被标记为脏的：
      • 如果是脏数据，则先把Cache Block 中的数据写回到内存，然后从内存读取要写入的整个块（32字节）到Cache Block中，再把当前数据写入到Cache Block，标记为脏。
        • 因为此时是要判断数据即将写入到 cache block 里的位置，是否被「其他数据」占用了此位置，如果这个「其他数据」是脏数据，那么就要帮忙把它写回到内存。
      • 如果不是脏数据，则从内存读取整个块（32字节）到Cache Block中，接着将数据写入到Cache Block中，并标记为脏。

如果我们大量的操作都可以命中缓存，那么就不需要多次去从内存中读写数据，从而浪费时间。

  • 缓存一致性问题：由于L1/L2 Cache是多个核心独有的，写回策略并没有同步数据到内存，所以多核心会产生缓存一致性问题。
  • 解决缓存不一致的问题
    • 某个 CPU 核心里的 Cache 数据更新时，必须要传播到其他核心的 Cache，这个称为写传播（Write Propagation）；
      • 写传播的原则就是当某个 CPU 核心更新了 Cache 中的数据，要把该事件广播通知到其他核心。
        最常见实现的方式是总线嗅探（Bus Snooping）。也就是CPU时刻监听总线上的一切活动，不管别的核心的Cache是否缓存了相同的数据，但是会加重总线的负载。
    • 某个 CPU 核心里对数据的操作顺序，必须在其他核心看起来顺序是一样的，这个称为事务的串行化（Transaction Serialization）。
      • 总线嗅探不能保证事务的串行化，使用MESI协议，基于总线嗅探机制实现了事务串行化，CPU缓存一致性。
  • MESI协议
    • Modified，已修改
      • 已修改状态就是脏标记，代表该 Cache Block 上的数据已经被更新过，但是还没有写到内存里。
    • Exclusive，独占
    • Shared，共享
    • Invalidated，已失效
      • 已失效状态表示的是这个 Cache Block 里的数据已经失效了，不可以读取该状态的数据。

这四个状态来标记 Cache Line 四个不同的状态。

  • 「独占」和「共享」状态都代表 Cache Block 里的数据是干净的，也就是说，这个时候 Cache Block 里的数据和内存里面的数据是一致性的。
  • 「独占」和「共享」的差别在于，独占状态的时候，数据只存储在一个 CPU 核心的 Cache 里，而其他 CPU 核心的 Cache 没有该数据。这个时候，如果要向独占的 Cache 写数据，就可以直接自由地写入，而不需要通知其他 CPU 核心，因为只有你这有这个数据，就不存在缓存一致性的问题了，于是就可以随便操作该数据。
  • 另外，在「独占」状态下的数据，如果有其他核心从内存读取了相同的数据到各自的 Cache ，那么这个时候，独占状态下的数据就会变成共享状态。
  • 那么，「共享」状态代表着相同的数据在多个 CPU 核心的 Cache 里都有，所以当我们要更新 Cache 里面的数据的时候，不能直接修改，而是要先向所有的其他 CPU 核心广播一个请求，要求先把其他核心的 Cache 中对应的 Cache Line 标记为「无效」状态，然后再更新当前 Cache 里面的数据。
  • MESI 协议，是已修改、独占、共享、已失效这四个状态的英文缩写的组合。整个 MESI 状态的变更，**则是根据来自本地 CPU 核心的请求，或者来自其他 CPU 核心通过总线传输过来的请求，从而构成一个流动的状态机。**另外，对于在「已修改」或者「独占」状态的 Cache Line，修改更新其数据不需要发送广播给其他 CPU 核心，这在一定程度上减少了总线带宽压力。
  • 举例理解四个状态的流转：
    1. 当 A 号 CPU 核心从内存读取变量 i 的值，数据被缓存在 A 号 CPU 核心自己的 Cache 里面，此时其他 CPU 核心的 Cache 没有缓存该数据，于是标记 Cache Line 状态为「独占」，此时其 Cache 中的数据与内存是一致的；
    2. 然后 B 号 CPU 核心也从内存读取了变量 i 的值，此时会发送消息给其他 CPU 核心，由于 A 号 CPU 核心已经缓存了该数据，所以会把数据返回给 B 号 CPU 核心。在这个时候， A 和 B 核心缓存了相同的数据，Cache Line 的状态就会变成「共享」，并且其 Cache 中的数据与内存也是一致的；
    3. 当 A 号 CPU 核心要修改 Cache 中 i 变量的值，发现数据对应的 Cache Line 的状态是共享状态，则要向所有的其他 CPU 核心广播一个请求，要求先把其他核心的 Cache 中对应的 Cache Line 标记为「无效」状态，然后 A 号 CPU 核心才更新 Cache 里面的数据，同时标记 Cache Line 为「已修改」状态，此时 Cache 中的数据就与内存不一致了。
    4. 如果 A 号 CPU 核心「继续」修改 Cache 中 i 变量的值，由于此时的 Cache Line 是「已修改」状态，因此不需要给其他 CPU 核心发送消息，直接更新数据即可。
    5. 如果 A 号 CPU 核心的 Cache 里的 i 变量对应的 Cache Line 要被「替换」，发现 Cache Line 状态是「已修改」状态，就会在替换前先把数据同步到内存。

CPU是如何执行任务的？

  1. CPU 内部的多个 Cache + 外部的内存和磁盘都就构成了金字塔的存储器结构，在这个金字塔中，越往下，存储器的容量就越大，但访问速度就会小。
  2. CPU 读写数据的时候，并不是按一个一个字节为单位来进行读写，而是以 CPU Cache Line 大小为单位，CPU Cache Line 大小一般是 64 个字节，也就意味着 CPU 读写数据的时候，每一次都是以 64 字节大小为一块进行操作。
  3. 因此，如果我们操作的数据是数组，那么访问数组元素的时候，按内存分布的地址顺序进行访问，这样能充分利用到 Cache，程序的性能得到提升。但如果操作的数据不是数组，而是普通的变量，并在多核 CPU 的情况下，我们还需要避免 Cache Line 伪共享的问题。
  4. 所谓的 Cache Line 伪共享问题就是，多个线程同时读写同一个 Cache Line 的不同变量时，而导致 CPU Cache 失效的现象。那么对于多个线程共享的热点数据，即经常会修改的数据，应该避免这些数据刚好在同一个 Cache Line 中，避免的方式一般有 Cache Line 大小字节对齐，以及字节填充等方法。
  • Cache 伪共享
    多个线程同时读写同一个 Cache Line 的不同变量时，而导致 CPU Cache 失效的现象称为伪共享（False Sharing）。
    • 两个线程共享同一Cache Line的数据，由于MESI协议，当A线程在Cache Line修改变量A时，B线程中的Cache Line就是失效状态。此时线程B修改变量B，A线程变为了失效状态。
  • 避免伪共享
    • 在 Linux 内核中存在 __cacheline_aligned_in_smp 宏定义，是用于解决伪共享的问题。可以将变量的内存地址设置为Cache Line对齐地址，这样两个变量就不在同一个Cache Line中了。所以，避免 Cache 伪共享实际上是用空间换时间的思想，浪费一部分 Cache 空间，从而换来性能的提升。
  2. 应用层面也存在规避方案：有一个 Java 并发框架 Disruptor 使用「字节填充 + 继承」的方式，来避免伪共享的问题。Disruptor 中有一个 RingBuffer 类会经常被多个线程使用。-  CPU Cache 从内存读取数据的单位是 CPU Cache Line，一般 64 位 CPU 的Cache Line 的大小是 64 个字节，一个 long 类型的数据是 8 个字节，所以 CPU 一下会加载 8 个 long 类型的数据。 -  RingBufferPad 中的 7 个 long 类型数据作为 Cache Line **前置填充**，而 RingBuffer 中的 7 个 long 类型数据则作为 Cache Line **后置填充**，这 14 个 long 变量没有任何实际用途，更不会对它们进行读写操作。 -  另外，RingBufferFelds 里面定义的这些变量都是 `final` 修饰的，意味着第一次加载之后不会再修改， 又**由于「前后」各填充了 7 个不会被读写的 long 类型变量，所以无论怎么加载 Cache Line，这整个 Cache Line 里都没有会发生更新操作的数据，于是只要数据被频繁地读取访问，就自然没有数据被换出 Cache 的可能，也因此不会产生伪共享的问题**。
  • CPU如何选择线程？
    • 在 Linux 内核中，进程和线程都是用 task_struct 结构体表示的，区别在于线程的 task_struct 结构体里部分资源是共享了进程已创建的资源，比如内存地址空间、代码段、文件描述符等，所以 Linux 中的线程也被称为轻量级进程，因为线程的 task_struct 相比进程的 task_struct 承载的 资源比较少，因此以「轻」得名。
    • 一般来说，没有创建线程的进程，是只有单个执行流，它被称为是主线程。如果想让进程处理更多的事情，可以创建多个线程分别去处理，但不管怎么样，它们对应到内核里都是 task_struct。所以，Linux 内核里的调度器，调度的对象就是 task_struct，接下来我们就把这个数据结构统称为任务。
    • 在 Linux 系统中，根据任务的优先级以及响应要求，主要分为两种，其中优先级的数值越小，优先级越高：
      • 实时任务，对系统的响应时间要求很高，也就是要尽可能快的执行实时任务，优先级在 0~99 范围内的就算实时任务；
      • 普通任务，响应时间没有很高的要求，优先级在 100~139 范围内都是普通任务级别
        • 对于普通任务来说，公平性最重要，在 Linux 里面，实现了一个基于 CFS 的调度算法，也就是完全公平调度（Completely Fair Scheduling）。
  • 完全公平调度
    • 这个算法的理念是想让分配给每个任务的 CPU 时间是一样，于是它为每个任务安排一个虚拟运行时间 vruntime，如果一个任务在运行，其运行的越久，该任务的 vruntime 自然就会越大，而没有被运行的任务，vruntime 是不会变化的。那么，在 CFS 算法调度的时候，会优先选择 vruntime 少的任务，以保证每个任务的公平性。
  • 系统中需要运行的多线程数一般都会大于 CPU 核心，这样就会导致线程排队等待 CPU，这可能会产生一定的延时，如果我们的任务对延时容忍度很低，则可以通过一些人为手段干预 Linux 的默认调度策略和优先级。

什么是软中断？

在计算机中，中断是系统用来响应硬件设备请求的一种机制，操作系统收到硬件的中断请求，会打断正在执行的进程，然后调用内核中的中断处理程序来响应请求。
操作系统收到了中断请求，会打断其他进程的运行，所以中断请求的响应程序，也就是中断处理程序，要尽可能快的执行完，这样可以减少对正常进程运行调度地影响。
而且，中断处理程序在响应中断时，可能还会「临时关闭中断」，这意味着，如果当前中断处理程序没有执行完之前，系统中其他的中断请求都无法被响应，也就说中断有可能会丢失，所以中断处理程序要短且快。
那 Linux 系统为了解决中断处理程序执行过长和中断丢失的问题，将中断过程分成了两个阶段，分别是「上半部和下半部分」。

  • 上半部用来快速处理中断，也就是硬中断，一般会暂时关闭中断请求，主要负责处理跟硬件紧密相关或者时间敏感的事情。
    • 比如先禁止网卡中断，避免频繁硬中断，而降低内核的工作效率
  • 下半部用来延迟处理上半部未完成的工作，也就是软中断，一般以「内核线程」的方式运行。
    • 比如需要从内存中找到网络数据，再按照网络协议栈，对网络数据进行逐层解析和处理，最后把数据送给应用程序。

Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型，可以通过查看 /proc/softirqs 来观察软中断的累计中断次数情况，如果要实时查看中断次数的变化率，可以使用 watch -d cat /proc/softirqs 命令。
每一个 CPU 都有各自的软中断内核线程，我们还可以用 ps 命令来查看内核线程，一般名字在中括号里面的，都认为是内核线程。
如果在 top 命令发现，CPU 在软中断上的使用率比较高，而且 CPU 使用率最高的进程也是软中断 ksoftirqd 的时候，这种一般可以认为系统的开销被软中断占据了。
这时我们就可以分析是哪种软中断类型导致的，一般来说都是因为网络接收软中断导致的，如果是的话，可以用 sar 命令查看是哪个网卡的有大量的网络包接收，再用 tcpdump 抓网络包，做进一步分析该网络包的源头是不是非法地址，如果是就需要考虑防火墙增加规则，如果不是，则考虑硬件升级等。

操作系统结构

Linux内核 vs Windows内核

什么是内核？

  • 计算机使用内核作为应用连接硬件设备的桥梁，应用程序只需关心与内核交互，不用关心硬件的细节。

内核的能力：

  • 管理进程、线程，决定哪个进程、线程使用 CPU，也就是进程调度的能力；
  • 管理内存，决定内存的分配和回收，也就是内存管理的能力；
  • 管理硬件设备，为进程与硬件设备之间提供通信能力，也就是硬件通信能力；
  • 提供系统调用，如果应用程序要运行更高权限运行的服务，那么就需要有系统调用，它是用户程序与操作系统之间的接口。

内核具有很高的权限，可以控制 cpu、内存、硬盘等硬件，而应用程序具有的权限很小，因此大多数操作系统，把内存分成了两个区域：

  • 内核空间，这个内存空间只有内核程序可以访问；
  • 用户空间，这个内存空间专门给应用程序使用；
  • 用户空间的代码只能访问一个局部的内存空间，而内核空间的代码可以访问所有内存空间。因此，当程序使用用户空间时，我们常说该程序在用户态执行，而当程序使内核空间时，程序则在内核态执行。
  • 内核程序执行在内核态，用户程序执行在用户态。当应用程序使用系统调用时，会产生一个中断。发生中断后， CPU 会中断当前在执行的用户程序，转而跳转到中断处理程序，也就是开始执行内核程序。内核处理完后，主动触发中断，把 CPU 执行权限交回给用户程序，回到用户态继续工作。

Linux的设计
Linux 内核设计的理念主要有这几个点：

  • MultiTask，多任务
    多任务意味着可以有多个任务同时执行，这里的「同时」可以是并发或并行：
    • 对于单核 CPU 时，可以让每个任务执行一小段时间，时间到就切换另外一个任务，从宏观角度看，一段时间内执行了多个任务，这被称为并发。
    • 对于多核 CPU 时，多个任务可以同时被不同核心的 CPU 同时执行，这被称为并行。
  • SMP，对称多处理
    SMP 的意思是对称多处理，代表着每个 CPU 的地位是相等的，对资源的使用权限也是相同的，多个 CPU 共享同一个内存，每个 CPU 都可以访问完整的内存和硬件资源。
    这个特点决定了 Linux 操作系统不会有某个 CPU 单独服务应用程序或内核程序，而是每个程序都可以被分配到任意一个 CPU 上被执行。
  • ELF，可执行文件链接格式
    ELF 的意思是可执行文件链接格式，它是 Linux 操作系统中可执行文件的存储格式。执行 ELF 文件的时候，会通过「装载器」把 ELF 文件装载到内存里，CPU 读取内存中的指令和数据，于是程序就被执行起来了。
  • Monolithic Kernel，宏内核
    Monolithic Kernel 的意思是宏内核，Linux 内核架构就是宏内核，意味着 Linux 的内核是一个完整的可执行程序，且拥有最高的权限。
    宏内核的特征是系统内核的所有模块，比如进程调度、内存管理、文件系统、设备驱动等，都运行在内核态。
    不过，Linux 也实现了动态加载内核模块的功能，例如大部分设备驱动是以可加载模块的形式存在的，与内核其他模块解藕，让驱动开发和驱动加载更为方便、灵活。

Windows设计

  • 当今 Windows 7、Windows 10、11 使用的内核叫 Windows NT，NT 全称叫 New Technology。
  • Windows 和 Linux 一样，同样支持 MultiTask 和 SMP，但不同的是，Window 的内核设计是混合型内核，内核中有一个 MicroKernel 模块，这个就是最小版本的内核，而整个内核实现是一个完整的程序，含有非常多模块。
  • 混合型内核：内核里面会有一个最小版本的内核，然后其他模块会在这个基础上搭建，然后实现的时候会跟宏内核类似，也就是把整个内核做成一个完整的程序，大部分服务都在内核中，这就像是宏内核的方式包裹着一个微内核。
  • Windows 的可执行文件格式叫 PE，称为可移植执行文件，扩展名通常是.exe、.dll、.sys等。

内存管理

为什么要有虚拟内存？

单片机的 CPU 是直接操作内存的「物理地址」。单片机中只能跑一个程序。
如果我们想要同时在内存中运行多个程序，就需要把进程所使用的地址隔离，所以使用了虚拟内存。简单来说，虚拟内存地址是程序使用的内存地址。物理内存地址是实际存在硬件里面的地址。
操作系统为每个进程都分配了一套虚拟内存地址，进程持有的虚拟地址会通过 CPU 芯片中内存管理单元（MMU）的映射关系，来转换变成物理地址，然后再通过物理地址访问内存。
虚拟内存的作用？

  • 扩展可用内存空间。虚拟内存使得程序能够使用比实际物理内存更大的内存空间。当物理内存不足时，操作系统将不常用的数据从内存中转移到磁盘中，从而腾出空间供活动进程使用。
  • 解决多地址冲突问题。由于每个进程都有自己的页表，所以每个进程的虚拟内存空间就是相互独立的。进程也没有办法访问其他进程的页表，所以这些页表是私有的，这就解决了多进程之间地址冲突的问题。
  • 简化内存管理。由于虚拟内存将物理内存的使用方式与程序中的虚拟地址分离开来，使得程序在执行时不必关心物理内存的使用情况，简化了内存管理。
  • 页表里的页表项中除了物理地址之外，还有一些标记属性的比特，比如控制一个页的读写权限，标记该页是否存在等。在内存访问方面，操作系统提供了更好的安全性。

操作系统使用内存分段和内存分页的方式管理虚拟地址与物理地址之间的关系。
内存分段 ：程序是由若干个逻辑分段组成的，如可由代码分段、数据分段、栈段、堆段组成。不同的段是有不同的属性的，所以就用分段（Segmentation）的形式把这些段分离出来。

  • 分段机制下的虚拟地址由段选择因子和段内偏移量两部分组成
    • 段选择因子保存在段寄存器内。段选择子里面最重要的是段号，用作段表的索引。段表里面保存的是这个段的基地址、段的界限和特权等级等。
    • 段内偏移量位于 0 和段界限之间，如果段内偏移量是合法的，就将段基地址加上段内偏移量得到物理内存地址。
  • 虚拟地址是通过段表与物理地址进行映射的。
    • 分段机制会把程序的虚拟地址分成多个段，每个段在段表中有一个项，在这一项找到段的基地址，再加上偏移量，于是就能找到物理内存中的地址。
  • 分段也存在不足之处，存在内存碎片问题和内存交换的效率低的问题。
    • 内存碎片主要分为内部内存碎片和外部内存碎片。内存分段管理可以做到1段根据实际需求分配内存，有多少需求就分配多大的段，所以不会出现内部内存碎片。但是由于每个段的长度不固定，所以多个段未必能恰好使用所有的内存空间，会产生了多个不连续的小物理内存，导致新的程序无法被装载，所以会出现外部内存碎片的问题。
      • 解决「外部内存碎片」的问题就是内存交换。可以将音乐程序占用的那 256MB 内存写到硬盘上，然后再从硬盘上读回来到内存里。不过再读回的时候，我们不能装载回原来的位置，而是紧紧跟着那已经被占用了的 512MB 内存后面。这样就能空缺出连续的 256MB 空间，于是新的 200MB 程序就可以装载进来。
  • 为什么分段会导致内存交换效率低？
    • 产生了外部内存碎片，那就不得不重新 Swap 内存区域，这个过程会产生性能瓶颈。因为硬盘的访问速度要比内存慢太多了，每一次内存交换，我们都需要把一大段连续的内存数据写到硬盘上。
    • 所以，**如果内存交换的时候，交换的是一个占内存空间很大的程序，这样整个机器都会显得卡顿。**为了解决内存分段的「外部内存碎片和内存交换效率低」的问题，就出现了内存分页。

当需要进行内存交换的时候，让需要交换写入或者从磁盘装载的数据更少一点，这样就可以解决问题了。这个办法，也就是内存分页（Paging）。分页是把整个虚拟和物理内存空间切成一段段固定尺寸的大小。这样一个连续并且尺寸固定的内存空间，我们叫页（Page）。
内存分页中，虚拟地址与物理地址之间通过页表来映射。页表是存储在内存里的，内存管理单元 （MMU）就做将虚拟内存地址转换成物理地址的工作。当进程访问的虚拟地址在页表中查不到时，系统会产生一个缺页异常，进入系统内核空间分配物理内存、更新进程页表，最后再返回用户空间，恢复进程的运行。
分页是怎么解决分段【外部内存碎片和内存交换效率低】的问题？

  • 内存分页由于内存空间都是预先划分好的，也就不会像内存分段一样，在段与段之间会产生间隙非常小的内存，这正是分段会产生外部内存碎片的原因。而采用了分页，页与页之间是紧密排列的，所以不会有外部碎片。
    • 但是，因为内存分页机制分配内存的最小单位是一页，即使程序不足一页大小，我们最少只能分配一个页，所以页内会出现内存浪费，所以针对内存分页机制会有内部内存碎片的现象。
  • 如果内存空间不够，触发swap机制，一次性写入磁盘的也只有少数的一个页或者几个页，不会花太多时间，内存交换的效率就相对比较高。
  • 在加载程序时，不再需要一次性都把程序加载到物理内存中。我们完全可以在进行虚拟内存和物理内存的页之间的映射之后，并不真的把页加载到物理内存里，而是只有在程序运行中，需要用到对应虚拟内存页里面的指令和数据时，再加载到物理内存里面去。

分页机制下，虚拟地址和物理地址是如何映射的？

  • 在分页机制下，虚拟地址分为两部分，页号和页内偏移。页号作为页表的索引，基地址（页表中）与页内偏移的组合就形成了物理内存地址。
  • 对于虚拟地址和物理地址相互转换，就三个步骤：
    • 虚拟内存分为页号和页内偏移量。
    • 根据页号，从页表里面，查询对应的物理页号。
    • 直接拿物理页号，加上前面的偏移量，就得到了物理内存地址。

单页表的实现方式，在 32 位和页大小 4KB 的环境下，一个进程的页表需要装下 100 多万个「页表项」，并且每个页表项是占用 4 字节大小的，于是相当于每个页表需占用 4MB 大小的空间。存在空间上的缺陷。
我们把这个 100 多万个「页表项」的单级页表再分页，将页表（一级页表）分为 1024 个页表（二级页表），每个表（二级页表）中包含 1024 个「页表项」，形成二级分页。
为什么多级页表比单页表省空间？

  • 使用二级分页，如果某个一级页表的页表项没有被用到，也就不需要创建这个页表项对应的二级页表了，即可以在需要时才创建二级页表。
    从页表的性质来看，保存在内存中的页表承担的职责是将虚拟地址翻译成物理地址。假如虚拟地址在页表中找不到对应的页表项，计算机系统就不能工作了。所以页表一定要覆盖全部虚拟地址空间，不分级的页表就需要有 100 多万个页表项来映射，而二级分页则只需要 1024 个页表项。
  • 我们把二级分页再推广到多级页表，就会发现页表占用的内存空间更少了，这一切都要归功于对局部性原理的充分应用。

对于 64 位的系统，两级分页肯定不够了，就变成了四级目录。

TLB
多级页表虽然解决了空间上的问题，但是虚拟地址到物理地址的转换就多了几道转换的工序，这显然就降低了这俩地址转换的速度，也就是带来了时间上的开销。
程序是有局部性的，即在一段时间内，整个程序的执行仅限于程序中的某一部分。相应地，执行所访问的存储空间也局限于某个内存区域。我们就可以利用这一特性，把最常访问的几个页表项存储到访问速度更快的硬件，于是计算机科学家们，就在 CPU 芯片中，加入了一个专门存放程序最常访问的页表项的 Cache，这个 Cache 就是 TLB（Translation Lookaside Buffer） ，通常称为页表缓存、转址旁路缓存、快表等。

  • 在 CPU 芯片里面，封装了内存管理单元（Memory Management Unit）芯片，它用来完成地址转换和 TLB 的访问与交互。有了 TLB 后，那么 CPU 在寻址时，会先查 TLB，如果没找到，才会继续查常规的页表。TLB 的命中率其实是很高的，因为程序最常访问的页就那么几个。

内存分段和内存分页并不是对立的，它们是可以组合起来在同一个系统中使用的，那么组合起来后，通常称为段页式内存管理。
段页式内存管理实现的方式：

  • 先将程序划分为多个有逻辑意义的段，也就是前面提到的分段机制；
  • 接着再把每个段划分为多个页，也就是对分段划分出来的连续空间，再划分固定大小的页；

虚拟内存地址结构由段号、段内页号和页内位移三部分组成。
用于段页式地址变换的数据结构是每一个程序一张段表，每个段又建立一张页表，段表中的地址是页表的起始地址，而页表中的地址则为某页的物理页号。
段页式地址变换中要得到物理地址须经过三次内存访问：

  • 第一次访问段表，得到页表起始地址；
  • 第二次访问页表，得到物理页号；
  • 第三次将物理页号与页内位移组合，得到物理地址。

Linux系统
页式内存管理的作用是在由段式内存管理所映射而成的地址上再加上一层地址映射。
逻辑地址和线性地址：

  • 程序所使用的地址，通常是没被段式内存管理映射的地址，称为逻辑地址；
  • 通过段式内存管理映射的地址，称为线性地址，也叫虚拟地址；

逻辑地址是「段式内存管理」转换前的地址，线性地址则是「页式内存管理」转换前的地址。
Linux 内存主要采用的是页式内存管理，但同时也不可避免地涉及了段机制。
Linux 系统中的每个段都是从 0 地址开始的整个 4GB 虚拟空间（32 位环境下），也就是所有的段的起始地址都是一样的。这意味着，Linux 系统中的代码，包括操作系统本身的代码和应用程序代码，所面对的地址空间都是线性地址空间（虚拟地址），这种做法相当于屏蔽了处理器中的逻辑地址概念，段只被用于访问控制和内存保护。

malloc是如何分配内存的？

在 Linux 操作系统中，虚拟地址空间的内部又被分为内核空间和用户空间两部分，不同位数的系统，地址空间的范围也不同。比如最常见的 32 位和 64 位系统：

  • 32位系统最大只能申请4G的内存空间，其中内核空间1G、用户空间3G。
  • 64位系统可以分配的空间更多，其中内核空间128T、用户空间128T。

内核空间与用户空间的区别：

  • 进程在用户态时，只能访问用户空间内存；而只有进入内核态后，才可以访问内核空间的内存；

虽然每个进程都各自有独立的虚拟内存，但是每个虚拟内存中的内核地址，其实关联的都是相同的物理内存。这样，进程切换到内核态后，就可以很方便地访问内核空间内存。

用户空间内存从低到高分别是 6 种不同的内存段：

  • 代码段，包括二进制可执行代码；
  • 数据段，包括已初始化的静态常量和全局变量；
  • BSS 段，包括未初始化的静态变量和全局变量；
  • 堆段，包括动态分配的内存，从低地址开始向上增长；
  • 文件映射段，包括动态库、共享内存等，从低地址开始向上增长。
  • 栈段，包括局部变量和函数调用的上下文等。栈的大小是固定的，一般是 8 MB。当然系统也提供了参数，以便我们自定义大小；

在这 6 个内存段中，堆和文件映射段的内存是动态分配的。比如说，使用 C 标准库的 malloc() 或者 mmap() ，就可以分别在堆和文件映射段动态分配内存。

  • malloc是如何分配内存的？
    malloc 申请内存的时候，会有两种方式向操作系统申请堆内存。
    • 方式一：通过 brk() 系统调用从堆分配内存（break）
      • 该方式实现方式简单，就是通过 brk() 函数将「堆顶」指针向高地址移动，获得新的内存空间。
      • 方式二：通过 mmap() 系统调用在文件映射区域分配内存（memory map：内存映射）
        • 通过调用【私有匿名映射】的方式，在文件映射区分配一块内存。
  • 什么场景下 malloc() 会通过 brk() 分配内存？又是什么场景下通过 mmap() 分配内存？
    malloc() 源码里默认定义了一个阈值：如果用户分配的内存小于 128 KB，则通过 brk() 申请内存；如果用户分配的内存大于 128 KB，则通过 mmap() 申请内存；不同glibc版本不同阈值不同。
    • glibc是LInux最底层的api，几乎其他任何运行库都会依赖于glibc。
  • malloc()分配的是物理内存吗？
    malloc()分配的是虚拟内存。如果分配后的虚拟内存没有被访问，虚拟内存不会映射到物理内存（发生缺页），这样就不会占用物理内存了。
    如果程序访问了未被分配的虚拟页，就会触发缺页中断，通过缺页中断函数，操作系统会建立虚拟内存和物理内存之间的映射关系。
  • malloc(1)会分配多大的虚拟内存？
    在使用C语言中的标准库函数malloc进行内存分配时，传入的参数表示要分配的内存块大小，但是实际上malloc函数可能会分配比请求更大的内存空间。
    这是因为malloc在为内存块分配空间时，需要在其前面存储一些额外的信息，例如内存块的大小、是否被占用等信息，这些信息通常被存储在分配的内存块的前几个字节中。因此，即使请求分配的内存块大小为1字节，malloc可能会分配更大的虚拟内存空间来存储这些额外的信息。
    具体而言，每个malloc实现都可能有不同的实现方式和策略，因此无法确定分配的虚拟内存空间的确切大小。在一些实现中，分配的内存大小可能会被调整为对齐到特定的边界值，以提高内存访问的效率。在其他实现中，可能会使用更多的额外信息来记录内存块的其他元数据。
    因此，调用malloc(1)分配虚拟内存空间时，实际分配的大小可能会大于1字节，具体取决于实现方式和策略。
  • free释放内存，会归还给操作系统吗？
    针对 malloc 通过 brk() 方式申请的内存的情况，通过 free 释放内存后，堆内存还是存在的，并没有归还给操作系统，而是缓存着放进 malloc 的内存池里。
    • 等下次在申请内存的时候，就直接从内存池取出对应的内存块就行了，而且可能这个内存块的虚拟地址与物理地址的映射关系还存在，这样不仅减少了系统调用的次数，也减少了缺页中断的次数，这将大大降低 CPU 的消耗。

如果 malloc 通过 mmap 方式申请的内存，free 释放内存后就会归还给操作系统，内存得到真正释放。

  • 为什么不全部使用mmap来分配内存？
    频繁通过 mmap 分配内存，不仅每次都会发生运行态的切换，还会发生缺页中断（在第一次访问虚拟地址后），这样会导致 CPU 消耗较大。
    为了改进这两个问题，malloc 通过 brk() 系统调用在堆空间申请内存的时候，由于堆空间是连续的，所以直接预分配更大的内存来作为内存池，当内存释放的时候，就缓存在内存池中。
  • 为什么不全部使用brk来分配内存？
    如果我们连续申请了 10k，20k，30k 这三片内存，如果 10k 和 20k 这两片释放了，变为了空闲内存空间，但是如果下次申请的内存大于 30k，没有可用的空闲内存空间，必须向 OS 申请，实际使用内存继续增大。随着系统频繁地 malloc 和 free ，尤其对于小块内存，堆内将产生越来越多不可用的碎片，导致“ 内存泄露 ”（内存空间无法被再利用）。
    所以，malloc 实现中，充分考虑了 brk 和 mmap 行为上的差异及优缺点，默认分配大块内存 (128KB) 才使用 mmap 分配内存空间。
  • free()函数只传入一个内存地址，为什么能知道要释放多大的内存？
    当执行 free() 函数时，free 会对传入进来的内存地址向左偏移 16 字节（保存内存块的信息，比如大小），然后从这个 16 字节的分析出当前的内存块的大小，自然就知道要释放多大的内存了。

内存满了，会发生什么？

CPU 访问虚拟内存时， 如果发现这个虚拟内存没有映射到物理内存， CPU 就会产生缺页中断，进程会从用户态切换到内核态，并将缺页中断交给内核的 Page Fault Handler （缺页中断函数）处理。

  • 缺页中断处理函数会看是否有空闲的物理内存，如果有，就直接分配物理内存，并建立虚拟内存与物理内存之间的映射关系（将虚拟页加载到物理页上，之后更新页表）。
  • 如果没有空闲的物理内存，那么内核就会开始进行回收内存的工作，回收的方式主要是两种：直接内存回收和后台内存回收。
    • 后台内存回收（kswapd）：在物理内存紧张的时候，会唤醒 kswapd 内核线程来回收内存，这个回收内存的过程异步的，不会阻塞进程的执行。
    • 直接内存回收（direct reclaim）：如果后台异步回收跟不上进程内存申请的速度，就会开始直接回收，这个回收内存的过程是同步的，会阻塞进程的执行。

如果直接内存回收后，空闲的物理内存仍然无法满足此次物理内存的申请，那么内核就会放最后的大招了 ——触发 OOM （Out of Memory）机制。

OOM Killer 机制会根据算法选择一个占用物理内存较高的进程，然后将其杀死，以便释放内存资源，如果物理内存依然不足，OOM Killer 会继续杀死占用物理内存较高的进程，直到释放足够的内存位置。

  • 哪些内存可以被回收？
    • 主要有两类内存可以被回收，而且它们的回收方式也不同。
      • 文件页（File-backed Page）：内核缓存的磁盘数据（Buffer）和内核缓存的文件数据（Cache）都叫作文件页。回收干净页的方式是直接释放内存，回收脏页的方式是先写回磁盘后再释放内存。
      • 匿名页（Anonymous Page）：这部分内存没有实际载体，不像文件缓存有硬盘文件这样一个载体，比如堆、栈数据等。这部分内存很可能还要再次被访问，所以不能直接释放内存，它们回收的方式是通过 Linux 的 Swap 机制，Swap 会把不常访问的内存先写到磁盘中，然后释放这些内存，给其他更需要的进程使用。再次访问这些内存时，重新从磁盘读入内存就可以了。

文件页和匿名页的回收都是基于 LRU 算法，也就是优先回收不常访问的内存。LRU 回收算法，实际上维护着 active 和 inactive 两个双向链表，其中：

  • active_list 活跃内存页链表，这里存放的是最近被访问过（活跃）的内存页；
  • inactive_list 不活跃内存页链表，这里存放的是很少被访问（非活跃）的内存页；
  • 回收内存带来的性能影响
    • 回收内存的操作基本都会发生磁盘 I/O 的，如果回收内存的操作很频繁，意味着磁盘 I/O 次数会很多，会影响操作系统性能。
  • 针对回收内存导致的性能影响，常见的解决方式。
    • 设置 /proc/sys/vm/swappiness，调整文件页和匿名页的回收倾向，尽量倾向于回收文件页；
      • swappiness 的范围是 0-100，数值越大，越积极使用 Swap，也就是更倾向于回收匿名页；数值越小，越消极使用 Swap，也就是更倾向于回收文件页。一般建议 swappiness 设置为 0（默认值是 60），这样在回收内存的时候，会更倾向于文件页的回收，但是并不代表不会回收匿名页。
    • 设置 /proc/sys/vm/min_free_kbytes，调整 kswapd 内核线程异步回收内存的时机；
    • 设置 /proc/sys/vm/zone_reclaim_mode，调整 NUMA 架构下内存回收策略，建议设置为 0，这样在回收本地内存之前，会在其他 Node 寻找空闲内存，从而避免在系统还有很多空闲内存的情况下，因本地 Node 的本地内存不足，发生频繁直接内存回收导致性能下降的问题；
  • 尽早触发kswapd内核线程异步回收内存
    • 内核定义了三个内存阈值（watermark，也称为水位），用来衡量当前剩余内存（pages_free）是否充裕或者紧张，分别是：
      • 页高阈值（pages_high）；
        • 说明内存有一定压力，但还可以满足应用程序申请内存的请求；在这个区间说明内存充足；
      • 页低阈值（pages_low）；
        • 如果剩余内存（pages_free）在页低阈值（pages_low）和页最小阈值（pages_min）之间，说明内存压力比较大，剩余内存不多了。这时 kswapd0 会执行内存回收，直到剩余内存大于高阈值（pages_high）为止。虽然会触发内存回收，但是不会阻塞应用程序，因为两者关系是异步的。
    • 页最小阈值（pages_min）；
      • 如果剩余内存（pages_free）小于页最小阈值（pages_min），说明用户可用内存都耗尽了，此时就会触发直接内存回收，这时应用程序就会被阻塞，因为两者关系是同步的。
  • kswapd 的活动空间只有 pages_low 与 pages_min 之间的这段区域，如果剩余内存低于了 pages_min 会触发直接内存回收，高于了 pages_high 又不会唤醒 kswapd。
    • 增大 min_free_kbytes 配置（设置的是页最小阈值），这会使得系统预留过多的空闲内存，从而在一定程度上降低了应用程序可使用的内存量，这在一定程度上浪费了内存。极端情况下设置 min_free_kbytes 接近实际物理内存大小时，留给应用程序的内存就会太少而可能会频繁地导致 OOM 的发生。
      所以在调整 min_free_kbytes 之前，需要先思考一下，应用程序更加关注什么，如果关注延迟那就适当地增大 min_free_kbytes（尽量少的触发直接内存回收），如果关注内存的使用量那就适当地调小 min_free_kbytes。
  • NUMA架构下的内存回收策略
    • SMP 指的是一种多个 CPU 处理器共享资源的电脑硬件架构，也就是说每个 CPU 地位平等，它们共享相同的物理资源，包括总线、内存、IO、操作系统等。每个 CPU 访问内存所用时间都是相同的，因此，这种系统也被称为一致存储访问结构（UMA，Uniform Memory Access）。
      随着 CPU 处理器核数的增多，多个 CPU 都通过一个总线访问内存，这样总线的带宽压力会越来越大，同时每个 CPU 可用带宽会减少，这也就是 SMP 架构的问题。
    • 为了解决 SMP 架构的问题，就研制出了 NUMA 结构，即非一致存储访问结构（Non-uniform memory access）。
      NUMA 架构将每个 CPU 进行了分组，每一组 CPU 用 Node 来表示，一个 Node 可能包含多个 CPU 。每个 Node 有自己独立的资源，包括内存、IO 等，每个 Node 之间可以通过互联模块总线（QPI）进行通信，所以，也就意味着每个 Node 上的 CPU 都可以访问到整个系统中的所有内存。但是，访问远端 Node 的内存比访问本地内存要耗时很多。
    • 虽然说访问远端 Node 的内存比访问本地内存要耗时很多，但是相比内存回收的危害而言，访问远端 Node 的内存带来的性能影响还是比较小的。因此，zone_reclaim_mode 一般建议设置为 0，即在回收本地内存之前，在其他 Node 寻找空闲内存；
  • 如何保护一个进程不被OOM杀掉呢？
    • 在经历完直接内存回收后，空闲的物理内存大小依然不够，那么就会触发 OOM 机制，Linux 内核里有一个 oom_badness() 函数，它会把系统中可以被杀掉的进程扫描一遍，并对每个进程打分，得分最高的进程就会被首先杀掉。进程得分的结果受下面这两个方面影响：
      • 第一，进程已经使用的物理内存页面数。
      • 第二，每个进程的 OOM 校准值 oom_score_adj。它是可以通过 /proc/[pid]/oom_score_adj 来配置的。我们可以在设置 -1000 到 1000 之间的任意一个数值，调整进程被 OOM Kill 的几率。

在4GB物理内存的机器上，申请8G内存会怎么样？

  • 32位系统和64位系统所占用的内核空间不同
    • 32 位系统的内核空间占用 1G，位于最高处，剩下的 3G 是用户空间；
    • 64 位系统的内核空间和用户空间都是 128T，分别占据整个内存空间的最高和最低处，剩下的中间部分是未定义的。
  • 32位系统的场景
    • 因为 32 位操作系统，进程最多只能申请 3 GB 大小的虚拟内存空间，所以进程申请 8GB 内存的话，在申请虚拟内存阶段就会失败
  • 64位系统的场景
    • 64 位操作系统，进程可以使用 128 TB 大小的虚拟内存空间，所以进程申请 8GB 内存是没问题的，因为进程申请内存是申请虚拟内存，只要不读写这个虚拟内存，操作系统就不会分配物理内存。
    • 但是申请虚拟内存的过程中，还是用到了物理内存（比如内核保存虚拟内存的数据结构），如果主机只有2GB的物理内存的话，大概率会触发OOM。（没有开始Swap机制的情况下）
      • 内存溢出(Out Of Memory，简称OOM)是指应用系统中存在无法回收的内存或使用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。此时程序就运行不了，系统会提示内存溢出。
    • 程序申请的虚拟内存，如果没有被使用，它是不会占用物理空间的。当访问这块虚拟内存后，操作系统才会进行物理内存分配。如果申请物理内存大小超过了空闲物理内存大小，就要看操作系统有没有开启 Swap 机制：
      • 如果没有开启 Swap 机制，程序就会直接 OOM；
      • 如果有开启 Swap 机制，程序可以正常运行。
  • Swap机制
    当系统的物理内存不够用的时候，就需要将物理内存中的一部分空间释放出来，以供当前运行的程序使用。将内存数据换出磁盘，又从磁盘中恢复数据到内存的过程，就是 Swap 机制负责的。Swap 就是把一块磁盘空间或者本地文件，当成内存来使用，它包含换出和换入两个过程：
    • 换出（Swap Out） ，是把进程暂时不用的内存数据存储到磁盘中，并释放这些数据占用的内存；
    • 换入（Swap In），是在进程再次访问这些内存的时候，把它们从磁盘读到内存中来；

使用 Swap 机制优点是，应用程序实际可以使用的内存空间将远远超过系统的物理内存。当然，频繁地读写硬盘，会显著降低操作系统的运行速率，这也是 Swap 的弊端。
在Linux中，Swap机制会在内存不足和内存闲置的场景下触发：

  • 内存不足：当系统需要的内存超过了可用的物理内存时，内核会将内存中不常使用的内存页交换到磁盘上为当前进程让出内存，保证正在执行的进程的可用性，这个内存回收的过程是强制的直接内存回收（Direct Page Reclaim）。
  • 内存闲置：应用程序在启动阶段使用的大量内存在启动后往往都不会使用，通过后台运行的守护进程（kSwapd），我们可以将这部分只使用一次的内存交换到磁盘上为其他内存的申请预留空间。kSwapd 是 Linux 负责页面置换（Page replacement）的守护进程，它也是负责交换闲置内存的主要进程，它会在空闲内存低于一定水位 时，回收内存页中的空闲内存保证系统中的其他进程可以尽快获得申请的内存。kSwapd 是后台进程，所以回收内存的过程是异步的，不会阻塞当前申请内存的进程。
  • Swap换入换出的是什么类型的内存？
    换出文件页：内核缓存的文件数据，因为都有对应的磁盘文件，所以在回收文件数据的时候， 直接写回到对应的文件就可以了。
    换出匿名页：但是像进程的堆、栈数据等，它们是没有实际载体，这部分内存被称为匿名页。而且这部分内存很可能还要再次被访问，所以不能直接释放内存，于是就需要有一个能保存匿名页的磁盘载体，这个载体就是 Swap 分区。

如何避免预读失效和缓存污染问题？

传统的 LRU 算法存在这两个问题：

  • 「预读失效」导致缓存命中率下降
  • 「缓存污染」导致缓存命中率下降

Redis 的缓存淘汰算法则是通过实现 LFU 算法来避免「缓存污染」而导致缓存命中率下降的问题（Redis 没有预读机制）。

MySQL 和 Linux 操作系统是通过改进 LRU 算法来避免「预读失效和缓存污染」而导致缓存命中率下降的问题。

  • Linux的缓存在Page Cache 中
    Linux 操作系统是会对读取的文件数据进行缓存的，会缓存在文件系统中的 Page Cache。Page Cache 属于内存空间里的数据，由于内存访问比磁盘访问快很多，在下一次访问相同的数据就不需要通过磁盘 I/O 了，命中缓存就直接返回数据即可。
    因此，Page Cache 起到了加速访问数据的作用。
  • MySQL的缓存在Buffer Pool中
    MySQL 的数据是存储在磁盘里的，为了提升数据库的读写性能，Innodb 存储引擎设计了一个缓冲池（Buffer Pool），Buffer Pool 属于内存空间里的数据。

传统的 LRU 算法的实现思路是这样的：

  • 当访问的页在内存里，就直接把该页对应的 LRU 链表节点移动到链表的头部。
  • 当访问的页不在内存里，除了要把该页放入到 LRU 链表的头部，还要淘汰 LRU 链表末尾的页。

预读失效带来的问题

应用程序利用 read 系统调动读取 4KB 数据，实际上内核使用预读机制（ReadaHead） 机制完成了 16KB 数据的读取。预读机制带来的好处就是减少了 磁盘 I/O 次数，提高系统磁盘 I/O 吞吐量。如果这些被提前加载进来的页，并没有被访问，相当于这个预读工作是白做了，这个就是预读失效。

在传统的LRU算法中，如果预读页一直不会被访问到，不会被访问的预读页却占用了 LRU 链表前排的位置，而末尾淘汰的页，可能是热点数据，这样就大大降低了缓存命中率 。

避免预读失效的影响

要避免预读失效带来影响，最好就是让预读页停留在内存里的时间要尽可能的短，让真正被访问的页才移动到 LRU 链表的头部，从而保证真正被读取的热数据留在内存里的时间尽可能长。

  • Linux 操作系统实现两个了 LRU 链表：活跃 LRU 链表（active_list）和非活跃 LRU 链表（inactive_list）；
    • 有了这两个 LRU 链表后，预读页就只需要加入到 inactive list 区域的头部，当页被真正访问的时候，才将页插入 active list 的头部。如果预读的页一直没有被访问，就会从 inactive list 移除，这样就不会影响 active list 中的热点数据。
  • MySQL 的 Innodb 存储引擎是在一个 LRU 链表上划分来 2 个区域：young 区域 和 old 区域。
    • 划分这两个区域后，预读的页就只需要加入到 old 区域的头部，当页被真正访问的时候，才将页插入 young 区域的头部。如果预读的页一直没有被访问，就会从 old 区域移除，这样就不会影响 young 区域中的热点数据。

缓存污染带来的问题

如果还是使用「只要数据被访问一次，就将数据加入到活跃 LRU 链表头部（或者 young 区域）」这种方式的话，那么还存在缓存污染的问题。

当我们在批量读取数据的时候，由于数据被访问了一次，这些大量数据都会被加入到「活跃 LRU 链表」里，然后之前缓存在活跃 LRU 链表（或者 young 区域）里的热点数据全部都被淘汰了，如果这些大量的数据在很长一段时间都不会被访问的话，那么整个活跃 LRU 链表（或者 young 区域）就被污染了。

  • 比如，当某一个 SQL 语句扫描了大量的数据时，在 Buffer Pool 空间比较有限的情况下，可能会将 Buffer Pool 里的所有页都替换出去，导致大量热数据被淘汰了，等这些热数据又被再次访问的时候，由于缓存未命中，就会产生大量的磁盘 I/O，MySQL 性能就会急剧下降。

避免缓存污染造成的影响

只要我们提高进入到活跃 LRU 链表（或者 young 区域）的门槛，就能有效地保证活跃 LRU 链表（或者 young 区域）里的热点数据不会被轻易替换掉。

  • Linux ：在内存页被访问第二次的时候，才将页从 inactive list 升级到 active list 里。
  • MySQL Innodb：在内存页被访问第二次的时候，并不会马上将该页从 old 区域升级到 young 区域，因为还要进行停留在 old 区域的时间判断
    • 如果第二次的访问时间与第一次访问的时间在 1 秒内（默认值），那么该页就不会被从 old 区域升级到 young 区域；
    • 如果第二次的访问时间与第一次访问的时间超过 1 秒，那么该页就会从 old 区域升级到 young 区域；

通过提高了进入 active list （或者 young 区域）的门槛后，就很好了避免缓存污染带来的影响。

进程管理

进程、线程基础知识

  • 什么是进程/线程？
    进程是程序执行的基本单位。说简单一点，执行中的程序，就是进程。
    **线程是进程当中的一条执行流程。**同一个进程内多个线程之间可以共享代码段、数据段、打开的文件等资源，但每个线程各自都有一套独立的寄存器和栈，这样可以确保线程的控制流是相对独立的。
  • 并行和并发
    虽然单核的 CPU 在某一个瞬间，只能运行一个进程。但在 1 秒钟期间，它可能会运行多个进程，实际上这是并发，在一个CPU核心上运行多个任务。而并行是在多个CPU核心上运行同时多个任务。
  • 区别

线程是调度的基本单位，而进程则是资源拥有的基本单位。所以，所谓操作系统的任务调度，实际上的调度对象是线程，而进程只是给线程提供了虚拟内存、全局变量等资源。

对于线程和进程，我们可以这么理解：

  • 当进程只有一个线程时，可以认为进程就等于线程；
  • 当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量等资源，这些资源在上下文切换时是不需要修改的；

具体区别：

  • 进程是资源（包括内存、打开的文件等）分配的单位，线程是 CPU 调度（资源调度）的基本单位；
  • 进程拥有一个完整的资源平台，而线程只独享必不可少的资源，如寄存器和栈；
  • 线程同样具有就绪、阻塞、执行三种基本状态，同样具有状态之间的转换关系；
  • 线程能减少并发执行的时间和空间开销；
  • 线程的创建时间比进程快。创建时，进程需要资源管理信息，线程不会涉及这些资源管理信息，而是共享它们；
    • 线程释放的资源比进程少。
    • 同一个进程内的线程切换比进程切换快，因为线程具有相同的地址空间（虚拟内存共享），这意味着同一个进程的线程都具有同一个页表，那么在切换的时候不需要切换页表。而对于进程之间的切换，切换的时候要把页表给切换掉，而页表的切换过程开销是比较大的；
    • 由于同一进程的各线程间共享内存和文件资源，那么在线程之间数据传递的时候，就不需要经过内核了，这就使得线程之间的数据交互效率更高了；

所以，不管是时间效率，还是空间效率线程比进程都要高。

  • 进程的状态
    • 运行状态（Running）：该时刻进程占用 CPU；
    • 就绪状态（Ready）：可运行，由于其他进程处于运行状态而暂时停止运行；
    • 阻塞状态（Blocked）：该进程正在等待某一事件发生（如等待输入/输出操作的完成）而暂时停止运行，这时，即使给它CPU控制权，它也无法运行；

两个基本状态

  • 创建状态（new）：进程正在被创建时的状态；
  • 结束状态（Exit）：进程正在从系统中消失时的状态；
  • 进程的状态变迁：
    • NULL -> 创建状态：一个新进程被创建时的第一个状态；
    • 创建状态 -> 就绪状态：当进程被创建完成并初始化后，一切就绪准备运行时，变为就绪状态，这个过程是很快的；
    • 就绪态 -> 运行状态：处于就绪状态的进程被操作系统的进程调度器选中后，就分配给 CPU 正式运行该进程；
    • 运行状态 -> 结束状态：当进程已经运行完成或出错时，会被操作系统作结束状态处理；
    • 运行状态 -> 就绪状态：处于运行状态的进程在运行过程中，由于分配给它的运行时间片用完，操作系统会把该进程变为就绪态，接着从就绪态选中另外一个进程运行；
    • 运行状态 -> 阻塞状态：当进程请求某个事件且必须等待时，例如请求 I/O 事件；
    • 阻塞状态 -> 就绪状态：当进程要等待的事件完成时，它从阻塞状态变到就绪状态；
  • 挂起状态
    在虚拟内存管理中，通常会把阻塞状态的进程的物理内存空间换出到硬盘，等需要再次运行的时候，再从硬盘换入到物理内存。
    那么，就需要一个新的状态，来描述进程没有占用实际的物理内存空间的情况，这个状态就是挂起状态。这跟阻塞状态是不一样，阻塞状态是等待某个事件的返回。
    另外，挂起状态可以分为两种：
    • 阻塞挂起状态：进程在外存（硬盘）并等待某个事件的出现；
    • 就绪挂起状态：进程在外存（硬盘），但只要进入内存，即刻立刻运行；
  • 进程的控制结构
    在操作系统中，是用进程控制块（process control block，PCB）数据结构来描述进程的。
    PCB 是进程存在的唯一标识。这意味着一个进程的存在，必然会有一个 PCB，如果进程消失了，那么 PCB 也会随之消失。
  • PCB具体包含的信息
    进程描述信息：
    • 进程标识符：标识各个进程，每个进程都有一个并且唯一的标识符；
    • 用户标识符：进程归属的用户，用户标识符主要为共享和保护服务；

进程控制和管理信息：

  • 进程当前状态，如 new、ready、running、waiting 或 blocked 等；
  • 进程优先级：进程抢占 CPU 时的优先级；

资源分配清单：

  • 有关内存地址空间或虚拟地址空间的信息，所打开文件的列表和所使用的 I/O 设备信息。

CPU 相关信息：

  • CPU 中各个寄存器的值，当进程被切换时，CPU 的状态信息都会被保存在相应的 PCB 中，以便进程重新执行时，能从断点处继续执行。
  • PCB是如何组织的
    通常是通过链表的方式进行组织，把具有相同状态的进程链在一起，组成各种队列。比如：
    • 将所有处于就绪状态的进程链在一起，称为就绪队列；
    • 把所有因等待某事件而处于等待状态的进程链在一起就组成各种阻塞队列；
    • 对于运行队列在单核 CPU 系统中则只有一个运行指针了，因为单核 CPU 在某个时间，只能运行一个程序。
  • 进程的控制
    01 创建进程
    • 申请一个空白的 PCB，并向 PCB 中填写一些控制和管理进程的信息，比如进程的唯一标识等；
    • 为该进程分配运行时所必需的资源，比如内存资源；
    • 将 PCB 插入到就绪队列，等待被调度运行；

02 终止进程进程可以有 3 种终止方式：正常结束、异常结束以及外界干预（信号 kill 掉）。
当子进程被终止时，其在父进程处继承的资源应当还给父进程。而当父进程被终止时，该父进程的子进程就变为孤儿进程，会被 1 号进程收养，并由 1 号进程对它们完成状态收集工作。
终止进程的过程如下：

  • 查找需要终止的进程的 PCB；
  • 如果处于执行状态，则立即终止该进程的执行，然后将 CPU 资源分配给其他进程；
  • 如果其还有子进程，则应将该进程的子进程交给 1 号进程接管；
  • 将该进程所拥有的全部资源都归还给操作系统；
  • 将其从 PCB 所在队列中删除；

03 阻塞进程当进程需要等待某一事件完成时，它可以调用阻塞语句把自己阻塞等待。而一旦被阻塞等待，它只能由另一个进程唤醒。
阻塞进程的过程如下：

  • 找到将要被阻塞进程标识号对应的 PCB；
  • 如果该进程为运行状态，则保护其现场，将其状态转为阻塞状态，停止运行；
  • 将该 PCB 插入到阻塞队列中去；

04 唤醒进程进程由「运行」转变为「阻塞」状态是由于进程必须等待某一事件的完成，所以处于阻塞状态的进程是绝对不可能叫醒自己的。
如果某进程正在等待 I/O 事件，需由别的进程发消息给它，则只有当该进程所期待的事件出现时，才由发现者进程用唤醒语句叫醒它。
唤醒进程的过程如下：

  • 在该事件的阻塞队列中找到相应进程的 PCB；
  • 将其从阻塞队列中移出，并置其状态为就绪状态；
  • 把该 PCB 插入到就绪队列中，等待调度程序调度；

进程的阻塞和唤醒是一对功能相反的语句，如果某个进程调用了阻塞语句，则必有一个与之对应的唤醒语句。

线程相关

  • 线程的优点：
    • 一个进程中可以同时存在多个线程；
    • 各个线程之间可以并发执行；
    • 各个线程之间可以共享地址空间和文件等资源；
  • 线程的缺点：
    • 当进程中的一个线程崩溃时，会导致其所属进程的所有线程崩溃（这里是针对 C/C++ 语言，Java语言中的线程奔溃不会造成JVM进程崩溃。)
  • 线程的实现
    • 用户线程（User Thread）：在用户空间实现的线程，操作系统不参与，由用户态的线程库来完成线程的管理。
      • 用户线程是基于用户态的线程管理库来实现的，那么线程控制块（Thread Control Block, TCB） 也是在库里面来实现的，对于操作系统而言是看不到这个 TCB 的，它只能看到整个进程的 PCB。
        所以，用户线程的整个线程管理和调度，操作系统是不直接参与的，而是由用户级线程库函数来完成线程的管理，包括线程的创建、终止、同步和调度等。
    • 内核线程（Kernel Thread）：在内核中实现的线程，是由内核管理的线程；
      • 内核线程是由操作系统管理的，线程对应的 TCB 自然是放在操作系统里的，这样线程的创建、终止和管理都是由操作系统负责。
    • 轻量级进程（LightWeight Process）：在内核中来支持用户线程；
      • 轻量级进程（Light-weight process，LWP）是内核支持的用户线程，一个进程可有一个或多个 LWP，每个 LWP 是跟内核线程一对一映射的，也就是 LWP 都是由一个内核线程支持，而且 LWP 是由内核管理并像普通进程一样被调度。
        在大多数系统中，LWP与普通进程的区别也在于它只有一个最小的执行上下文和调度程序所需的统计信息。一般来说，一个进程代表程序的一个实例，而 LWP 代表程序的执行线程，因为一个执行线程不像进程那样需要那么多状态信息。

上下文切换

CPU上下文切换
在每个任务运行前，CPU 需要知道任务从哪里加载，又从哪里开始运行。
操作系统需要事先帮 CPU 设置好 CPU 寄存器和程序计数器，是任务必须依赖的环境，这些环境就叫做 CPU 上下文。
CPU 上下文切换就是先把前一个任务的 CPU 上下文（CPU 寄存器和程序计数器）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。
系统内核会存储保持下来的上下文信息，当此任务再次被分配给 CPU 运行时，CPU 会重新加载这些上下文，这样就能保证任务原来的状态不受影响，让任务看起来还是连续运行。

  • 进程的上下文切换
    进程的切换只能发生在内核态，是由内核管理和调度。
    所以，进程的上下文切换不仅包含了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的资源。
    通常，会把交换的信息保存在进程的 PCB，当要运行另外一个进程的时候，我们需要从这个进程的 PCB 取出上下文，然后恢复到 CPU 中，这使得这个进程可以继续执行。
  • 发生进程上下文切换有哪些场景？
    • 时间片调度原则，当某个进程的时间片耗尽了，进程就从运行状态变为就绪状态，系统从就绪队列选择另外一个进程运行；
    • 进程在系统资源不足（比如内存不足）时，要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其他进程运行；
    • 使用sleep()将自己挂起。
    • 高优先级优先执行，当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行；
    • 发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序；
  • 线程的上下文切换
    线程也有自己的私有数据，比如栈和寄存器等，这些在上下文切换时也是需要保存的。
    所以，线程的上下文切换的是什么这还得看线程是不是属于同一个进程：
    • 当两个线程不是属于同一个进程，则切换的过程就跟进程上下文切换一样；
    • 当两个线程是属于同一个进程，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据；

调度

一旦操作系统把进程切换到运行状态，也就意味着该进程占用着 CPU 在执行，但是当操作系统把进程切换到其他状态时，那就不能在 CPU 中执行了，于是操作系统会选择下一个要运行的进程。
选择一个进程运行这一功能是在操作系统中完成的，通常称为调度程序（scheduler）。

  • 调度时机
    在进程的生命周期中，当进程从一个运行状态到另外一状态变化的时候，其实会触发一次调度。
    • 从就绪态 -> 运行态：当进程被创建时，会进入到就绪队列，操作系统会从就绪队列选择一个进程运行；
    • 从运行态 -> 阻塞态：当进程发生 I/O 事件而阻塞时，操作系统必须选择另外一个进程运行；
    • 从运行态 -> 结束态：当进程退出结束后，操作系统得从就绪队列选择另外一个进程运行；

另外，如果硬件时钟提供某个频率的周期性中断，那么可以根据如何处理时钟中断 ，把调度算法分为两类：

  • 非抢占式调度算法挑选一个进程，然后让该进程运行直到被阻塞，或者直到该进程退出，才会调用另外一个进程，也就是说不会理时钟中断这个事情。
  • 抢占式调度算法挑选一个进程，然后让该进程只运行某段时间，如果在该时段结束时，该进程仍然在运行时，则会把它挂起，接着调度程序从就绪队列挑选另外一个进程。这种抢占式调度处理，需要在时间间隔的末端发生时钟中断，以便把 CPU 控制返回给调度程序进行调度，也就是常说的时间片机制。
  • CPU进行调度的原则
    • 原则一：CPU 利用率：调度程序应确保 CPU 是始终匆忙的状态，这可提高 CPU 的利用率；
    • 原则二：系统吞吐量：吞吐量表示的是单位时间内 CPU 完成进程的数量，长作业的进程会占用较长的 CPU 资源，因此会降低吞吐量，相反，短作业的进程会提升系统吞吐量；调度程序要提高系统吞吐量，要兼顾短任务和长任务运行完成数量。
    • 原则三：周转时间：周转时间是进程运行+阻塞时间+等待时间的总和，一个进程的周转时间越小越好；
    • 原则四：等待时间：这个等待时间不是阻塞状态的时间，而是进程处于就绪队列的时间，等待的时间越长，用户越不满意；
    • 原则五：响应时间：用户提交请求到系统第一次产生响应所花费的时间，在交互式系统中，响应时间是衡量调度算法好坏的主要标准。
  • 调度算法
    单核 CPU 系统中常见的调度算法。
    • 先来先服务调度算法(First Come First Serve, FCFS)
      顾名思义，先来后到，**每次从就绪队列选择最先进入队列的进程，然后一直运行，直到进程退出或被阻塞，才会继续从队列中选择第一个进程接着运行。**但是当一个长作业先运行了，那么后面的短作业等待的时间就会很长，不利于短作业。
    • 最短作业优先调度算法
      最短作业优先（Shortest Job First, SJF）调度算法同样也是顾名思义，它会优先选择运行时间最短的进程来运行，这有助于提高系统的吞吐量。这显然对长作业不利，很容易造成一种极端现象。
    • 高响应比优先调度算法
      高响应比优先 （Highest Response Ratio Next, HRRN）调度算法主要是权衡了短作业和长作业。每次进行进程调度时，先计算「响应比优先级」，然后把「响应比优先级」最高的进程投入运行。
      怎么才能知道一个进程要求服务的时间？这不是不可预知的吗？
      对的，这是不可预估的。所以，高响应比优先调度算法是「理想型」的调度算法，现实中是实现不了的。
    • 时间片轮转调度算法
      最古老、最简单、最公平且使用最广的算法就是时间片轮转（Round Robin, RR）调度算法。每个进程被分配一个时间段，称为时间片（Quantum），即允许该进程在该时间段中运行。
      • 如果时间片用完，进程还在运行，那么将会把此进程从 CPU 释放出来，并把 CPU 分配给另外一个进程；
      • 如果该进程在时间片结束前阻塞或结束，则 CPU 立即进行切换；

另外，时间片的长度就是一个很关键的点：

  • 如果时间片设得太短会导致过多的进程上下文切换，降低了 CPU 效率；
  • 如果设得太长又可能引起对短作业进程的响应时间变长。
  • 最高优先级调度算法
    调度程序能从就绪队列中选择最高优先级的进程进行运行，这称为最高优先级（Highest Priority First，HPF）调度算法。
    进程的优先级可以分为，静态优先级和动态优先级：
    • 静态优先级：创建进程时候，就已经确定了优先级了，然后整个运行时间优先级都不会变化；
    • 动态优先级：根据进程的动态变化调整优先级，比如如果进程运行时间增加，则降低其优先级，如果进程等待时间（就绪队列的等待时间）增加，则升高其优先级，也就是随着时间的推移增加等待进程的优先级。

该算法也有两种处理优先级高的方法，非抢占式和抢占式：

  • 非抢占式：当就绪队列中出现优先级高的进程，运行完当前进程，再选择优先级高的进程。
  • 抢占式：当就绪队列中出现优先级高的进程，当前进程挂起，调度优先级高的进程运行。

可能导致低优先级的进程永远不会运行。

  • 多级反馈队列调度算法
    多级反馈队列（Multilevel Feedback Queue）调度算法是「时间片轮转算法」和「最高优先级算法」的综合和发展。
    顾名思义：
    • 「多级」表示有多个队列，每个队列优先级从高到低，同时优先级越高时间片越短。
    • 「反馈」表示如果有新的进程加入优先级高的队列时，立刻停止当前正在运行的进程，转而去运行优先级高的队列；

对于短作业可能可以在第一级队列很快被处理完。对于长作业，如果在第一级队列处理不完，可以移入下次队列等待被执行，虽然等待的时间变长了，但是运行时间也变更长了，所以该算法很好的兼顾了长短作业，同时有较好的响应时间。

进程间有哪些通信方式？

由于每个进程的用户空间都是独立的，不能相互访问，这时就需要借助内核空间来实现进程间通信，原因很简单，每个进程都是共享一个内核空间。

  • 管道
    Linux 内核提供了不少进程间通信的方式，其中最简单的方式就是管道，管道分为「匿名管道」和「命名管道」。
$ ps auxf | grep mysql


「|」竖线就是一个管道，它的功能是将前一个命令（ps auxf）的输出，作为后一个命令（grep mysql）的输入，从这功能描述，可以看出管道传输数据是单向的，如果想相互通信，我们需要创建两个管道才行。这种就是匿名管道。
匿名管道顾名思义，它没有名字标识，匿名管道是特殊文件只存在于内存，没有存在于文件系统中，shell 命令中的「|」竖线就是匿名管道，通信的数据是无格式的流并且大小受限，通信的方式是单向的，数据只能在一个方向上流动，如果要双向通信，需要创建两个管道，再来匿名管道是只能用于存在父子关系的进程间通信，匿名管道的生命周期随着进程创建而建立，随着进程终止而消失。
命名管道突破了匿名管道只能在亲缘关系进程间的通信限制，因为使用命名管道的前提，需要在文件系统创建一个类型为 p 的设备文件，那么毫无关系的进程就可以通过这个设备文件进行通信。
另外，不管是匿名管道还是命名管道，进程写入的数据都是缓存在内核中，另一个进程读取数据时候自然也是从内核中获取，同时通信数据都遵循先进先出原则。
所谓的管道，就是内核里面的一串缓存。从管道的一段写入的数据，实际上是缓存在内核中的，另一端读取，也就是从内核中读取这段数据。另外，管道传输的数据是无格式的流且大小受限。

  • 消息队列
    消息队列克服了管道通信的数据是无格式的字节流并且通信效率低的问题，消息队列实际上是保存在内核的「消息链表」，消息队列的消息体可以是用户自定义的数据类型，发送数据时，会被分成一个一个独立的消息体，当然接收数据时，也要与发送方发送的消息体的数据类型保持一致，这样才能保证读取的数据是正确的。消息队列通信的速度不是最及时的，毕竟每次数据的写入和读取都需要经过用户态与内核态之间的拷贝过程。
  • 共享内存
    共享内存可以解决消息队列通信中用户态与内核态之间数据拷贝过程带来的开销，它直接分配一个共享空间，每个进程都可以直接访问，就像访问进程自己的空间一样快捷方便，不需要陷入内核态或者系统调用，大大提高了通信的速度，享有最快的进程间通信方式之名。但是便捷高效的共享内存通信，带来新的问题，多进程竞争同个共享资源会造成数据的错乱。
  • 信号量
    那么，就需要信号量来保护共享资源，以确保任何时刻只能有一个进程访问共享资源，这种方式就是互斥访问。信号量不仅可以实现访问的互斥性，还可以实现进程间的同步，信号量其实是一个计数器，表示的是资源个数，其值可以通过两个原子操作来控制，分别是 P 操作和 V 操作。
  • 信号
    信号是异步通信机制，信号可以在应用进程和内核之间直接交互，内核也可以利用信号来通知用户空间的进程发生了哪些系统事件，对于异常情况下的工作模式，就需要用「信号」的方式来通知进程。
    信号事件的来源主要有硬件来源（如键盘 Cltr+C ）和软件来源（如 kill 命令），一旦有信号发生，**进程有三种方式响应信号 **。
    1. 执行默认操作
      Linux 对每种信号都规定了默认操作，例如， SIGTERM信号，就是终止进程的意思
    2. 捕捉信号
      我们可以为信号定义一个信号处理函数。当信号发生时，我们就执行相应的信号处理函数。
    3. 忽略信号
      当我们不希望处理某些信号的时候，就可以忽略该信号，不做任何处理。有两个信号是应用进程无法捕捉和忽略的，即 SIGKILL 和 SEGSTOP，它们用于在任何时候中断或结束某一进程。
  • Socket
    前面说到的通信机制，都是工作于同一台主机，如果要与不同主机的进程间通信，那么就需要 Socket 通信了。Socket 实际上不仅用于不同的主机进程间通信，还可以用于本地主机进程间通信，可根据创建 Socket 的类型不同，分为三种常见的通信方式，一个是基于 TCP 协议的通信方式，一个是基于 UDP 协议的通信方式，一个是本地进程间通信方式。

线程间通信的方式呢？
同个进程下的线程之间都是共享进程的资源，只要是共享变量都可以做到线程间通信，比如全局变量，所以对于线程间关注的不是通信方式，而是关注多线程竞争共享资源的问题，信号量也同样可以在线程间实现互斥与同步：

  • 互斥的方式，可保证任意时刻只有一个线程访问共享资源；
  • 同步的方式，可保证线程 A 应在线程 B 之前执行；

多线程冲突了怎么办？

由于多线程执行操作共享变量可能会导致竞争状态，因此我们将此段访问共享变量的代码称为临界区（critical section），它是访问共享资源的代码片段，一定不能给多线程同时执行。
我们希望这段代码是互斥（mutualexclusion）的，也就说保证一个线程在临界区执行时，其他线程应该被阻止进入临界区，说白了，就是这段代码执行过程中，最多只能出现一个线程。
所谓同步，就是并发进程/线程在一些关键点上可能需要互相等待与互通消息，这种相互制约的等待与互通信息称为进程/线程同步。
所以我们使用加锁操作和解锁操作可以解决并发线程/进程的互斥问题。任何想进入临界区的线程，必须先执行加锁操作。若加锁操作顺利通过，则线程可进入临界区；在完成对临界资源的访问后再执行解锁操作，以释放该临界资源。
自旋锁

  • CPU 体系结构提供的特殊原子操作指令 —— 测试和置位（Test-and-Set）指令。原子操作就是，要么全部执行，要么都不执行，不能出现执行到一半的中间状态。
  • 可以用Test-and-Set实现忙等待锁/自旋锁，这是最简单的一种锁，一直自旋，利用 CPU 周期，直到锁可用。在单处理器上，需要抢占式的调度器（即不断通过时钟中断一个线程，运行其他线程）。否则，自旋锁在单 CPU 上无法使用，因为一个自旋的线程永远不会放弃 CPU。

无等待锁
无等待锁顾明思义就是获取不到锁的时候，不用自旋。既然不想自旋，那当没获取到锁的时候，就把当前线程放入到锁的等待队列，然后执行调度程序，把 CPU 让给其他线程执行。
信号量
通常信号量表示资源的数量，对应的变量是一个整型（sem）变量。
另外，还有两个原子操作的系统调用函数来控制信号量的，分别是：

  • P 操作：将 sem 减 1，相减后，如果 sem < 0，则进程/线程进入阻塞等待，否则继续，表明 P 操作可能会阻塞；
  • V 操作：将 sem 加 1，相加后，如果 sem <= 0，唤醒一个等待中的进程/线程，表明 V 操作不会阻塞；

PV 操作的函数是由操作系统管理和实现的，所以操作系统已经使得执行 PV 函数时是具有原子性的。

经典线程问题

生产者-消费者问题

  • 生产者在生成数据后，放在一个缓冲区中；
  • 消费者从缓冲区取出数据处理；
  • 任何时刻，只能有一个生产者或消费者可以访问缓冲区；

对问题分析可以得出：

  • 任何时刻只能有一个线程操作缓冲区，说明操作缓冲区是临界代码，需要互斥；
  • 缓冲区空时，消费者必须等待生产者生成数据；缓冲区满时，生产者必须等待消费者取出数据。说明生产者和消费者需要同步。

使用三个信号量，就可以实现同步和互斥。

  • 互斥信号量 mutex：用于互斥访问缓冲区，初始化值为 1；（保证两个线程互斥）
  • 资源信号量 fullBuffers：用于消费者询问缓冲区是否有数据，有数据则读取数据，初始化值为 0（表明缓冲区一开始为空）；
  • 资源信号量 emptyBuffers：用于生产者询问缓冲区是否有空位，有空位则生成数据，初始化值为 n （缓冲区大小）；

哲学家就餐问题

  • 5 个老大哥哲学家，闲着没事做，围绕着一张圆桌吃面；
  • 巧就巧在，这个桌子只有 5 支叉子，每两个哲学家之间放一支叉子；
  • 哲学家围在一起先思考，思考中途饿了就会想进餐；
  • 奇葩的是，这些哲学家要两支叉子才愿意吃面，也就是需要拿到左右两边的叉子才进餐；
  • 吃完后，会把两支叉子放回原处，继续思考；

使用互斥信号量mutex，初始值为1，要么拿到两把叉子或放回两把叉子的过程是互斥的。拿叉子时不能尝试返回叉子。
s[i]信号量，来表示第i个哲学家是否可以进餐。
我们还用一个数组 state 来记录每一位哲学家的三个状态，分别是在进餐状态、思考状态、饥饿状态（正在试图拿叉子）。
那么，一个哲学家只有在两个邻居都没有进餐时，才可以进入进餐状态。
第 i 个哲学家的左邻右舍，则由宏 LEFT 和 RIGHT 定义：比如 i 为 2，则 LEFT 为 1，RIGHT 为 3。
具体代码实现如下：

读者-写者问题
前面的「哲学家进餐问题」对于互斥访问有限的竞争问题（如 I/O 设备）一类的建模过程十分有用。
另外，还有个著名的问题是「读者-写者」，它为数据库访问建立了一个模型。
读者只会读取数据，不会修改数据，而写者即可以读也可以修改数据。
读者-写者的问题描述：

  • 「读-读」允许：同一时刻，允许多个读者同时读
  • 「读-写」互斥：没有写者时读者才能读，没有读者时写者才能写
  • 「写-写」互斥：没有其他写者时，写者才能写

公平策略：

  • 优先级相同；
  • 写者、读者互斥访问；
  • 只能一个写者访问临界区；
  • 可以有多个读者同时访问临界资源；

怎么避免死锁？

那么，当两个线程为了保护两个不同的共享资源而使用了两个互斥锁，那么这两个互斥锁应用不当的时候，可能会造成两个线程都在等待对方释放锁，在没有外力的作用下，这些线程会一直相互等待，就没办法继续运行，这种情况就是发生了死锁。
死锁只有同时满足以下四个条件才会发生：

  • 互斥条件；
    • 互斥条件是指多个线程不能同时使用同一个资源。
  • 持有并等待条件；
    • 当线程 A 已经持有了资源 1，又想申请资源 2，而资源 2 已经被线程 C 持有了，所以线程 A 就会处于等待状态，但是线程 A 在等待资源 2 的同时并不会释放自己已经持有的资源 1。
  • 不可剥夺条件；
    • 不可剥夺条件是指，当线程已经持有了资源 ，在自己使用完之前不能被其他线程获取，线程 B 如果也想使用此资源，则只能在线程 A 使用完并释放后才能获取。
  • 环路等待条件；
    • 环路等待条件指的是，在死锁发生的时候，两个线程获取资源的顺序构成了环形链。比如，线程 A 已经持有资源 2，而想请求资源 1， 线程 B 已经获取了资源 1，而想请求资源 2，这就形成资源请求等待的环形图。

所以要避免死锁问题，就是要破坏其中一个条件即可，最常见的并且可行的就是使用资源有序分配法，来破坏环路等待条件。

  • 就是A线程和B线程获取资源的顺序要一致。两个线程都使用相同的顺序来访问资源。

什么是悲观锁、乐观锁？

  • 互斥锁与自旋锁
    最底层的两种锁就是互斥锁和自旋锁，有很多高级的锁都是基于它们实现的。
    当已经有一个线程加锁后，其他线程加锁则就会失败，互斥锁和自旋锁对于加锁失败后的处理方式是不一样的：
    • 互斥锁加锁失败后，线程会释放 CPU ，给其他线程；
      • 互斥锁是一种「独占锁」，比如当线程 A 加锁成功后，此时互斥锁已经被线程 A 独占了，只要线程 A 没有释放手中的锁，线程 B 加锁就会失败，于是就会释放 CPU 让给其他线程，既然线程 B 释放掉了 CPU，自然线程 B 加锁的代码就会被阻塞。
    • 自旋锁加锁失败后，线程会忙等待，直到它拿到锁；
      • 使用自旋锁的时候，当发生多线程竞争锁的情况，加锁失败的线程会「忙等待」，直到它拿到锁。这里的「忙等待」可以用 while 循环等待实现，不过最好是使用 CPU 提供的 PAUSE 指令来实现「忙等待」，因为可以减少循环等待时的耗电量。
        PAUSE指令：用于暂时终止程序的运行。可以提高自选等待循环的性能。
  • 自旋锁与互斥锁
    • 互斥锁会存在两次线程上下文切换的成本，如下：
      • 当线程加锁失败时，内核会把线程的状态从「运行」状态设置为「睡眠」状态，然后把 CPU 切换给其他线程运行；
      • 接着，当锁被释放时，之前**「睡眠」状态的线程会变为「就绪」状态**，然后内核会在合适的时间，把 CPU 切换给该线程运行。

如果锁住的代码执行时间比较短，那可能上下文切换的时间可能比锁住代码执行时间更长。所以，如果你能确定被锁住的代码执行时间很短，就不应该用互斥锁，而应该选用自旋锁，否则使用互斥锁。

  • 自旋锁是通过 CPU 提供的 CAS 函数（Compare And Swap），在「用户态」完成加锁和解锁操作，不会主动产生线程上下文切换，所以相比互斥锁来说，会快一些，开销也小一些。

自旋锁与互斥锁使用层面比较相似，但实现层面上完全不同：当加锁失败时，互斥锁用「线程切换」来应对，自旋锁则用「忙等待」来应对。
需要注意，在单核 CPU 上，需要抢占式的调度器（即不断通过时钟中断一个线程，运行其他线程）。否则，自旋锁在单 CPU 上无法使用，因为一个自旋的线程永远不会放弃 CPU。

  • 读写锁
    读写锁从字面意思我们也可以知道，它由「读锁」和「写锁」两部分构成，如果只读取共享资源用「读锁」加锁，如果要修改共享资源则用「写锁」加锁。所以，读写锁适用于能明确区分读操作和写操作的场景。
    读写锁的工作原理如下：
    • **读锁是共享锁。**当「写锁」没有被线程持有时，多个线程能够并发地持有读锁，这大大提高了共享资源的访问效率，因为「读锁」是用于读取共享资源的场景，所以多个线程同时持有读锁也不会破坏共享资源的数据。
    • **写锁是独占锁。**一旦「写锁」被线程持有后，读线程的获取读锁的操作会被阻塞，而且其他写线程的获取写锁的操作也会被阻塞。

读写锁在读多写少的场景，能发挥出优势。因为多个线程可以同时持有读锁。
另外，根据实现的不同，读写锁可以分为「读优先锁」和「写优先锁」。

  • 「读优先锁」期望的是，读锁能被更多的线程持有，以便提高读线程的并发性。即所有的读锁优先级比写锁高，写锁必须等待读锁释放。
  • 「写优先锁」是期望优先服务写线程。当读线程 A 先持有了读锁，写线程 B 在获取写锁的时候，会被阻塞，并且在阻塞过程中，后续来的读线程 C 获取读锁时会失败，于是读线程 C 将被阻塞在获取读锁的操作，这样只要读线程 A 释放读锁后，写线程 B 就可以成功获取写锁。

公平读写锁比较简单的一种方式是：用队列把获取锁的线程排队，不管是写线程还是读线程都按照先进先出的原则加锁即可，这样读线程仍然可以并发，也不会出现「饥饿」的现象。

  • 悲观锁
    悲观锁做事比较悲观，它认为多线程同时修改共享资源的概率比较高，于是很容易出现冲突，所以访问共享资源前，先要上锁。
    那相反的，如果多线程同时修改共享资源的概率比较低，就可以采用乐观锁。
  • 乐观锁
    乐观锁做事比较乐观，它假定冲突的概率很低，它的工作方式是：先修改完共享资源，再验证这段时间内有没有发生冲突，如果没有其他线程在修改资源，那么操作完成，如果发现有其他线程已经修改过这个资源，就放弃本次操作。
    可见，乐观锁的心态是，不管三七二十一，先改了资源再说。另外，你会发现乐观锁全程并没有加锁，所以它也叫无锁编程。
    乐观锁虽然去除了加锁解锁的操作，但是一旦发生冲突，重试的成本非常高，所以只有在冲突概率非常低，且加锁成本非常高的场景时，才考虑使用乐观锁。

不管使用的哪种锁，我们的加锁的代码范围应该尽可能的小，也就是加锁的粒度要小，这样执行速度会比较快。再来，使用上了合适的锁，就会快上加快了。

一个进程最多可以创建多少个线程？

主要和进程的虚拟内存空间大小、系统参数限制最大线程个数有关。

因为创建一个线程，操作系统需要为其分配一个栈空间，如果线程数量越多，所需的栈空间就要越大，那么虚拟内存就会占用的越多。

  • 实践：
    我们可以执行 ulimit -a 这条命令，查看进程创建线程时默认分配的栈空间大小。在前面我们知道，在 32 位 Linux 系统里，一个进程的虚拟空间是 4G，内核分走了1G，留给用户用的只有 3G。那么假设创建一个线程需要占用 10M 虚拟内存，总共有 3G 虚拟内存可以使用。于是我们可以算出，最多可以创建差不多 300 个（3G/10M）左右的线程。
    • 下面这三个内核参数的大小，都会影响创建线程的上限：
      • /proc/sys/kernel/threads-max，表示系统支持的最大线程数，默认值是 14553；
      • /proc/sys/kernel/pid_max，表示系统全局的 PID 号数值的限制，每一个进程或线程都有 ID，ID 的值超过这个数，进程或线程就会创建失败，默认值是 32768；
      • /proc/sys/vm/max_map_count，表示限制一个进程可以拥有的VMA(虚拟内存区域)的数量，如果它的值很小，也会导致创建线程失败，默认值是 65530。
  • 总结：
    32 位系统，用户态的虚拟空间只有 3G，如果创建线程时分配的栈空间是 10M，那么一个进程最多只能创建 300 个左右的线程。
    64 位系统，用户态的虚拟空间大到有 128T，理论上不会受虚拟内存大小的限制，而会受系统的参数或性能限制。

线程崩溃了，进程也会崩溃吗？

如果线程因为非法访问内存崩溃，进程也会崩溃。

  • 因为进程中，每个线程地址空间共享，如果产生非法内存访问，可能会对其他线程产生影响。所以整个线程就会崩溃。

非法访问的情况：对只读内存进行写入、访问进程没有权限访问的地址（比如内核空间）、访问不存在的内存。

操作系统使用信号来让进程崩溃。背后的机制如下：

  1. CPU 执行正常的进程指令
  2. 调用 kill 系统调用向进程发送信号
  3. 进程收到操作系统发的信号，CPU 暂停当前程序运行，并将控制权转交给操作系统
  4. 调用 kill 系统调用向进程发送信号（假设为 11，即 SIGSEGV，一般非法访问内存报的都是这个错误）
  5. 操作系统根据情况执行相应的信号处理程序（函数），一般执行完信号处理程序逻辑后会让进程退出。

为什么线程崩溃不会导致JVM进程崩溃？

因为 JVM 自定义了自己的信号处理函数，拦截了 SIGSEGV 信号，针对这两者不让它们崩溃。在启动 JVM 的时候，也设置了信号处理函数，收到 SIGSEGV，SIGPIPE 等信号后最终会调用 JVM_handle_linux_signal这个自定义信号处理函数。恢复了线程的执行，并抛出 StackoverflowError 和 NPE（NullPointExpection），这就是为什么 JVM 不会崩溃且我们能捕获这两个异常的原因。

  • SEGV是segmentation violation（段违例）的缩写。

如果 JVM 不对信号做额外的处理，最后会自己退出并产生 crash 文件 hs_err_pid_xxx.log（可以通过 -XX:ErrorFile=/var/log/hs_err.log 这样的方式指定），这个文件记录了虚拟机崩溃的重要原因。

调度算法

进程调度/页面置换/磁盘调度算法

进程调度算法

进程调度算法也称CPU调度算法，因为进程是由CPU调度的。

发生CPU调度的情况：

  1. 当进程从运行状态转到等待状态（阻塞状态）；
    非抢占式调度。比如进程等待I/O发生阻塞。
  2. 当进程从运行状态转到就绪状态；
    抢占式调度。时间片用完，运行状态会转为就绪状态。
  3. 当进程从等待状态转到就绪状态；
    抢占式调度。假设有一个进程是处于等待状态的，但是它的优先级比较高，如果该进程等待的事件发生了，它就会转到就绪状态，一旦它转到就绪状态，如果我们的调度算法是以优先级来进行调度的，那么它就会立马抢占正在运行的进程，所以这个时候就会发生 CPU 调度。
  4. 当进程从运行状态转到终止状态；
    非抢占式调度。进程运行结束，就到了终止状态。

非抢占式调度的意思是，进程会一直运行，直到进程完成或发生某个事件被阻塞，才会把CPU让给其他进程。

抢占式调度的意思是，进程正在运行时，可以被打断，把CPU让给其他进程。抢占的原则一般有三种，分别是：时间片原则、优先权原则、短作业优先原则。

  • 先来先服务调度算法
    最简单的一个调度算法，就是非抢占式的先来先服务（First Come First Severd, FCFS）算法了。先来后到，每次从就绪队列选择最先进入队列的进程，然后一直运行，直到进程退出或被阻塞，才会继续从队列中选择第一个进程接着运行。
    但是，该算法对长任务有利，如果长任务进行I/O操作，CPU也会持有进程等待，所以不适用于I/O繁忙型作业的系统。
  • 最短作业优先调度算法
    最短作业优先（Shortest Job First, SJF）调度算法，它会优先选择运行时间最短的进程来运行，这有助于提高系统的吞吐量。
    但是，该算法对短作业有利，如果就绪队列中有非常多的短作业，那么会导致长作业长时间不会被运行。
  • 高响应比优先调度算法
    高响应比优先 （Highest Response Ratio Next, HRRN）调度算法主要是权衡了短作业和长作业。
    每次进行进程调度时，先计算「响应比优先级」，然后把「响应比优先级」最高的进程投入运行，「响应比优先级」的计算公式：
    • 如果两个进程的「等待时间」相同时，「要求的服务时间」越短，「响应比」就越高，这样短作业的进程容易被选中运行；
    • 如果两个进程「要求的服务时间」相同时，「等待时间」越长，「响应比」就越高，这就兼顾到了长作业进程，因为进程的响应比可以随时间等待的增加而提高，当其等待时间足够长时，其响应比便可以升到很高，从而获得运行的机会；
  • 时间片轮转调度算法
    最古老、最简单、最公平且使用最广的算法就是时间片轮转（Round Robin, RR）调度算法。
    每个进程被分配一个时间片（Quantum），即允许该进程在该时间段中运行。
    • 如果时间片用完，进程还在运行，从CPU中释放进程，并把 CPU 分配另外一个进程；
    • 如果该进程在时间片结束前阻塞或结束，则 CPU 立即进行切换；

但是不适用于多用户计算机系统。

  • 最高优先级调度算法
    对于多用户计算机系统，它们希望调度是有优先级的，即希望调度程序能从就绪队列中选择最高优先级的进程进行运行，这称为最高优先级（Highest Priority First，HPF）调度算法。
    该算法也有两种处理优先级高的方法，非抢占式和抢占式：
    • 非抢占式：当就绪队列中出现优先级高的进程，运行完当前进程，再选择优先级高的进程。
    • 抢占式：当就绪队列中出现优先级高的进程，当前进程挂起，调度优先级高的进程运行。

但是，可能会导致低优先级的进程永远不会运行。

  • 多级反馈队列调度算法
    多级反馈队列（Multilevel Feedback Queue）调度算法是「时间片轮转算法」和「最高优先级算法」的综合和发展。
    • 多级：即多个队列，每个队列优先级从高到低，但优先级越高时间片越短。
    • 反馈：如果有新的进程加入优先级高的队列时，立刻停止当前正在运行的进程，转而去运行优先级高的队列；

多级反馈队列调度算法工作方式如下：

  • 设置了多个队列，赋予每个队列不同的优先级，每个队列优先级从高到低，同时优先级越高时间片越短；
  • 新的进程会被放入到第一级队列的末尾，按先来先服务的原则排队等待被调度，如果在第一级队列规定的时间片没运行完成，则将进程转入到第二级队列的末尾，以此类推，直至完成；
  • 当较高优先级的队列为空，才调度较低优先级的队列中的进程运行。如果进程运行时，有新进程进入较高优先级的队列，则停止当前运行的进程并将其移入到原队列末尾，接着让较高优先级的进程运行；

可以发现，对于短作业可能可以在第一级队列很快被处理完。对于长作业，如果在第一级队列处理不完，可以移入下次队列等待被执行，虽然等待的时间变长了，但是运行时间也会更长了，所以该算法很好的兼顾了长短作业，同时有较好的响应时间。

内存页面置换算法

页面置换算法的功能是，当出现缺页异常，需调入新页面而内存已满时，选择被置换的物理页面，也就是说选择一个物理页面换出到磁盘，然后把需要访问的页面换入到物理页。

算法的目标是，尽可能减少页面的换入换出的次数，常见的页面置换算法有如下几种：

  • 最佳页面置换算法（OPT）
  • 先进先出置换算法（FIFO）
  • 最近最久未使用的置换算法（LRU）
  • 时钟页面置换算法（Lock）
  • 最不常用置换算法（LFU）
  • 缺页异常（缺页中断）
    当 CPU 访问的页面不在物理内存时，便会产生一个缺页中断，请求操作系统将所缺页调入到物理内存。那它与一般中断的主要区别在于：
    • 缺页中断在指令执行「期间」产生和处理中断信号，而一般中断在一条指令执行「完成」后检查和处理中断信号。
    • 缺页中断返回到该指令的开始重新执行「该指令」，而一般中断返回回到该指令的「下一个指令」执行。

  1. 在 CPU 里访问一条 Load M 指令，然后 CPU 会去找 M 所对应的页表项。
  2. 如果该页表项的状态位是「有效的」，那 CPU 就可以直接去访问物理内存了，如果状态位是「无效的」，则 CPU 则会发送缺页中断请求。
  3. 操作系统收到了缺页中断，则会执行缺页中断处理函数，先会查找该页面在磁盘中的页面的位置。
  4. 找到磁盘中对应的页面后，需要把该页面换入到物理内存中，但是在换入前，需要在物理内存中找空闲页，如果找到空闲页，就把页面换入到物理内存中。
    如果此时找不到空闲页，就需要页面置换算法，来选择一个物理页，如果该物理页有被修改过（脏页），则把它换出到磁盘，然后把该被置换出去的页表项的状态改成「无效的」，最后把正在访问的页面装入到这个物理页中。
  5. 页面从磁盘换入到物理内存完成后，则把页表项中的状态位修改为「有效的」。
  6. 最后，CPU 重新执行导致缺页异常的指令。
  • 页表项
    页表项通常有如下图的字段：
    • 状态位：用于表示该页是否有效，也就是说是否在物理内存中，供程序访问时参考。
    • 访问字段：用于记录该页在一段时间被访问的次数，供页面置换算法选择出页面时参考。
    • 修改位：表示该页在调入内存后是否有被修改过，由于内存中的每一页都在磁盘上保留一份副本，因此，如果没有修改，在置换该页时就不需要将该页写回到磁盘上，以减少系统的开销；如果已经被修改，则将该页重写到磁盘上，以保证磁盘中所保留的始终是最新的副本。
    • 硬盘地址：用于指出该页在硬盘上的地址，通常是物理块号，供调入该页时使用。
  • 最佳页面置换算法
    最佳页面置换算法基本思路是，置换在「未来」最长时间不访问的页面。
    所以，该算法实现需要计算内存中每个逻辑页面的「下一次」访问时间，然后比较，选择未来最长时间不访问的页面。

    2号页触发缺页中断，此时内存中找不到空闲页，就需要页面置换算法。依据最佳置换算法，会将7号页换出（0号页在2号页后第1个就会被访问，1号页在2号页后第10个会被访问，7号页在2号页后第14个会被访问，7号页在已经装入内存的作业中是未来最长时间不会被访问的，所以换出7号页）。
    在这个请求的页面序列中，缺页共发生了 7 次（空闲页换入 3 次 + 最优页面置换 4 次），页面置换共发生了 4 次。
    这很理想，但是实际系统中无法实现，因为程序访问页面时是动态的，我们是无法预知每个页面在「下一次」访问前的等待时间。
    所以，最佳页面置换算法作用是为了衡量你的算法的效率，你的算法效率越接近该算法的效率，那么说明你的算法是高效的。
  • 先进先出置换算法
    既然我们无法预知页面在下一次访问前所需的等待时间，那我们可以选择在内存驻留时间很长的页面进行中置换，这个就是「先进先出置换」算法的思想。
    在这个请求的页面序列中，缺页共发生了 10 次，页面置换共发生了 7 次，跟最佳页面置换算法比较起来，性能明显差了很多。
  • 最近最久未使用的置换算法
    最近最久未使用（LRU）的置换算法的基本思路是，发生缺页时，选择最长时间没有被访问的页面进行置换，也就是说，该算法假设已经很久没有使用的页面很有可能在未来较长的一段时间内仍然不会被使用。
    这种算法近似最优置换算法，最优置换算法是通过「未来」的使用情况来推测要淘汰的页面，而 LRU 则是通过「历史」的使用情况来推测要淘汰的页面。
    在这个请求的页面序列中，缺页共发生了 9 次，页面置换共发生了 6 次，跟先进先出置换算法比较起来，性能提高了一些。
    虽然 LRU 在理论上是可以实现的，但代价很高。为了完全实现 LRU，需要在内存中维护一个所有页面的链表，最近最多使用的页面在表头，最近最少使用的页面在表尾。
    困难的是，在每次访问内存时都必须要更新「整个链表」。在链表中找到一个页面，删除它，然后把它移动到表头是一个非常费时的操作。
    所以，LRU 虽然看上去不错，但是由于开销比较大，实际应用中比较少使用。
  • 时钟页面置换算法
    时钟页面置换算法就可以两者兼得，它跟 LRU 近似，又是对 FIFO 的一种改进。
    该算法的思路是，把所有的页面都保存在一个类似钟面的「环形链表」中，一个表针指向最老的页面。
    当发生缺页中断时，算法首先检查表针指向的页面：
    • 如果它的访问位位是 0 就淘汰该页面，并把新的页面插入这个位置，然后把表针前移一个位置；
    • 如果访问位是 1 就清除访问位，并把表针前移一个位置，重复这个过程直到找到了一个访问位为 0 的页面为止；
  • 最不常用算法
    最不常用（LFU）算法，当发生缺页中断时，选择「访问次数」最少的那个页面，并将其淘汰。
    它的实现方式是，对每个页面设置一个「访问计数器」，每当一个页面被访问时，该页面的访问计数器就累加 1。在发生缺页中断时，淘汰计数器值最小的那个页面。
    要增加一个计数器来实现，这个硬件成本是比较高的，另外如果要对这个计数器查找哪个页面访问次数最小，查找链表本身，如果链表长度很大，是非常耗时的，效率不高。
    但还有个问题，LFU 算法只考虑了频率问题，没考虑时间的问题，比如有些页面在过去时间里访问的频率很高，但是现在已经没有访问了，而当前频繁访问的页面由于没有这些页面访问的次数高，在发生缺页中断时，就会可能会误伤当前刚开始频繁访问，但访问次数还不高的页面。
    那这个问题的解决的办法还是有的，可以定期减少访问的次数，比如当发生时间中断时，把过去时间访问的页面的访问次数除以 2，也就说，随着时间的流失，以前的高访问次数的页面会慢慢减少，相当于加大了被置换的概率。

磁盘调度算法

磁盘调度算法的目的很简单，就是为了提高磁盘的访问性能，一般是通过优化磁盘的访问请求顺序来做到的。
寻道的时间是磁盘访问最耗时的部分，如果请求顺序优化的得当，必然可以节省一些不必要的寻道时间，从而提高磁盘的访问性能。
假设有下面一个请求序列，每个数字代表磁道的位置：
98，183，37，122，14，124，65，67
初始磁头当前的位置是在第 53 磁道。
接下来，分别对以上的序列，作为每个调度算法的例子，那常见的磁盘调度算法有：

  • 先来先服务算法
  • 最短寻道时间优先算法
  • 扫描算法
  • 循环扫描算法
  • LOOK 与 C-LOOK 算法
  • 先来先服务
    先来先服务（First-Come，First-Served，FCFS），顾名思义，先到来的请求，先被服务。
    先来先服务算法总共移动了 640 个磁道的距离，这么一看这种算法，比较简单粗暴，但是如果大量进程竞争使用磁盘，请求访问的磁道可能会很分散，那先来先服务算法在性能上就会显得很差，因为寻道时间过长。
  • 最短寻道时间优先
    最短寻道时间优先（Shortest Seek First，SSF）算法的工作方式是，优先选择从当前磁头位置所需寻道时间最短的请求


磁头移动的总距离是 236 磁道，相比先来先服务性能提高了不少。但这个算法可能存在某些请求的饥饿，因为本次例子我们是静态的序列，看不出问题，假设是一个动态的请求，如果后续来的请求都是小于 183 磁道的，那么 183 磁道可能永远不会被响应，于是就产生了饥饿现象，这里产生饥饿的原因是磁头在一小块区域来回移动。

  • 扫描算法
    为了防止这个问题，可以规定：磁头在一个方向上移动，访问所有未完成的请求，直到磁头到达该方向上的最后的磁道，才调换方向，这就是扫描（Scan）算法。
    这种算法也叫做电梯算法，比如电梯保持按一个方向移动，直到在那个方向上没有请求为止，然后改变方向。
    磁头先响应左边的请求，直到到达最左端（ 0 磁道）后，才开始反向移动，响应右边的请求。
    扫描调度算法性能较好，不会产生饥饿现象，但是存在这样的问题，中间部分的磁道会比较占便宜，中间部分相比其他部分响应的频率会比较多，也就是说每个磁道的响应频率存在差异。
  • 循环扫描算法
    扫描算法使得每个磁道响应的频率存在差异，那么要优化这个问题的话，可以总是按相同的方向进行扫描，使得每个磁道的响应频率基本一致。
    循环扫描（Circular Scan, CSCAN ）规定：只有磁头朝某个特定方向移动时，才处理磁道访问请求，而返回时直接快速移动至最靠边缘的磁道，也就是复位磁头，这个过程是很快的，并且返回中途不处理任何请求，该算法的特点，就是磁道只响应一个方向上的请求。
    循环扫描算法相比于扫描算法，对于各个位置磁道响应频率相对比较平均。
  • LOOK与C-LOOK算法
    我们前面说到的扫描算法和循环扫描算法，都是磁头移动到磁盘「最始端或最末端」才开始调换方向。
    那这其实是可以优化的，优化的思路就是磁头在移动到「最远的请求」位置，然后立即反向移动。
    那针对 SCAN 算法的优化则叫 LOOK 算法，它的工作方式，磁头在每个方向上仅仅移动到最远的请求位置，然后立即反向移动，而不需要移动到磁盘的最始端或最末端，反向移动的途中会响应请求。
    而针 C-SCAN 算法的优化则叫 C-LOOK，它的工作方式，磁头在每个方向上仅仅移动到最远的请求位置，然后立即反向移动，而不需要移动到磁盘的最始端或最末端，反向移动的途中不会响应请求。

文件系统

文件系统概述

  • 文件系统的基本组成
    文件系统负责把用户的文件存到磁盘中，即使计算机断电，磁盘里的数据也不会丢失，也就是负责管理持久化的数据。
    文件系统的基本数据单位是文件，它的目的是对磁盘上的文件进行组织管理，那组织的方式不同，就会形成不同的文件系统。
    Linux 文件系统会为每个文件分配两个数据结构：索引节点（index node）和目录项（directory entry），它们主要用来记录文件的元信息和目录层次结构。
    • 索引节点，也就是 inode，用来记录文件的元信息，比如 inode 编号、文件大小、访问权限、创建时间、修改时间、数据在磁盘的位置等等。索引节点是文件的唯一标识，它们之间一一对应，也同样都会被存储在硬盘中，所以索引节点同样占用磁盘空间。
    • 目录项，也就是 dentry，用来记录文件的名字、索引节点指针以及与其他目录项的层级关联关系。多个目录项关联起来，就会形成目录结构，但它与索引节点不同的是，目录项是由内核维护的一个数据结构，不存放于磁盘，而是缓存在内存。

注意：目录和目录项虽然名字很相近，但是它们不是一个东西，目录是个文件，持久化存储在磁盘，而目录项是内核一个数据结构，缓存在内存。
如果查询目录频繁从磁盘读，效率会很低，所以内核会把已经读过的目录用目录项这个数据结构缓存在内存，下次再次读到相同的目录时，只需从内存读就可以，大大提高了文件系统的效率。
磁盘读写的最小单位是扇区，扇区的大小只有 512B 大小，很明显，如果每次读写都以这么小为单位，那这读写的效率会非常低。所以，文件系统把多个扇区组成了一个逻辑块，每次读写的最小单位就是逻辑块（数据块）。

  • 虚拟文件系统
    **虚拟文件系统（Virtual File System，VFS）。**VFS 定义了一组所有文件系统都支持的数据结构和标准接口，这样程序员不需要了解文件系统的工作原理，只需要了解 VFS 提供的统一接口即可。
  • 文件的使用
    使用文件之前应先打开文件。
    使用 write 写数据，其中 write 使用 open 所返回的文件描述符，并不使用文件名作为参数。
fd = open(name, flag); # 打开文件
...
write(fd,...);         # 写数据
...
close(fd);             # 关闭文件


我们打开了一个文件后，操作系统会跟踪进程打开的所有文件，就是操作系统为每个进程维护一个打开文件表，文件描述符是打开文件表的一个索引。对应着文件表里的每一项。
操作系统在打开文件表中维护着打开文件的状态和信息：

  • 文件指针：系统跟踪上次读写位置作为当前文件位置指针，这种指针对打开文件的某个进程来说是唯一的；
  • 文件打开计数器：多个进程可能打开同一个文件，所以系统在删除打开文件条目之前，必须等待最后一个进程关闭文件，该计数器跟踪打开和关闭的数量，当该计数为 0 时，系统关闭文件，删除该条目；
  • 文件磁盘位置：绝大多数文件操作都要求系统修改文件数据，文件磁盘位置信息保存在内存中，以免每个操作都从磁盘中读取；
  • 访问权限：每个进程打开文件都需要有一个访问模式（创建、只读、读写、添加等），该信息保存在进程的打开文件表中，以便操作系统能允许或拒绝之后的 I/O 请求；

文件系统的基本操作单位是数据块。

  • 当用户进程从文件读取 1 个字节大小的数据时，文件系统则需要获取字节所在的数据块，再返回数据块对应的用户进程所需的数据部分。
  • 当用户进程把 1 个字节大小的数据写进文件时，文件系统则找到需要写入数据的数据块的位置，然后修改数据块中对应的部分，最后再把数据块写回磁盘。
  • 文件的存储
    主要分为两种方式存储在硬盘上
    连续空间存放方式 和 非连续空间存放方式
    其中，非连续空间存放方式又可以分为「链表方式」和「索引方式」。
    • 连续空间存放方式
      连续空间存放方式顾名思义，文件存放在磁盘「连续的」物理空间中。这种模式下，文件的数据都是紧密相连，读写效率很高，因为一次磁盘寻道就可以读出整个文件。
      文件头里需要指定「起始块的位置」和「长度」，有了这两个信息就可以很好的表示文件存放方式是一块连续的磁盘空间。
      连续空间存放的方式虽然读写效率高，但是有「磁盘空间碎片」和「文件长度不易扩展」的缺陷。
    • 非连续空间存放方式
      非连续空间存放方式分为「链表方式」和「索引方式」。
      链表的方式存放是离散的，不用连续的，于是就可以消除磁盘碎片，可大大提高磁盘空间的利用率，同时文件的长度可以动态扩展。根据实现的方式的不同，链表可分为「隐式链表」和「显式链接」两种形式。
      • 文件要以「隐式链表」的方式存放的话，实现的方式是文件头要包含「第一块」和「最后一块」的位置，并且每个数据块里面留出一个指针空间，用来存放下一个数据块的位置，这样一个数据块连着一个数据块，从链头开始就可以顺着指针找到所有的数据块，所以存放的方式可以是不连续的。
        隐式链表的存放方式的缺点在于无法直接访问数据块，只能通过指针顺序访问文件，以及数据块指针消耗了一定的存储空间。隐式链接分配的稳定性较差，系统在运行过程中由于软件或者硬件错误导致链表中的指针丢失或损坏，会导致文件数据的丢失。
      • 如果取出每个磁盘块的指针，把它放在内存的一个表中，就可以解决上述隐式链表的两个不足。那么，这种实现方式是「显式链接」，它指把用于链接文件各数据块的指针，显式地存放在内存的一张链接表中，该表在整个磁盘仅设置一张，每个表项中存放链接指针，指向下一个数据块号。
        由于查找记录的过程是在内存中进行的，因而不仅显著地提高了检索速度，而且大大减少了访问磁盘的次数。但也正是整个表都存放在内存中的关系，它的主要的缺点是不适用于大磁盘。

链表的方式解决了连续分配的磁盘碎片和文件动态扩展的问题，但是不能有效支持直接访问（FAT除外），索引的方式可以解决这个问题。
索引的实现是为每个文件创建一个「索引数据块」，里面存放的是指向文件数据块的指针列表，说白了就像书的目录一样，要找哪个章节的内容，看目录查就可以。
另外，文件头需要包含指向「索引数据块」的指针，这样就可以通过文件头知道索引数据块的位置，再通过索引数据块里的索引信息找到对应的数据块。
创建文件时，索引块的所有指针都设为空。当首次写入第 i 块时，先从空闲空间中取得一个块，再将其地址写到索引块的第 i 个条目。
链表 + 索引的组合，这种组合称为「链式索引块」，它的实现方式是在索引数据块留出一个存放下一个索引数据块的指针，于是当一个索引数据块的索引信息用完了，就可以通过指针的方式，找到下一个索引数据块的信息。那这种方式也会出现前面提到的链表方式的问题，万一某个指针损坏了，后面的数据也就会无法读取了。
还有另外一种组合方式是索引 + 索引的方式，这种组合称为「多级索引块」，实现方式是通过一个索引块来存放多个索引数据块，一层套一层索引。

早期 Unix 文件系统是组合了前面的文件存放方式的优点

它是根据文件的大小，存放的方式会有所变化：

  • 如果存放文件所需的数据块小于 10 块，则采用直接查找的方式；
  • 如果存放文件所需的数据块超过 10 块，则采用一级间接索引方式；
  • 如果前面两种方式都不够存放大文件，则采用二级间接索引方式；
  • 如果二级间接索引也不够存放大文件，这采用三级间接索引方式；

那么，文件头（Inode）就需要包含 13 个指针：

  • 10 个指向数据块的指针；
  • 第 11 个指向索引块的指针；
  • 第 12 个指向二级索引块的指针；
  • 第 13 个指向三级索引块的指针；

所以，这种方式能很灵活地支持小文件和大文件的存放：

  • 对于小文件使用直接查找的方式可减少索引数据块的开销；
  • 对于大文件则以多级索引的方式来支持，所以大文件在访问数据块时需要大量查询；
  • 空闲空间管理
    针对磁盘的空闲空间也是要引入管理的机制，接下来介绍几种常见的方法：
    空闲表法、空闲链表法、位图法。
    空闲表法就是为所有空闲空间建立一张表，表内容包括空闲区的第一个块号和该空闲区的块个数，注意，这个方式是连续分配的。当请求分配磁盘空间时，系统依次扫描空闲表里的内容，直到找到一个合适的空闲区域为止。当用户撤销一个文件时，系统回收文件空间。这时，也需顺序扫描空闲表，寻找一个空闲表条目并将释放空间的第一个物理块号及它占用的块数填到这个条目中。
    • 如果存储空间中有着大量的小的空闲区，则空闲表变得很大，这样查询效率会很低。另外，这种分配技术适用于建立连续文件。

空闲链表法，就是每一个空闲块里有一个指针指向下一个空闲块，这样也能很方便的找到空闲块并管理起来。当创建文件需要一块或几块时，就从链头上依次取下一块或几块。反之，当回收空间时，把这些空闲块依次接到链头上。

  • 其特点是简单，但不能随机访问，工作效率低，因为每当在链上增加或移动空闲块时需要做很多 I/O 操作，同时数据块的指针消耗了一定的存储空间。空闲表法和空闲链表法都不适合用于大型文件系统，因为这会使空闲表或空闲链表太大。

位图法，就是利用二进制的一位来表示磁盘中一个盘块的使用情况，磁盘上所有的盘块都有一个二进制位与之对应。当值为 0 时，表示对应的盘块空闲，值为 1 时，表示对应的盘块已分配。

  • 文件系统的结构
    前面提到 Linux 是用位图的方式管理空闲空间，用户在创建一个新文件时，Linux 内核会通过 inode 的位图找到空闲可用的 inode，并进行分配。要存储数据时，会通过块的位图找到空闲的块，并分配。
    采用「一个块的位图 + 一系列的块」，外加「一个块的 inode 的位图 + 一系列的 inode 的结构」，在 Linux 文件系统，把这个结构称为一个块组，那么有 N 多的块组，就能够表示 N 大的文件。
    下图给出了 Linux Ext2 整个文件系统的结构和块组的内容，文件系统都由大量块组组成，在硬盘上相继排布：


最前面的第一个块是引导块，在系统启动时用于启用引导，接着后面就是一个一个连续的块组了，块组的内容如下：

  • 超级块，包含的是文件系统的重要信息，比如 inode 总个数、块总个数、每个块组的 inode 个数、每个块组的块个数等等。
  • 块组描述符，包含文件系统中各个块组的状态，比如块组中空闲块和 inode 的数目等，每个块组都包含了文件系统中「所有块组的组描述符信息」。
  • 数据位图和 inode 位图， 用于表示对应的数据块或 inode 是空闲的，还是被使用中。
  • inode 列表，包含了块组中所有的 inode，inode 用于保存文件系统中与各个文件和目录相关的所有元数据。
  • 数据块，包含文件的有用数据。

超级块和块组描述符表，这两个都是全局信息，而且非常的重要，这么做是有两个原因：

  • 如果系统崩溃破坏了超级块或块组描述符，有关文件系统结构和内容的所有信息都会丢失。如果有冗余的副本，该信息是可能恢复的。
  • 通过使文件和管理数据尽可能接近，减少了磁头寻道和旋转，这可以提高文件系统的性能。
  • 目录的存储
    和普通文件不同的是，普通文件的块里面保存的是文件数据，而目录文件的块里面保存的是目录里面一项一项的文件信息。
    在目录文件的块中，最简单的保存格式就是列表，就是一项一项地将目录下的文件信息（如文件名、文件 inode、文件类型等）列在表里。列表中每一项就代表该目录下的文件的文件名和对应的 inode，通过这个 inode，就可以找到真正的文件。


如果一个目录有超级多的文件，我们要想在这个目录下找文件，按照列表一项一项的找，效率就不高了。
于是，保存目录的格式改成哈希表，对文件名进行哈希计算，把哈希值保存起来，如果我们要查找一个目录下面的文件名，可以通过名称取哈希。如果哈希能够匹配上，就说明这个文件的信息在相应的块里面。
目录查询是通过在磁盘上反复搜索完成，需要不断地进行 I/O 操作，开销较大。所以，为了减少 I/O 操作，把当前使用的文件目录缓存在内存，以后要使用该文件时只要在内存中操作，从而降低了磁盘操作次数，提高了文件系统的访问速度。

  • 软链接和硬链接
    有时候我们希望给某个文件取个别名，那么在 Linux 中可以通过硬链接（Hard Link） 和软链接（Symbolic Link） 的方式来实现，它们都是比较特殊的文件，但是实现方式也是不相同的。
    硬链接是多个目录项中的「索引节点」指向一个文件，也就是指向同一个 inode，但是 inode 是不可能跨越文件系统的，每个文件系统都有各自的 inode 数据结构和列表，所以硬链接是不可用于跨文件系统的。由于多个目录项都是指向一个 inode，那么只有删除文件的所有硬链接以及源文件时，系统才会彻底删除该文件。
    软链接相当于重新创建一个文件，这个文件有独立的 inode，但是这个文件的内容是另外一个文件的路径，类似于快捷方式。所以访问软链接的时候，实际上相当于访问到了另外一个文件，所以软链接是可以跨文件系统的，甚至目标文件被删除了，链接文件还是在的，只不过指向的文件找不到了而已。
  • 文件I/O
    文件操作的标准库是可以实现数据的缓存，那么根据「是否利用标准库缓冲」，可以把文件 I/O 分为缓冲 I/O 和非缓冲 I/O：
    • 缓冲 I/O，利用的是标准库的缓存实现文件的加速访问，而标准库再通过系统调用访问文件。
    • 非缓冲 I/O，直接通过系统调用访问文件，不经过标准库缓存。
      这里所说的「缓冲」特指标准库内部实现的缓冲。
      比方说，很多程序遇到换行时才真正输出，而换行前的内容，其实就是被标准库暂时缓存了起来，这样做的目的是，减少系统调用的次数，毕竟系统调用是有 CPU 上下文切换的开销的。

根据是「否利用操作系统的缓存」，可以把文件 I/O 分为直接 I/O 与非直接 I/O：

  • 直接 I/O，不会发生内核缓存和用户程序之间数据复制，而是直接经过文件系统访问磁盘。
  • 非直接 I/O，读操作时，数据从内核缓存中拷贝给用户程序，写操作时，数据从用户程序拷贝给内核缓存，再由内核决定什么时候写入数据到磁盘。

阻塞I/O，当用户程序执行 read ，线程会被阻塞，一直等到内核数据准备好，并把数据从内核缓冲区拷贝到应用程序的缓冲区中，当拷贝过程完成，read 才会返回。阻塞等待的是「内核数据准备好」和「数据从内核态拷贝到用户态」这两个过程。
非阻塞 I/O，非阻塞的 read 请求在数据未准备好的情况下立即返回，可以继续往下执行，此时应用程序不断轮询内核，直到数据准备好，内核将数据拷贝到应用程序缓冲区，read 调用才可以获取到结果。**这里最后一次 read 调用，获取数据的过程，是一个同步的过程，是需要等待的过程。这里的同步指的是内核态的数据拷贝到用户程序的缓存区这个过程。**为了解决这种轮询方式，于是I/O多路复用技术就出来了，如 select、poll，它是通过 I/O 事件分发，当内核数据准备好时，再以事件通知应用程序进行操作。这个做法大大改善了 CPU 的利用率，因为当调用了 I/O 多路复用接口，如果没有事件发生，那么当前线程就会发生阻塞，这时 CPU 会切换其他线程执行任务，等内核发现有事件到来的时候，会唤醒阻塞在 I/O 多路复用接口的线程，然后用户可以进行后续的事件处理。

  • 整个流程要比阻塞 IO 要复杂，似乎也更浪费性能。但 I/O 多路复用接口最大的优势在于，用户可以在一个线程内同时处理多个 socket 的 IO 请求。用户可以注册多个 socket，然后不断地调用 I/O 多路复用接口读取被激活的 socket，即可达到在同一个线程内同时处理多个 IO 请求的目的。而在同步阻塞模型中，必须通过多线程的方式才能达到这个目的。

实际上，无论是阻塞 I/O、非阻塞 I/O，还是基于非阻塞 I/O 的多路复用都是同步调用。因为它们在 read 调用时，内核将数据从内核空间拷贝到应用程序空间，过程都是需要等待的，也就是说这个过程是同步的，如果内核实现的拷贝效率不高，read 调用就会在这个同步过程中等待比较长的时间。而真正的异步 I/O 是「内核数据准备好」和「数据从内核态拷贝到用户态」这两个过程都不用等待。

  • 当我们发起 aio_read 之后，就立即返回，内核自动将数据从内核空间拷贝到应用程序空间，这个拷贝过程同样是异步的，内核自动完成的，和前面的同步操作不一样，应用程序并不需要主动发起拷贝动作。

在前面我们知道了，I/O 是分为两个过程的：

  1. 数据准备的过程
  2. 数据从内核空间拷贝到用户进程缓冲区的过程

阻塞 I/O 会阻塞在「过程 1 」和「过程 2」，而非阻塞 I/O 和基于非阻塞 I/O 的多路复用只会阻塞在「过程 2」，所以这三个都可以认为是同步 I/O。
异步 I/O 则不同，「过程 1 」和「过程 2 」都不会阻塞。

进程写文件时，进程发生崩溃，已写入的数据会丢失吗？

进程在执行 write （使用缓冲 IO）系统调用的时候，实际上是将文件数据写到了内核的 page cache，它是文件系统中用于缓存文件数据的缓冲，所以即使进程崩溃了，文件数据还是保留在内核的 page cache，我们读数据的时候，也是从内核的 page cache 读取，因此还是依然读的进程崩溃前写入的数据。

内核会找个合适的时机，将 page cache 中的数据持久化到磁盘。但是如果 page cache 里的文件数据，在持久化到磁盘化到磁盘之前，系统发生了崩溃，那这部分数据就会丢失了。

当然， 我们也可以在程序里调用 fsync 函数，在写文文件的时候，立刻将文件数据持久化到磁盘，这样就可以解决系统崩溃导致的文件数据丢失的问题。

  • Page Cache
    Page Cache 的本质是由 Linux 内核管理的内存区域。我们通过 mmap 以及 buffered I/O 将文件读取到内存空间实际上都是读取到 Page Cache 中。
    page 是内存管理分配的基本单位， Page Cache 由多个 page 构成。page 在操作系统中通常为 4KB 大小（32bits/64bits），而 Page Cache 的大小则为 4KB 的整数倍。
    另一方面，并不是所有 page 都被组织为 Page Cache。
    Linux 系统上供用户可访问的内存分为两个类型，即：
    • File-backed pages：文件备份页也就是 Page Cache 中的 page，对应于磁盘上的若干数据块；对于这些页最大的问题是脏页回盘；
    • Anonymous pages：匿名页不对应磁盘上的任何磁盘数据块，它们是进程的运行是内存空间（例如方法栈、局部变量表等属性）；
  • Swap与缺页中断
    Swap 机制指的是当物理内存不够用，内存管理单元（Memory Mangament Unit，MMU）需要提供调度算法来回收相关内存空间，然后将清理出来的内存空间给当前内存申请方。
    Swap 机制存在的本质原因是 Linux 系统提供了虚拟内存管理机制，每一个进程认为其独占内存空间，因此所有进程的内存空间之和远远大于物理内存。所有进程的内存空间之和超过物理内存的部分就需要交换到磁盘上。
    操作系统以 page 为单位管理内存，当进程发现需要访问的数据不在内存时，操作系统可能会将数据以页的方式加载到内存中。上述过程被称为缺页中断，当操作系统发生缺页中断时，就会通过系统调用将 page 再次读到内存中。
    但主内存的空间是有限的，当主内存中不包含可以使用的空间时，操作系统会从选择合适的物理内存页驱逐回磁盘，为新的内存页让出位置，选择待驱逐页的过程在操作系统中叫做页面替换（Page Replacement），替换操作又会触发 swap 机制。
  • Page Cache 与 buffer cache
    Page Cache 用于缓存文件的页数据，buffer cache 用于缓存块设备（如磁盘）的块数据。
    • 页是逻辑上的概念，因此 Page Cache 是与文件系统同级的；
    • 块是物理上的概念，因此 buffer cache 是与块设备驱动程序同级的。

Page Cache 与 buffer cache 的共同目的都是加速数据 I/O：

  • 写数据时首先写到缓存，将写入的页标记为 dirty，然后向外部存储 flush，也就是缓存写机制中的 write-back（另一种是 write-through，Linux 默认情况下不采用）；
  • 读数据时首先读取缓存，如果未命中，再去外部存储读取，并且将读取来的数据也加入缓存。操作系统总是积极地将所有空闲内存都用作 Page Cache 和 buffer cache，当内存不够用时也会用 LRU 等算法淘汰缓存页。、

在 2.4 版本内核之后，两块缓存近似融合在了一起：如果一个文件的页加载到了 Page Cache，那么同时 buffer cache 只需要维护块指向页的指针就可以了。只有那些没有文件表示的块，或者绕过了文件系统直接操作（如dd命令）的块，才会真正放到 buffer cache 里。

  • Page Cache 与预读
    操作系统为基于 Page Cache 的读缓存机制提供预读机制（PAGE_READAHEAD），一个例子是：
    • 用户线程仅仅请求读取磁盘上文件 A 的 offset 为 0-3KB 范围内的数据，由于磁盘的基本读写单位为 block（4KB），于是操作系统至少会读 0-4KB 的内容，这恰好可以在一个 page 中装下。
    • 但是操作系统出于局部性原理会选择将磁盘块 offset [4KB,8KB)、[8KB,12KB) 以及 [12KB,16KB) 都加载到内存，于是额外在内存中申请了 3 个 page；
  • Page Cache 与文件持久化的一致性&可靠性
    现代 Linux 的 Page Cache 正如其名，是对磁盘上 page（页）的内存缓存，同时可以用于读/写操作。
    任何系统引入缓存，就会引发一致性问题：内存中的数据与磁盘中的数据不一致，例如常见后端架构中的 Redis 缓存与 MySQL 数据库就存在一致性问题。
  • Page Cache 的优劣势
    优势：
    1.加快数据访问
    如果数据能够在内存中进行缓存，那么下一次访问就不需要通过磁盘 I/O 了，直接命中内存缓存即可。
    由于内存访问比磁盘访问快很多，因此加快数据访问是 Page Cache 的一大优势。
    2.减少 I/O 次数，提高系统磁盘 I/O 吞吐量
    得益于 Page Cache 的缓存以及预读能力，而程序又往往符合局部性原理，因此通过一次 I/O 将多个 page 装入 Page Cache 能够减少磁盘 I/O 次数， 进而提高系统磁盘 I/O 吞吐量。
    劣势：
    最直接的缺点是需要占用额外物理内存空间，物理内存在比较紧俏的时候可能会导致频繁的 swap 操作，最终导致系统的磁盘 I/O 负载的上升。
    Page Cache 的另一个缺陷是对应用层并没有提供很好的管理 API，几乎是透明管理。应用层即使想优化 Page Cache 的使用策略也很难进行。因此一些应用选择在用户空间实现自己的 page 管理，而不使用 page cache，例如 MySQL InnoDB 存储引擎以 16KB 的页进行管理。
    Page Cache 最后一个缺陷是在某些应用场景下比 Direct I/O（直接I/O） 多一次磁盘读 I/O 以及磁盘写 I/O。

设备管理

键盘敲入A字母时，操作系统期间发生了什么？

为了屏蔽各种设备之间的差异，每个设备都有一个叫设备控制器（Device Control） 的组件，比如硬盘有硬盘控制器、显示器有视频控制器等。

因为这些控制器都很清楚的知道对应设备的用法和功能，所以 CPU 是通过设备控制器来和设备打交道的。

设备控制器里有芯片，它可执行自己的逻辑，也有自己的寄存器，用来与 CPU 进行通信，比如：

  • 通过写入这些寄存器，操作系统可以命令设备发送数据、接收数据、开启或关闭，或者执行某些其他操作。
  • 通过读取这些寄存器，操作系统可以了解设备的状态，是否准备好接收一个新的命令等。

有三类寄存器，它们分别是状态寄存器（Status Register）、 命令寄存器（Command Register）以及数据寄存器（Data Register）

  • 数据寄存器，CPU 向 I/O 设备写入需要传输的数据，比如要打印的内容是「Hello」，CPU 就要先发送一个 H 字符给到对应的 I/O 设备。
  • 命令寄存器，CPU 发送一个命令，告诉 I/O 设备，要进行输入/输出操作，于是就会交给 I/O 设备去工作，任务完成后，会把状态寄存器里面的状态标记为完成。
  • 状态寄存器，目的是告诉 CPU ，现在已经在工作或工作已经完成，如果已经在工作状态，CPU 再发送数据或者命令过来，都是没有用的，直到前面的工作已经完成，状态寄存标记成已完成，CPU 才能发送下一个字符和命令。

CPU通过读写设备控制器中的寄存器来控制设备，比直接控制输入输出设备要方便很多。

输入输出设备可分为两大类 ：块设备（Block Device）和字符设备（Character Device）。

  • 块设备，把数据存储在固定大小的块中，每个块有自己的地址，硬盘、USB 是常见的块设备。
    • 块设备通常传输的数据量会非常大，于是控制器设立了一个可读写的数据缓冲区。可以减少对设备的频繁操作。
      • CPU 写入数据到控制器的缓冲区时，当缓冲区的数据囤够了一部分，才会发给设备。
      • CPU 从控制器的缓冲区读取数据时，也需要缓冲区囤够了一部分，才拷贝到内存。
  • 字符设备，以字符为单位发送或接收一个字符流，字符设备是不可寻址的，也没有任何寻道操作，鼠标是常见的字符设备。

那 CPU 是如何与设备的控制寄存器和数据缓冲区进行通信的？存在两个方法：

  • 端口 I/O，每个控制寄存器被分配一个 I/O 端口，可以通过特殊的汇编指令操作这些寄存器，比如 in/out 类似的指令。
  • 内存映射 I/O，将所有控制寄存器映射到内存空间中，这样就可以像读写内存一样读写数据缓冲区。

当CPU给设备发送一个指令，设备控制器取读设备的数据，读完的时候，要怎么通知CPU呢？

  • 方法一：轮询等待的方法，让 CPU 一直查寄存器的状态，直到状态标记为完成，很明显，这种方式非常的傻瓜，它会占用 CPU 的全部时间。
  • 方法二： 中断，通知操作系统数据已经准备好了。我们一般会有一个硬件的中断控制器，当设备完成任务后触发中断到中断控制器，中断控制器就通知 CPU，一个中断产生了，CPU 需要停下当前手里的事情来处理中断。
    • 另外，中断有两种，一种软中断，例如代码调用 INT 指令触发，一种是硬件中断，就是硬件通过中断控制器触发的。
    • 但中断的方式对于频繁读写数据的磁盘，并不友好，这样 CPU 容易经常被打断，会占用 CPU 大量的时间。

对于这一类设备的问题的解决方法是使用 DMA（Direct Memory Access） 功能，它可以使得设备在 CPU 不参与的情况下，能够自行完成把设备 I/O 数据放入到内存。那要实现 DMA 功能要有 「DMA 控制器」硬件的支持。

DMA 的工作方式如下：

  • CPU 需对 DMA 控制器下发指令，告诉它想读取多少数据，读完的数据放在内存的某个地方就可以了；
  • 接下来，DMA 控制器会向磁盘控制器发出指令，通知它从磁盘读数据到其内部的缓冲区中，接着磁盘控制器将缓冲区的数据传输到内存；
  • 当磁盘控制器把数据传输到内存的操作完成后，磁盘控制器在总线上发出一个确认成功的信号到 DMA 控制器；
  • DMA 控制器收到信号后，DMA 控制器发中断通知 CPU 指令完成，CPU 就可以直接用内存里面现成的数据了；

设备驱动程序

每个设备控制器使用的模式可能都是不同的，为了屏蔽「设备控制器」的差异，引入了设备驱动程序。

设备控制器不属于操作系统范畴，它是属于硬件，而设备驱动程序属于操作系统的一部分，操作系统的内核代码可以像本地调用代码一样使用设备驱动程序的接口，而设备驱动程序是面向设备控制器的代码，它发出操控设备控制器的指令后，才可以操作设备控制器。

不同的设备控制器虽然功能不同，但是设备驱动程序会提供统一的接口给操作系统，这样不同的设备驱动程序，就可以以相同的方式接入操作系统。

通常，设备驱动程序初始化的时候，要先注册一个该设备的中断处理函数。

我们来看看，中断处理程序的处理流程：

  1. 在 I/O 时，设备控制器如果已经准备好数据，则会通过中断控制器向 CPU 发送中断请求；
  2. 保护被中断进程的 CPU 上下文；
  3. 转入相应的设备中断处理函数；
  4. 进行中断处理；
  5. 恢复被中断进程的上下文；

通用块层

对于块设备，为了减少不同块设备的差异带来的影响，Linux 通过一个统一的通用块层，来管理不同的块设备。

通用块层是处于文件系统和磁盘驱动中间的一个块设备抽象层，它主要有两个功能：

  • 第一个功能，向上为文件系统和应用程序，提供访问块设备的标准接口，向下把各种不同的磁盘设备抽象为统一的块设备，并在内核层面，提供一个框架来管理这些设备的驱动程序；
  • 第二功能，通用层还会给文件系统和应用程序发来的 I/O 请求排队，接着会对队列重新排序、请求合并等方式，也就是 I/O 调度，主要目的是为了提高磁盘读写的效率。

Linux存储系统的I/O软件分层

可以把 Linux 存储系统的 I/O 由上到下可以分为三个层次，分别是文件系统层、通用块层、设备层。

这三个层次的作用是：

  • 文件系统层，包括虚拟文件系统和其他文件系统的具体实现，它向上为应用程序统一提供了标准的文件访问接口，向下会通过通用块层来存储和管理磁盘数据。
  • 通用块层，包括块设备的 I/O 队列和 I/O 调度器，它会对文件系统的 I/O 请求进行排队，再通过 I/O 调度器，选择一个 I/O 发给下一层的设备层。
  • 设备层，包括硬件设备、设备控制器和驱动程序，负责最终物理设备的 I/O 操作。

另外，存储系统的 I/O 是整个系统最慢的一个环节，所以 Linux 提供了不少缓存机制来提高 I/O 的效率。

  • 为了提高文件访问的效率，会使用页缓存、索引节点缓存、目录项缓存等多种缓存机制，目的是为了减少对块设备的直接调用。
  • 为了提高块设备的访问效率， 会使用缓冲区，来缓存块设备的数据。

键盘敲入字母，发生了什么？

CPU 里面的内存接口，直接和系统总线通信，然后系统总线再接入一个 I/O 桥接器，这个 I/O 桥接器，另一边接入了内存总线，使得 CPU 和内存通信。再另一边，又接入了一个 I/O 总线，用来连接 I/O 设备，比如键盘、显示器等。

那当用户输入了键盘字符，键盘控制器就会产生扫描码数据，并将其缓冲在键盘控制器的寄存器中，紧接着键盘控制器通过总线给 CPU 发送中断请求。

CPU 收到中断请求后，操作系统会保存被中断进程的 CPU 上下文，然后调用键盘的中断处理程序。

键盘的中断处理程序是在键盘驱动程序初始化时注册的，那键盘中断处理函数的功能就是从键盘控制器的寄存器的缓冲区读取扫描码，再根据扫描码找到用户在键盘输入的字符，如果输入的字符是显示字符，那就会把扫描码翻译成对应显示字符的 ASCII 码，比如用户在键盘输入的是字母 A，是显示字符，于是就会把扫描码翻译成 A 字符的 ASCII 码。

得到了显示字符的 ASCII 码后，就会把 ASCII 码放到「读缓冲区队列」，接下来就是要把显示字符显示屏幕了，显示设备的驱动程序会定时从「读缓冲区队列」读取数据放到「写缓冲区队列」，最后把「写缓冲区队列」的数据一个一个写入到显示设备的控制器的寄存器中的数据缓冲区，最后将这些数据显示在屏幕里。

显示出结果后，恢复被中断进程的上下文。

网络系统

什么是零拷贝？

磁盘可以说是计算机系统最慢的硬件之一，读写速度相差内存 10 倍以上，所以针对优化磁盘的技术非常的多，比如零拷贝、直接 I/O、异步 I/O 等等，这些优化的目的就是为了提高系统的吞吐量，另外操作系统内核中的磁盘高速缓存区，可以有效的减少磁盘的访问次数。
使用DMA技术，在进行I/O设备与内存的数据传输时，数据搬运的工作交给DMA控制器，而CPU不再参与数据搬运相关的事情，这样CPU可以处理别的事务。
使用DMA技术的具体执行流程：

  • 用户进程调用 read 方法，向操作系统发出 I/O 请求，请求读取数据到自己的内存缓冲区/用户空间中，进程进入阻塞状态；
    • 用户缓存区：用户缓冲区的目的是为了减少系统调用次数，从而降低操作系统在用户态与核心态切换所耗费的时间。
      一些程序在读取文件时，会先申请一块内存数组，称为buffer，然后每次调用read，读取设定字节长度的数据，写入buffer。（用较小的次数填满buffer）。之后的程序都是从buffer中获取数据，当buffer使用完后，在进行下一次调用，填充buffer。【缓冲区就可以理解为内存数组，在当前进程中开辟一段虚拟内存空间，并且映射到物理内存中，实际上存储在物理内存中】
  • 操作系统收到请求后，进一步将 I/O 请求发送 DMA，然后让 CPU 执行其他任务；
  • DMA 进一步将 I/O 请求发送给磁盘；
  • 磁盘收到 DMA 的 I/O 请求，把数据从磁盘读取到磁盘控制器的缓冲区中，当磁盘控制器的缓冲区被读满后，向 DMA 发起中断信号，告知自己缓冲区已满；
  • DMA 收到磁盘的信号，将磁盘控制器缓冲区中的数据拷贝到内核缓冲区中，此时不占用 CPU，CPU 可以执行其他任务；
  • 当 DMA 读取了足够多的数据，就会发送中断信号给 CPU；
  • CPU 收到 DMA 的信号，知道数据已经准备好，于是将数据从内核拷贝到用户空间，系统调用返回；
  • 传统的文件传输有多糟糕？
    如果服务端要提供文件传输的功能，我们能想到的最简单的方式是：将磁盘上的文件读取出来，然后通过网络协议发送给客户端。传统 I/O 的工作方式是，数据读取和写入是从用户空间到内核空间来回复制，而内核空间的数据是通过操作系统层面的 I/O 接口从磁盘读取或写入。
read(file, tmp_buf, len);
write(socket, tmp_buf, len);


首先，期间发生了 4 次用户态和内核态的上下文切换，每次read()和write()都要从用户态切换到内核态，等内核态完成任务后，再从内核态切换到用户态。上下文切换到成本并不小，在高并发的场景下，这类时间容易被累积和放大，影响系统性能。
其次，期间还发生了 4 次数据拷贝，两次是DMA的拷贝，两次是CPU的拷贝。

  • 第一次拷贝，磁盘文件—>内核缓存区，这个拷贝的过程是通过 DMA 搬运的。
  • 第二次拷贝，内核缓存区—>用户缓存区，于是我们应用程序就可以使用这部分数据了，这个拷贝到过程是由 CPU 完成的。
  • 第三次拷贝，用户缓存区—>socket缓存区，这个过程依然还是由 CPU 搬运的。
  • 第四次拷贝，socket缓存区—>网卡的缓冲区，这个过程又是由 DMA 搬运的。

所以，要想提高文件传输的性能，就需要减少「用户态与内核态的上下文切换」和「内存拷贝」的次数。

  • 如何优化文件传输性能？
    减少用户态和内核态的上下文切换次数：减少系统调用的次数。
    • 一次系统调用，必然会发生 2 次上下文切换：首先从用户态切换到内核态，当内核执行完任务后，再切换回用户态交由进程代码执行。

减少数据拷贝的次数：用户的缓冲区是没有必要存在。

  • 因为文件传输的应用场景中，在用户空间我们并不会对数据「再加工」，所以数据实际上可以不用搬运到用户空间。
  • 如何实现零拷贝？
    零拷贝技术实现的方式通常有 2 种：mmap + write、sendfile
    mmap + write
    在前面我们知道，read() 系统调用的过程中会把内核缓冲区的数据拷贝到用户的缓冲区里，于是为了减少这一步开销，我们可以用 mmap() 替换 read() 系统调用函数。
    mmap() 系统调用函数会直接把内核缓冲区里的数据「映射」到用户空间，应用进程与操作系统内核共享这个缓冲区。这样，操作系统内核与用户空间就不需要再进行任何的数据拷贝操作。
    但这还不是最理想的零拷贝，只是减少了一次数据拷贝的过程，但仍然需要通过 CPU 把内核缓冲区的数据拷贝到 socket 缓冲区里，而且仍然需要 4 次上下文切换，因为系统调用还是 2 次。
    sendfile
    Linux内核版本 2.1 中，提供了一个专门发送文件的系统调用函数 sendfile()。
#include <sys/socket.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);


它的前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度。
首先，它可以替代前面的 read() 和 write() 这两个系统调用，这样就可以减少一次系统调用，也就减少了 2 次上下文切换的开销。
其次，该系统调用，可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里，不再拷贝到用户态，这样就只有 2 次上下文切换，和 3 次数据拷贝。
但是这还不是真正的零拷贝技术，如果网卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技术（和普通的 DMA 有所不同），我们可以进一步减少通过 CPU 把内核缓冲区里的数据拷贝到 socket 缓冲区的过程。
于是，从 Linux 内核 2.4 版本开始起，对于支持网卡支持 SG-DMA 技术的情况下， sendfile() 系统调用的过程发生了点变化，具体过程如下：

  • 第一步，通过 DMA 将磁盘上的数据拷贝到内核缓冲区里；
  • 第二步，缓冲区描述符和数据长度传到 socket 缓冲区，这样网卡的 SG-DMA 控制器就可以直接将内核缓存中的数据拷贝到网卡的缓冲区里，此过程不需要将数据从操作系统内核缓冲区拷贝到 socket 缓冲区中，这样就减少了一次数据拷贝；

这就是所谓的零拷贝（Zero-copy）技术，因为我们没有在内存层面去拷贝数据，也就是说全程没有通过 CPU 来搬运数据，所有的数据都是通过 DMA 来进行传输的。。
零拷贝技术的文件传输方式相比传统文件传输的方式，减少了 2 次上下文切换和数据拷贝次数，**只需要 2 次上下文切换和数据拷贝次数，就可以完成文件的传输，而且 2 次的数据拷贝过程，都不需要通过 CPU，2 次都是由 DMA 来搬运。**所以，总体来看，零拷贝技术可以把文件传输的性能提高至少一倍以上。
Kafufa、Nginx都使用了零拷贝技术。

  • PageCache 有什么用？
    上文提到的内核缓冲区，实际就是磁盘高速缓存（PageCache）。零拷贝就使用了Page Cache技术。通过 DMA 把磁盘里的数据搬运到内存里，这样就可以用读内存替换读磁盘。
    根据局部性原理，我们可以用PageCache缓存最近被访问的数据，并且使用预读功能，提高磁盘的性能。
    但是，在传输大文件（GB级别）的时候，PageCache不会起作用，就浪费了DMA多做的一次数据拷贝，此时，即使使用PageCache零拷贝，也会损失性能。
    • 这是因为如果你有很多 GB 级别文件需要传输，每当用户访问这些大文件的时候，内核就会把它们载入 PageCache 中，于是 PageCache 空间很快被这些大文件占满。但是可能占满的部分不会被经常访问

所以，针对大文件的传输，不应该使用PageCache零拷贝技术。

  • 大文件传输用什么方式实现？
    在高并发的场景下，针对大文件的传输的方式，应该使用「异步 I/O + 直接 I/O」来替代零拷贝技术。
    异步I/O把读操作分为两部分：
    • 前半部分，内核向磁盘发起读请求，但是可以不等待数据就位就可以返回，于是进程此时可以处理其他任务；
    • 后半部分，当内核将磁盘中的数据拷贝到进程缓冲区后，进程将接收到内核的通知，再去处理数据；

大文件的传输不应该使用PageCache，绕过PageCache的I/O叫直接I/O。通常对于磁盘，异步I/O只支持直接I/O。
直接I/O的应用场景有两种：

  1. 应用程序已经实现了磁盘数据的缓存。比如MySQL中可以开启直接I/O。
  2. 传输大文件时。

但是，由于直接I/O绕开了PageCache，也无法享受内核的优化：

  1. 内核I/O的调度算法会缓存尽可能多的I/O请求在PageCache中，最终合并更大的I/O请求再发给磁盘。
  2. 内核也会预读I/O请求，减少磁盘操作次数。
    - 内核的预读关键在于预测能力，可以对顺序读进行预读，保证高命中率。

I/O多路复用：select/poll/epoll

  • 最基本的Socket模型
    要建立网络连接，服务器的程序要先跑起来，等待客户端的连接和数据。需要一个Socket，才可以实现跨主机之间的通信。Socket的本质是对TCP/IP的封装。服务器端的Socket编程过程如下：
    服务器先调用socket()函数，创建网络协议IPv4，传输协议为TCP的Socket。调用bind()函数，给Socket绑定IP地址和端口。
    • IP地址：识别网络上的设备。
    • 端口号：表示TCP协议应该把报文发送给哪个应用程序。

之后调用listen()函数进行监听，如果要判断服务器中一个网络程序有没有启动，可以通过netstat 命令查看对应端口号是否被监听。
服务端进入了监听状态后，通过调用 accept() 函数，来从内核获取客户端的连接，如果没有客户端连接，则会阻塞等待客户端连接的到来。
回到客户端，客户端在创建好Socket后，调用connect()函数发起连接，指明服务器端IP地址和端口号，随后进行TCP三次握手。
在 TCP 连接的过程中，服务器的内核实际上为每个 Socket 维护了两个队列：

  • 一个是「还没完全建立」连接的队列，称为 TCP 半连接队列，这个队列都是没有完成三次握手的连接，此时服务端处于 syn_rcvd 的状态；
  • 一个是「已经建立」连接的队列，称为 TCP 全连接队列，这个队列都是完成了三次握手的连接，此时服务端处于 established 状态；

当TCP全连接队列不为空，服务器端使用accept()函数，从内核中的TCP全连接队列中拿出已经完成连接的Socket返回应用程序，后序使用这个Socket传输数据。
建立连接后，客户端和服务端就开始相互传输数据了，双方都可以通过 read() 和 write() 函数来读写数据。

在内核中，Socket是以文件的形式存在的，也有对应的文件描述符。

  • C10K
    TCP 连接是四元组唯一确认的：本机IP、本机端口、对端IP、对端端口。
    服务器作为服务方，通常会在本地固定监听一个端口，等待客户端的连接。因此服务器的本地 IP 和端口是固定的，于是对于服务端 TCP 连接的四元组只有对端 IP 和端口是会变化的，所以最大 TCP 连接数 = 客户端 IP 数×客户端端口数。
    对于 IPv4，客户端的 IP 数最多为 2 的 32 次方，客户端的端口数最多为 2 的 16 次方，也就是服务端单机最大 TCP 连接数约为 2 的 48 次方。
    但是实际上，服务器无法承载那么大的连接数，主要受两个方面的限制：
    • 文件描述符：Socket 实际上是一个文件，也就会对应一个文件描述符。在 Linux 下，单个进程打开的文件描述符数是有限制的，没有经过修改的值一般都是 1024。
    • 系统内存：每个 TCP 连接在内核中都有对应的数据结构，意味着每个连接都是会占用一定内存的；

服务器的内存只有 2 GB，网卡是千兆的，能支持并发 1 万请求吗？
并发 1 万请求，也就是经典的 C10K 问题 ，C 是 Client 单词首字母缩写，C10K 就是单机同时处理 1 万个请求的问题。
从硬件资源角度看，对于 2GB 内存千兆网卡的服务器，如果每个请求处理占用不到 200KB 的内存和 100Kbit 的网络带宽就可以满足并发 1 万个请求。
不过，要想真正实现 C10K 的服务器，要考虑的地方在于服务器的网络 I/O 模型，效率低的模型，会加重系统开销，从而会离 C10K 的目标越来越远。

  • 如何服务更多的用户？
    TCP Socket使用的是最简单、基本的一对一通信方式。因为使用的是同步阻塞的方式，当服务端还没处理完一个客户端的网络 I/O 时，不会有其他连接占用。
    如果要支持多个客户端，可以使用多进程模型，为每个客户端分配一个进程来处理请求。也就是一旦与客户端连接完成，accept() 函数就会返回一个「已连接 Socket」，这时就通过 fork() 函数创建一个子进程，实际上就把父进程所有相关的东西都复制一份，包括文件描述符、内存地址空间、程序计数器、执行的代码等。
    但是，如果客户端数量很多，每个进程都会占据一定的系统资源，并且进行上下文切换，很消耗资源。此时可以考虑使用多线程模型。
    线程是运行在进程中的一个“逻辑流”，单进程中可以运行多个线程，同进程里的线程可以共享进程的部分资源，比如文件描述符列表、进程空间、代码、全局数据、堆、共享库等，这些共享些资源在上下文切换时不需要切换，而只需要切换线程的私有数据、寄存器等不共享的数据，因此同一个进程下的线程上下文切换的开销要比进程小得多。
    当服务器与客户端 TCP 完成连接后，通过 pthread_create() 函数创建线程，然后将「已连接 Socket」的文件描述符传递给线程函数，接着在线程里和客户端进行通信，从而达到并发处理的目的。
    但是想要达到C10K，一台机器就要维护1万个连接，相当于维护1万个进程/线程。这种方式不合适。
    既然为每个请求分配一个进程/线程的方式不合适，那有没有可能只使用一个进程来维护多个 Socket 呢？答案是有的，那就是 I/O 多路复用技术。
  • I/O多路复用
    虽然同一时刻一个进程只能处理一个请求，但是处理每个请求时，耗时控制在很短的时间内，把时间拉长来看，多个请求复用了一个进程，这就是多路复用，这种思想很类似一个 CPU 并发多个进程，所以也叫做时分多路复用。
    Linux 下有三种提供 I/O 多路复用的 API，分别是：select、poll、epoll。进程可以通过一个系统调用函数从内核中获取多个事件。
    select/poll/epoll 是如何获取网络事件的呢？在获取事件时，先把所有连接（文件描述符）传给内核，再由内核返回产生了事件的连接，然后在用户态中再处理这些连接对应的请求即可。
  • select/poll
    select 实现多路复用的方式是，将已连接的 Socket 都放到一个文件描述符集合，然后调用 select 函数将文件描述符集合拷贝到内核里，让内核来检查是否有网络事件产生，检查的方式很粗暴，就是通过遍历文件描述符集合的方式，当检查到有事件产生后，将此 Socket 标记为可读或可写， 接着再把整个文件描述符集合拷贝回用户态里，然后用户态还需要再通过遍历的方法找到可读或可写的 Socket，然后再对其处理。
    所以，对于 select 这种方式，需要进行 2 次「遍历」文件描述符集合，一次是在内核态里，一个次是在用户态里 ，而且还会发生 2 次「拷贝」文件描述符集合，先从用户空间传入内核空间，由内核修改后，再传出到用户空间中。
    select 使用固定长度的 BitsMap，表示文件描述符集合，而且所支持的文件描述符的个数是有限制的。而poll 用动态数组，以链表形式来组织，突破了 select 的文件描述符个数限制，当然还会受到系统文件描述符限制。
    但是 poll 和 select 并没有太大的本质区别，都是使用「线性结构」存储进程关注的 Socket 集合，因此都需要遍历文件描述符集合来找到可读或可写的 Socket，时间复杂度为 O(n)，而且也需要在用户态与内核态之间拷贝文件描述符集合，这种方式随着并发数上来，性能的损耗会呈指数级增长。
  • epoll
int s = socket(AF_INET, SOCK_STREAM, 0);
bind(s, ...);
listen(s, ...)int epfd = epoll_create(...);
epoll_ctl(epfd, ...); //将所有需要监听的socket添加到epfd中while(1) {int n = epoll_wait(...);for(接收到数据的socket){//处理}
}


epoll 通过两个方面，很好解决了 select/poll 的问题。
第一点，epoll 在内核里使用红黑树来跟踪进程所有待检测的Socket，把需要监控的 socket 通过 epoll_ctl() 函数加入内核中的红黑树里，红黑树是个高效的数据结构，增删改一般时间复杂度是 O(logn)。而 select/poll 内核里没有类似 epoll 红黑树这种保存所有待检测的 socket 的数据结构，所以 select/poll 每次操作时都传入整个 socket 集合给内核，而 epoll 因为在内核维护了红黑树，可以保存所有待检测的 socket ，所以只需要传入一个待检测的 socket，减少了内核和用户空间大量的数据拷贝和内存分配。
第二点， epoll 使用事件驱动的机制，内核里维护了一个链表来记录就绪事件，当某个 socket 有事件发生时，通过回调函数，内核会将其加入到这个就绪事件列表中，当用户调用 epoll_wait() 函数时，只会返回有事件发生的文件描述符的个数，不需要像 select/poll 那样轮询扫描整个 socket 集合，大大提高了检测的效率。
epoll 的方式即使监听的 Socket 数量越多的时候，效率不会大幅度降低，能够同时监听的 Socket 的数目也非常的多了，上限就为系统定义的进程打开的最大文件描述符个数。因而，epoll 被称为解决 C10K 问题的利器。

  • epoll的边缘触发和水平触发
    • 使用边缘触发模式时，当被监控的 Socket 描述符上有可读事件发生时，服务器端只会从 epoll_wait 中苏醒一次，即使进程没有调用 read 函数从内核读取数据，也依然只苏醒一次，因此我们程序要保证一次性将内核缓冲区的数据读取完；
      • 如果使用边缘触发模式，I/O 事件发生时只会通知一次，而且我们不知道到底能读写多少数据，所以在收到通知后应尽可能地读写数据，以免错失读写的机会。因此，我们会循环从文件描述符读写数据，那么如果文件描述符是阻塞的，没有数据可读写时，进程会阻塞在读写函数那里，程序就没办法继续往下执行。所以，边缘触发模式一般和非阻塞 I/O 搭配使用。
    • 使用水平触发模式时，当被监控的 Socket 上有可读事件发生时，服务器端不断地从 epoll_wait 中苏醒，直到内核缓冲区数据被 read 函数读完才结束，目的是告诉我们有数据需要读取；
      • 如果使用水平触发模式，当内核通知文件描述符可读写时，接下来还可以继续去检测它的状态，看它是否依然可读或可写。所以在收到通知后，没必要一次执行尽可能多的读写操作。

一般来说，边缘触发的效率比水平触发的效率要高，因为边缘触发可以减少 epoll_wait 的系统调用次数，系统调用也是有一定的开销的，毕竟也存在上下文的切换。
select/poll 只有水平触发模式，epoll 默认的触发模式是水平触发，但是可以根据应用场景设置为边缘触发模式。

简单介绍：

  • 高性能网络模式：Reactor和Proactor
    • 简单介绍
      当下开源软件能做到网络高性能的原因就是基于I/O多路复用，Reactor模式是对I/O多路复用的封装，让使用者不用考虑底层网络 API 的细节，只需要关注应用代码的编写。
      这里的Reactor指的是「对事件反应」，也就是来了一个事件，Reactor 就有相对应的反应/响应。
      事实上，Reactor 模式也叫 Dispatcher 模式，即 I/O 多路复用监听事件，收到事件后，根据事件类型分配（Dispatch）给某个进程 / 线程。
      无论是 Reactor，还是 Proactor，都是一种基于「事件分发」的网络编程模式。Redis、Netty、Memcache、Mginx都使用了这种高性能的网络模式。
  • 什么是一致性哈希？
    大多数网站背后肯定不是只有一台服务器提供服务，因为单机的并发量和数据量都是有限的，所以都会用多台服务器构成集群来对外提供服务。如此多的节点，如何处理大量的请求呢？每个节点处理多少请求？这类问题就是负载均衡问题。
    当我们想提高系统的容量，就会将数据水平切分到不同的节点来存储，也就是将数据分布到了不同的节点。比如一个分布式 KV（key-value） 缓存系统，某个 key 应该到哪个或者哪些节点上获得，应该是确定的。
    不同的负载均衡算法适用的业务场景不同。
    轮询这类的策略只能适用与每个节点的数据都是相同的场景，访问任意节点都能请求到数据。但是不适用分布式系统，因为分布式系统意味着数据水平切分到了不同的节点上，访问数据的时候，一定要寻址存储该数据的节点。
    哈希算法虽然能建立数据和节点的映射关系，但是每次在节点数量发生变化的时候，最坏情况下所有数据都需要迁移，这样太麻烦了，所以不适用节点数量变化的场景。
    为了减少迁移的数据量，就出现了一致性哈希算法。
    一致性哈希是指将「存储节点」和「数据」都映射到一个首尾相连的哈希环上，如果增加或者移除一个节点，仅影响该节点在哈希环上顺时针相邻的后继节点，其它数据也不会受到影响。
    但是一致性哈希算法不能够均匀的分布节点，会出现大量请求都集中在一个节点的情况，在这种情况下进行容灾与扩容时，容易出现雪崩的连锁反应。
    为了解决一致性哈希算法不能够均匀的分布节点的问题，就需要引入虚拟节点，对一个真实节点做多个副本。不再将真实节点映射到哈希环上，而是将虚拟节点映射到哈希环上，并将虚拟节点映射到实际节点，所以这里有「两层」映射关系。
    引入虚拟节点后，可以会提高节点的均衡度，还会提高系统的稳定性。所以，带虚拟节点的一致性哈希方法不仅适合硬件配置不同的节点的场景，而且适合节点规模会发生变化的场景。

Linux命令

查看网络性能指标

  • 查看网络配置
ipconfig
ip -s addr show dev eth0
# -s：输出更详细的信息；
ip [ OPTIONS ] OBJECT { COMMAND | help }
ip   选项       对象      命令      帮助


第一，网口的连接状态标志。其实也就是表示对应的网口是否连接到交换机或路由器等设备，如果 ifconfig 输出中看到有 RUNNING，或者 ip 输出中有 LOWER_UP，则说明物理网络是连通的，如果看不到，则表示网口没有接网线。
第二，MTU 大小。默认值是 1500 字节，其作用主要是限制网络包的大小，如果 IP 层有一个数据报要传，而且网络包的长度比链路层的 MTU 还大，那么 IP 层就需要进行分片，即把数据报分成若干片，这样每一片就都小于 MTU。事实上，每个网络的链路层 MTU 可能会不一样，所以你可能需要调大或者调小 MTU 的数值。
第三，网口的 IP 地址、子网掩码、MAC 地址、网关地址。这些信息必须要配置正确，网络功能才能正常工作。
第四，网络包收发的统计信息。通常有网络收发的字节数、包数、错误数以及丢包情况的信息，如果 TX（发送） 和 RX（接收） 部分中 errors、dropped、overruns、carrier 以及 collisions 等指标不为 0 时，则说明网络发送或者接收出问题了

  • socket信息如何查看？
# -n 表示不显示名字，而是以数字的方式显示ip和端口
# -l 表示只显示LISTEN状态的socket
# -p 表示显示进程信息
netstat -nlp

可以发现，输出的内容都差不多， 比如都包含了 socket 的状态（State）、接收队列（Recv-Q）、发送队列（Send-Q）、本地地址（Local Address）、远端地址（Foreign Address）、进程 PID 和进程名称（PID/Program name）等。
接收队列（Recv-Q）和发送队列（Send-Q）比较特殊，在不同的 socket 状态。它们表示的含义是不同的。
当 socket 状态处于 Established时：

  • Recv-Q 表示 socket 缓冲区中还没有被应用程序读取的字节数；
  • Send-Q 表示 socket 缓冲区中还没有被远端主机确认的字节数；

而当 socket 状态处于 Listen 时：

  • Recv-Q 表示全连接队列的长度；
  • Send-Q 表示全连接队列的最大长度；

在 TCP 三次握手过程中，当服务器收到客户端的 SYN 包后，内核会把该连接存储到半连接队列，然后再向客户端发送 SYN+ACK 包，接着客户端会返回 ACK，服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其增加到全连接队列 ，等待进程调用 accept() 函数时把连接取出来。
也就说，全连接队列指的是服务器与客户端完了 TCP 三次握手后，还没有被 accept() 系统调用取走连接的队列。
那对于协议栈的统计信息，依然还是使用 netstat 或 ss，它们查看统计信息的命令如下：
ss 命令输出的统计信息相比 netsat 比较少，ss 只显示已经连接（estab）、关闭（closed）、孤儿（orphaned） socket 等简要统计。
而 netstat 则有更详细的网络协议栈信息，比如上面显示了 TCP 协议的主动连接（active connections openings）、被动连接（passive connection openings）、失败重试（failed connection attempts）、发送（segments send out）和接收（segments received）的分段数量等各种信息。

  • 网络吞吐率和PPS如何查看？
    可以使用 sar 命令当前网络的吞吐率和 PPS，用法是给 sar 增加 -n 参数就可以查看网络的统计信息，比如
    • sar -n DEV，显示网口的统计数据；
    • sar -n EDEV，显示关于网络错误的统计数据；
    • sar -n TCP，显示 TCP 的统计数据
    • rxpck/s 和 txpck/s 分别是接收和发送的 PPS，单位为包 / 秒。
    • rxkB/s 和 txkB/s 分别是接收和发送的吞吐率，单位是 KB/ 秒。
    • rxcmp/s 和 txcmp/s 分别是接收和发送的压缩数据包数，单位是包 / 秒。

ethtool命令查询网卡带宽：ens33网卡（network adapter），虚拟机使用虚拟网卡。

  • 连通性和延时如何查看？
    要测试本机与远程主机的连通性和延时，通常是使用 ping 命令，它是基于 ICMP 协议的，工作在网络层。
    比如，如果要测试本机到 192.168.175.100ens33网卡的 IP 地址的连通性和延时：
    显示的内容主要包含 icmp_seq（ICMP 序列号）、TTL（生存时间，或者跳数）以及 time （往返延时），而且最后会汇总本次测试的情况，如果网络没有丢包，packet loss 的百分比就是 0。
    不过，需要注意的是，ping 不通服务器并不代表 HTTP 请求也不通，因为有的服务器的防火墙是会禁用 ICMP 协议的。

如何从日志分析PV、UV？

很多时候，我们观察程序是否如期运行，或者是否有错误，最直接的方式就是看运行日志，当然要想从日志快速查到我们想要的信息，前提是程序打印的日志要精炼、精准。

但日志涵盖的信息远不止于此，比如对于 nginx 的 access.log 日志，我们可以根据日志信息分析用户行为。

什么用户行为呢？比如分析出哪个页面访问次数（PV）最多，访问人数（UV）最多，以及哪天访问量最多，哪个请求访问最多等等。

这次，将用一个大概几万条记录的 nginx 日志文件作为案例，一起来看看如何分析出「用户信息」。

  • 不要轻易使用cat
    当我们要分析日志的时候，先用 ls -lh 命令查看日志文件的大小，如果日志文件大小非常大，最好不要在线上环境做。
    大家都知道 cat 命令是用来查看文件内容的，但是日志文件数据量有多少，它就读多少，很显然不适用大文件。
    对于大文件，我们应该养成好习惯，用 less 命令去读文件里的内容，因为 less 并不会加载整个文件，而是按需加载，先是输出一小页的内容，当你要往下看的时候，才会继续加载。
  • PV分析（分析过程略）
    PV 的全称叫 Page View，用户访问一个页面就是一次 PV，比如大多数博客平台，点击一次页面，阅读量就加 1，所以说 PV 的数量并不代表真实的用户数量，只是个点击量。
  • UV分析（分析过程略）
    UV 的全称是 Uniq Visitor，它代表访问人数，比如公众号的阅读量就是以 UV 统计的，不管单个用户点击了多少次，最终只算 1 次阅读量。

完。

本文链接：https://my.lmcjl.com/post/1975.html

展开阅读全文

相关文章

4 评论

留下您的评论.