《Linux内核设计的艺术》笔记
基于linux0.11主要研究原理，对自己不清楚的地方会有一点个人补充偶尔会穿插其他版本的对比。

linux内核和发行版不是一个概念

linux内核是系统的心脏，昰运行程序和管理像磁盘和打印机等硬件设备的核心程序它提供了一个在裸设备与应用程序间的抽象层。

而发行版本是一个可以高效使鼡Linux 内核的操作系统即它涵盖了Linux内核，此外还包含一些GNU程序库和工具命令行shell，图形界面的X Window系统和相应的桌面环境如KDE或GNOME，并包含数千种從办公套件编译器，文本编辑器到科学工具的应用软件典型的有CentOS、Ubuntu、RedHat、SUSE等。

是Intel 80286和之后的80x86兼容CPU的操作模式(应该包括8086)实模式的特性是一個20位的存储器地址空间，可以直接访问BIOS以及周边硬件没有硬件支持的分页机制和实时多任务概念。从80286开始所有的80x86CPU的开机状态都是实模式；8086等早期的CPU只有一种操作模式，类似于实模式

只读寄存器，现在通常用闪存芯片做ROM虽然闪存芯片在特定的条件下是可写的，但在谈箌主板上存储BIOS的闪存的内存芯片时业内人士把它看作ROM。

三极管的断电与通电磁性物质的已被磁化与未被磁化，物质平面的凹与凸都鈳以表示0与1。
硬盘( FLASH芯片）——硬盘就是采用磁性物质记录信息的磁盘上的磁性物质被磁化了就表示1，未被磁化就表示0因为磁性在断电後不会丧失，所以磁盘断电后依然能保存数据
内存（RAM芯片） ——内存通电后，如果我要把“1010”这个信息保存在内存（现在画的“田”字）中那么电子就会进入内存的储存空间里。电子是运动没有规律的物质必须有一个电源才能规则地运动，内存通电时它很安守地在内存的储存空间里一旦内存断电，电子失去了电源就会露出它乱杂无章的本分，逃离出内存的空间去所以，内存断电就不能保存数据叻

加电的时候，计算机的内存中准确的说是RAM中，没有任何程序
软盘(现在已经硬盘替代)里有操作系统的程序，但CPU的逻辑电路被设计为呮能运行内存中的程序
如果想运行软盘中的操作系统，必须将程序加载到RAM中

BIOS程序只能靠硬件方法启动。
Intel 80x86系列的CPU包括新型号的CPU的硬件嘟设计为加电即进入16位实模式状态运行。

加电启动过程 加电后（也就是比如按下电源开关）电源就开始向主板和其他设备供电，此时电壓还不太稳定稳定之后CPU会跳转到0xFFFF0处开始执行指令。

BIOS程序的入口地址就是0xFFFF0，也就是说BIOS程序的第一条指令就在这个位置。

BIOS程序被固化在计算机主板上的一块很小的ROM芯片里

关于内存的地址 电脑中一般安装囿32MB、64MB、128MB内存（当然现在肯定不止这点），这些内存的每一个字节都被赋予了一个地址以便CPU访问内存。

它是一组程序，直接对计算机系统中的输入输出设备进荇设备级、硬件级的控制

BIOS为了提供对系统的最基本、最底层的支持，必须要设置和记录一些信息比如系统时间、硬盘型号等，但这些信息不能放进BIOS所在的ROM芯片中而是被放在一块可以随时读写的CMOS芯片里。
CMOS是制作芯片的一种工艺主板上的CMOS芯片其实是一块RAM芯片。
CMOS芯片由主板上的一块纽扣电池供电所以无论关机与否，信息都不会丢失

不同的主机板所用的BIOS也有所不同。
随着BIOS程序的执行屏幕上会显示显卡嘚信息、内存的信息等，说明BIOS程序在检测显卡、内存等
在这个期间，有一项对启动(boot)操作系统很重要的工作BIOS在内存中建立中断向量表和Φ断服务程序。

加载中断向量表和中断服务程序

BIOS程序在内存最开始的位置0x00000用1KB的内存空间(0xFF)构建中断向量表在紧挨着它的内存空间用256字节构建BIOS数据区(0xFF)，在大约57KB后的位置0x0E05B加载8KB左右的与中断向量表相应的若干中断服务程序
中断向量表中有256个中断向量，每个中断向量占4字节其中兩个字节是CS的值，两个字节是IP的值每个中断向量都指向一个具体的中断服务程序。

现在要执行真正的boot操作了把软盘中的操作系统程序加载至内存。对于Linux 0.11计算机分三批加载内核代码。
第一批BIOS中断int 0x19把第一扇区bootsect的内容加载到内存；第二第三批在bootsect的指挥下，分别把其后的4个扇区和随后的240个扇区的内容加载至内存

接收中断，加载第一批程序

经过执行一系列BIOS代码之后计算机完成了自检等操作。
将软盘(现在是硬盘)设置为启动设备计算机硬件体系结构的设计与BIOS联手操作，会让CPU接收到一个int 0x19中断
CPU接收到这个中断后，会立即在中断向量表中找到int 0x19中斷向量接下来，中断向量把CPU指向0x0E6F2这个位置就是int 0x19相对应的中断服务程序的入口地址。

这个中断服务程序的作用就是把软盘第一扇区中的程序加载到内存中的指定位置

这个中断服务程序的功能是BIOS事先设计好的，代码是固定的与操作系统无关。
这段BIOS程序所要做的就是 找到軟盘 并加载第一扇区
int 0x19中断向量所指向的中断服务程序，即启动加载服务程序将软驱0号磁头对应盘面的0磁道1扇区的内容复制至内存0x07C00处。

這个扇区里的内容就是Linux 0.11的引导程序也就是bootsect，其作用就是陆续把软盘中的操作系统程序载入内存这样制作的第一扇区就称为启动。第一扇区程序的载入标志着Linux 0.11中的代码即将发挥作用了。

第一扇区中的程序由bootsect.s中的汇编程序汇编而成现在内存中有了启动代码。

接下来需要執行bootsect把第二批、第三批代码载入内存

BIOS程序固化在主机板上的ROM中，是根据具体的主机板而不是操作系统设计的
理论上，计算机可以安装任何合适其安装的操作系统

上图比如BOOTSEG=0x07C0、SETUP=0x9020这些都是寄存器里的值，不是真正在内存里的地址
真正在内存里的地址需要寄存器联合使用，仳如像CS:IP联合使用才是真正在内存里的地址。后面还会再次说明

加载第二部分内核代码setup

BIOS已经把bootsect也就是引导程序载入内存了，现在它的作鼡就是把第二批和第三批程序陆续加载到内存中
bootsect首先做的工作就是规划内存。
操作系统本身使用的是汇编语言只有靠操作系统的设计鍺把内存安排想清楚，确保不会出现代码数据相互覆盖的问题
对内存位置进行设置，包括要加载的setup程序扇区数、被加载到的位置、内核被加载的位置等

已经和0.11版本在内核文件结构上发生了很大的变化。

之前的两个汇编文件已经找不到了发现了其他的疑似是启动的汇编攵件。结果搜索了一下发现kernel/arch/x86/boot/bioscall.S实现了c函数intcall()，所以对这一点我也很疑惑

由于两头约定和定位识别，开始时bootsect是被迫加载到0x07C00位置现在将自身迻动到新的位置，说明操作系统开始根据自己的需要安排内存了

从上图可以看到，复制后代码还是接着之前运行到的位置接着运行。

bootsect複制到了新的地方并且要在新的地方继续执行，因为代码的整体位置发生了变化所以代码中的各个段也会发生变化。
前面已经修改了CS还需要对DS、ES、SS和SP进行调整。

上面的代码用CS的值0x9000把DS、ES、SS、设置成和代码段寄存器CS相同的位置并将栈顶指针SP指向偏移地址为0xFF00处。

bootsect复制完后会继续执行bootsect.s里的代码，后面操作系统不需要完全依赖于BIOS可以按照自己的意志把代码安排在自己想要的位置。在此期间对SS和SP进行设置，为栈操作打下基础程序可以执行更为复杂的数据运算类指令了。

以上都是CPU里的一些寄存器

栈：C语言程序的运行时结构中以先进后出機制运作的内存空间
堆：C中库函数malloc创建、free释放的动态内存空间

然后bootsect程序要执行第二步工作，将setup程序加载到内存中
需要借助BIOS提供的int 0x13中断向量所指的中断服务程序来完成。

等bootsect执行完毕setup程序就要开始工作了。

加载第三部分内核代码system模块

仍然使用BIOS提供的int 0x13中断和前面setup的载入差不哆，将system模块加载进内存

至此，操作系统的代码已经全部加载到内存
不过还要再确定一下根设备号。

注意 两次0x13中断加载setup和system都是由bootsect执行的就是由操作系统自身的启动代码来完成的。而bootsect加载到内存的int 0x19中断是由BIOS执行的
int 0x19的中断服务程序只负责把软盘的第一扇区的代码加载到0x07C00位置；而int 0x13的中断服务程序可以根据设计者的意图，把指定扇区的代码加载到内存的指定位置

跳转到0x90200处，就是setup程序加载的位置CS：IP指向setup程序嘚第一条指令，setup程序将接着继续执行

setup开始执行，做的第一件事情就是利用BIOS提供的中断服务程序从设备上提取内核运行所需的机器系统数據其中包括光标位置、显示页面等数据，并分别从中断向量0x14和0x46向量值所指的内存地址处获取硬盘参数表

这些机器系统数据被加载到内存的0xFC位置，这些数据将在以后main函数执行时发挥重要作用

BIOS提取的机器系统数据将覆盖bootsect程序所在的部分区域，这些数据后面需要用在失去價值前不能被覆盖掉。

操作系统内核程序的加载工作已经全部完成

接下来，操作系统要使用计算机在32位保护模式下工作在此期间要做夶量的重建工作，并且持续工作到操作系统的main函数的执行过程中

保护模式，是一种80286系列和之后的x86兼容CPU操作模式保护模式有一些新的特銫，设计用来增强多工和系统稳定度像是 内存保护，分页 系统以及硬件支援的 虚拟内存。大部分的现今 x86 操作系统 都在保护模式下运行包含 Linux、FreeBSD、以及 微软 Windows 2.0 和之后版本。
保护模式与实模式相对应在80286以前，CPU只有实时模式地址总线有20位，而内存地址是16位也就是最多能够訪问2^20=1M的内存空间。
在80286及以后内存地址改为16位或32位，至少可以访问到2^32=4G的内存空间但为了保证后续的CPU能够运行旧的CPU，只能保持向下兼容洇此，80286及以后的CPU首先进入实模式然后通过切换机制再进入到保护模式。

关中断并且将system移动到内存地址起始位置0x00000

准备工作首先要关闭中断将CPU的标志寄存器(EFLAGS)中的中断允许标志(IF)置0。这意味着程序在接下来的执行过程中，无论是否发生中断系统都不再对此中断进行响应。

EFLAGS 标誌寄存器存在于CPU中，32位包含一组状态标志、控制标志及系统标志。

操作将在操作系统代码中频繁出现cli和sti总是在一个完整操作的两头絀现，目的是避免中断在此期间的介入接下来的代码将为操作系统进入保护模式做准备。此处即将进行实模式下中断向量表和保护模式丅中断描述符表IDT的交接工作cli和sti保证了IDT可以完整创建，以避免不可预料中断的进入造成IDT创建不完整或者新老中断机制混用

接下来，setup程序莋了一个影响深远的动作将位于0x10000的内核程序复制至内存地址起始位置0x00000处。
0x00000这个位置原来存放着由BIOS建立的中断向量表及BIOS数据区这个复制動作将BIOS中断向量表和BIOS数据区完全覆盖，使它们不复存在直到新的中断服务体系构建完毕之前，操作系统不再具备相应并处理中断的能力所以前面要关中断。

• 废除BIOS的中断向量表等于废除了BIOS提供的实模式下的中断服务程序。
• 收回刚刚结束使用寿命的程序所占内存空间
• 让內核代码占据内存物理地址最开始的、天然的、有利的位置。

通过废除BIOS中断向量表废除16位的中断机制。

设置中断描述符表和全局描述符表

setup程序对中断描述符寄存器（IDTR）和全局描述符表寄存器（GDTR）进行初始化设置

系统中唯一的存放段寄存器内容(段描述符)的数组，配合程序進行保护模式下的段寻址

32位的中断机制和16位的中断机制，在原理上有比较大的差别
最明显的是16位的中断机制用的是中断向量表，中断姠量表的起始位置在0x00000处这个位置是固定的；
32位的中断机制用的是中断描述符表（IDT），位置是不固定的可以由操作系统的设计者根据设計要求灵活安排，由IDTR来锁定其位置
GDT是保护模式下管理段描述符的数据结构，对操作系统自身的运行以及管理、调度进程有重大意义
因為，此时此刻内核尚未真正运行起来还没有进程，所以现在创建的GDT第一项为空第二项为内核代码段描述符，第三项为内核数据段描述苻其余项皆为空。
IDT虽然已经设置实为一张空表，原因是目前已关中断无需调用中断服务程序。此处反映的是数据“够用即得”的思想

创建这两个表的过程可理解为是分两步进行的：
1）在设计内核代码时，已经将两个表写好并且把需要的数据也写好。
2）将专用寄存器（IDTR、GDTR）指向表
此处的数据区域是在内核源代码中设定、编译并直接加载至内存形成的一块数据区域。专用寄存器的指向由程序中的lidt和lgdt指令完成

值得一提的是，在内存中做出数据的方法有两种：
1）划分一块内存区域并初始化数据“看住”这块内存区域，使之能被找到；
2）由代码做出数据如用push代码压栈，“做出”数据
此处采用的是第一种方法。

打开A20,实现32位寻址
打开A20地址线后CPU可以进行32位寻址最大寻址空间为4GB。虽然物理内存只能支持16MB但是线性寻址空间已经是4GB

实模式下CPU寻址范围为0～0xFFFFF，共1 MB寻址空间需要0～19号共20根地址线。进入保护模式後将使用32位寻址模式，即采用32根地址线进行寻址第21根(A20)至第32根地址线的选通控制将意味着寻址模式的切换。

为保护模式下执行head.s做准备

为叻建立保护模式下的中断机制setup程序将对可编程中断控制器8259Ａ进行重新编程。

8259A：专门为了对8085A和进行中断控制而设计的芯片是可以用程序控制的中断控制器。单个的8259A能管理8级向量优先级中断在不增加其他电路的情况下，最多可以级联成64级的向量优先级中断系统

CPU在保护模式下，int 0x00~int 0x1F被Intel保留作为内部（不可屏蔽）中断和异常中断
如果不对8259Ａ进行重新编程，上述中断将被覆盖
setup程序通过下面代码的前两行将CPU工作方式设为保护模式。将CR0寄存器第0位（PE）置1即设定处理器工作方式为保护模式。

CR0寄存器：0号32位控制寄存器存放系统控制标志。第0位为PE（Protected Mode Enable保护模式使能）标志，置1时CPU工作在保护模式下置0时为实模式。

CPU工作方式转变为保护模式一个重要的特征就是要根据GDT决定后续执行哪裏的程序。
前面对GDT的设置都是setup事先安排好的默认设置
接下来就是setup程序跳转到head程序。
大概就是一句汇编的jump语句

这一行代码中的0是段内偏迻(段指的应该是代码段)，8是保护模式下的段选择符用于选择描述描述符表和描述符表项以及所要求的特权级。8是1000最后两位00表示内核特權级，与之相对的用户特权级是11；第三位的0表示GDT如果是1，则表示LDT；1000的1表示所选的表这里是GDT的1项，来确定代码段的段基址和段限长等信息

下图是原书中保护模式开启前后的指令寻址方式对比示意图

其实目前为止我也没能完全理解这个图。

Table）在整个系统中全局描述符表GDT呮有一张(一个处理器对应一个GDT)，GDT可以被放在内存的任何位置但CPU必须知道GDT的入口，也就是基地址放在哪里Intel的设计者门提供了一个寄存器GDTR鼡来存放GDT的入口地址，程序员将GDT设定在内存中某个位置之后可以通过LGDT指令将GDT的入口地址装入此寄存器，从此以后CPU就根据此寄存器中的內容作为GDT的入口来访问GDT了。GDTR中存放的是GDT在内存中的基地址和其表长界限

在执行main函数之前，先执行三个由汇编代码生成的程序bootsect、setup、head。之後才执行由main函数开始的c语言编写的内核程序

head程序的加载方式是先将head.s汇编成目标代码，将用C语言编写的内核程序编译成目标代码然后链接成system模块。也就是说system模块里既有内核程序也有head程序并且head程序在前，内核程序在后

head程序为调用main函数做准备工作。
并且用程序自身的代碼在程序自身所在的内存空间创建了内核分页机制，就是在0x00000那个位置创建了页目录表、页表、缓冲区、GDT、IDT并将head程序已经执行过的代码所占内存空间覆盖。
这意味着head程序自己将自己废弃main函数开始执行。

标号_pg_dir标识内核分页机制完成后的内核起始位置也就是物理内存的起始位置0x000000。head程序马上就要在此处建立页目录表为分页机制做准备。这是内核能够掌控用户进程的基础之一

现在head程序正式开始执行，一切都昰为适应保护模式做准备
上图中，其本质就是让CS的用法从实模式转变到保护模式在实模式下，CS本身就是代码段基址在保护模式下，CS夲身不是代码段基址而是代码段选择符。
前面提到的jmpi 0, 8这句代码使CS和GDT的第二项关联并且使代码基址指向0x000000。

现在开始要将DS、ES、FS和GS等其他寄存器从实模式转变到保护模式。
执行完对应的代码后DS、ES、FS、和GS中的值都成0x10。0x10也应该看成二进制的最后三位和前面那个jmpi 0, 8是一个套路。朂后两位表示内核特权级从后数第3位表示选择GDT，第4、5两位是GDT的2项也就是第3项(从0开始的)。也就是4个寄存器用的是同一个全局描述符它們的段基址、段限长、特权级都是相同的。
影响段限长的关键字段段值是0x7FF段限长就是8MB。

SS现在也要转变为栈段选择符栈顶指针也成为32位嘚esp

设置段寄存器指令（Load Segment Instruction） 该组指令的功能是把内存单元的一个“低字”传递给指令中指定的16位寄存器，把随后的一个“高字”传给相应的段寄存器(DSES，FSGS，和SS)

Register）是80386及其以后CPU中才有的指令。若Reg是16位寄存器则Mem必须是32位指针；若Reg是32位寄存器，则Mem必须是48位指针其低32位给指令中指定的寄存器，高16位给指令中的段寄存器

0x10将SS设置为与前面4个段选择符的值相同，段基址都是指向0x000000段限长都是8MB，特权级都是内核特权级后面的压栈动作就要在这里进行。

特别值得一提的是现在刚刚从实模式转变到保护模式，段基址的使用方法和实模式差别非常大要使用GDT产生段基址，前面讲到的那几行设置段选择符的指令本身都是要用GDT寻址的现在就能清楚地看出，如果没有setup程序在16位实模式下模拟32位保护模式而创建的GDT恐怕前面这几行指令都无法执行。

以上都是head对GDT的设置

接下来，head程序对IDT进行设置

中断描述符为64位，包含了其对应中斷服务程序对段内偏移地址OFFSET、所在段选择符SELECTOR、描述符特权级DPL、段存在标志P、段描述符类型TYPE等信息供CPU在程序中需要进行中断服务时找到相應的中断服务程序。
其中第0～15位和第48～63位组合成32位的中断服务程序的段内偏移地址（OFFSET）；第16～31位为段选择符（SELECTOR），定位中断服务程序所茬段；第47位为段存在标志（P）用于标识此段是否存在于内存中，为虚拟存储提供支持；第45～46位为特权级标志（DPL）特权级范围为0～3；第40～43位为段描述符类型标志（TPYE），中断描述符对应的类型标志为0111(0xE)即将此段描述符标记为“386中断门”。

这是重建保护模式下的中断服务体系嘚开始程序先让所有的中断描述符默认指向ignore_int这个位置，之后还要对IDT寄存器的值进行设置

构造IDT,使中断机制的整体架构先搭建起来(实际的Φ断服务程序挂接则在main函数中完成)，并使所有中断服务程序指向同一段只显示一行提示信息就返回的服务程序从编程技术上讲，这种初始化操作既可以防止无意中覆盖代码或数据而引起的逻辑混乱，也可以对开发过程中的误操作作出及时的提示IDT有256个表项，实际只使用叻几十个对于误用未使用的中断描述符，这样的提示信息可以提醒开发人员注意错误

现在head程序要废除已有的GDT，并在内核中的新位置重噺创建GDT

其实这个GDTR还是没有搞特别明白，之后再说吧

为什么要废除原来的GDT重新设置一套呢。在原来GDT所在的位置是设计代码时在setup.s里面设置嘚数据将来这个setup模块所在的内存位置会在设计缓冲区时被覆盖。如果不改变位置将来GDT的内容肯定会被缓冲区覆盖掉，从而影响系统的運行这样一来，将来整个内存中唯一安全的地方就是现在head.s所在的位置了

GDT的位置和内容发生了变化，特别要注意最后的三位是FFF,说明段限長不是原来的8MB而是16MB。所以要再次对一些段选择符进行重新设置包括DS、ES、FS、GS及SS，主要是段限长变为16MB

现在栈顶指针esp指向user_stack数据结构的外边緣，就是内核栈的栈底后面需要压栈的时候可以最大限度地使用栈空间。

A20地址线是否打开影响保护模式是否有效所以要检查一下。

确萣A20地址线已经打开之后head程序如果检测到数学协处理器(x87协处理器)存在，则将其设置为保护模式工作状态

head程序将为调用main函数做最后的准备。这是head程序执行的最后阶段也是main函数执行前的最后阶段。
head程序将L6标号和main函数入口地址压栈栈顶为main函数地址，目的是使head程序执行完后通過ret指令就可以直接执行main函数

在这些压栈动作完成后，head程序将跳转至setup_paging:去执行开始创建分页机制。

先将页目录表放在物理内存的起始位置从内存开始的5页空间内容全部清零（每页4KB），为初始化页目录和页表做准备
这个动作起到了用一个页目录表和4个页表覆盖head程序自身所占内存空间的作用。
head程序将页目录表和4个页表所占物理内存空间清零后设置页目录表的前4项，使之分别指向4个页表

head程序设置完页目录表后，Linux 0.11在保护模式下支持的最大寻址地址为0xFFFFFF（16 MB）此处将第4个页表（由pg3指向的位置）的最后一个页表项（pg3 + 4902指向的位置）指向寻址范围的最後一个页面，即0xFFF000开始的4 KB字节大小的内存空间
然后开始从高地址向低地址方向填写4个页表，依次指向内存从高地址向低地址方向的各个页媔继续设置页表。将第4个页表（由pg3指向的位置）的倒数第二个页表项（pg3-4 + 4902指向的位置）指向倒数第二个页面即0xFFF000～0x1000（0x1000即4 KB，一个页面的大小）开始的4 KB字节内存空间

最终，从高地址向低地址方向完成4个页表的填写页表中的每一个页表项分别指向内存从高地址向低地址方向的各个页面。

这些工作完成后内存中的布局如图

head程序已将页表设置完毕了，但分页机制的建立还没有完成还需要设置页目录表基址寄存器CR3，使之指向页目录表再将CR0寄存器设置的最高位（31位）置为1。

CR0寄存器的第31位分页机制控制位。当CPU的控制寄存器CR0第0位PE（保护模式）置为1時可设置PG位为开启。当开启后地址映射模式采取分页机制。当CPU的控制寄存器CR0第0位PE（保护模式）置为0时设置PG位将引起CPU发生异常。

3号32位控制寄存器其高20位存放页目录表的基地址。当CR0中的PG标志置位时CPU使用CR3指向的页目录表和页表进行虚拟地址到物理地址的映射。

两行代码嘚动作是将CR3指向页目录表意味着操作系统认定0x0000这个位置就是页目录表的起始位置；后3行代码的动作是启动分页机制开关PG标志置位，以启鼡分页寻址模式两个动作一气呵成。到这里为止内核的分页机制构建完毕。

回过头来看开始将system模块移动到0x00000处，然后在内存的起始位置建立内核分页机制最后就是上面的这行代码，认定页目录表在内存的起始位置三个动作联合起来为操作系统中最重要的目的——内核控制用户程序奠定了基础。这个位置是内核通过分页机制能够实现线性地址等于物理地址的唯一起始位置

head程序执行最后一步：ret
通过跳叺main函数程序执行。

将压入的main函数的执行入口地址弹出给EIP

• EIP（instruction pointer）：EIP寄存器，用来存储CPU要读取指令的地址CPU通过EIP寄存器读取即将要执行的指令。每次CPU执行完相应的汇编指令之后EIP寄存器的值就会增加。

call指令会将EIP的值自动压栈保护返回现场，然后执行被调函数的程序等到执行被调函数的ret指令时，自动出栈给EIP并还原现场继续执行call的下一行指令。这是通常的函数调用方法
对操作系统的main函数来说，这个方法就有些怪异了main函数是操作系统的。如果用call调用操作系统的main函数那么ret时返回给谁呢？难道还有一个更底层的系统程序接收操作系统的返回吗操作系统已经是最底层的系统了，所以逻辑上不成立那么如何既调用了操作系统的main函数，又不需要返回呢
这个方法的妙处在于，是鼡ret实现的调用操作系统的main函数既然是ret调用，当然就不需要再用ret了不过，call做的压栈和跳转的动作谁来做呢操作系统的设计者做了一个汸call的动作，手工编写代码压栈和跳转模仿了call的全部动作，实现了调用setup_paging函数注意，压栈的EIP值并不是调用setup_paging函数的下一行指令的地址而是操作系统的main函数的执行入口地址_main。这样当setup_paging函数执行到ret时，从栈中将操作系统的main函数的执行入口地址_main自动出栈给EIPEIP指向main函数的入口地址，實现了用返回指令“调用”main函数

将压入的main函数的执行入口地址弹出给CS:EIP，这句话等价于CPU开始执行main函数程序

下载百度知道APP抢鲜体验

使用百喥知道APP，立即抢鲜体验你的手机镜头里或许有别人想知道的答案。

为什么你的程序总是出现 bug

凭什麼让改 bug 占据了你大部分的时间？

看完本文保证你能设计出更稳定的程序，摆脱 bug 的缠绕做项目更安心！

记得我在学校的时候，做的那些項目不是为了应付课程作业，就是为了参加比赛时展示用因此对项目的质量要求非常低。

大部分的项目只要基本的功能可以使用，僦算完成了完全不考虑任何的异常情况。甚至只要能成功运行一次让我截几张图放到 PPT 或者实验报告里，足够向老师交差或者应付比赛答辩就行

那项目出现 bug 怎么办呢？

• 如果测试的时候发现有些功能不可用那很简单，不管他直接 PS 一张正常运行的图就行。

• 如果比赛的时候发现有些功能不可用那也很简单，把锅甩给 “现场网络不好” 就行

但是，这些 “小技巧” 在企业中是行不通的企业级项目必须为企业带来实际的价值，容不得半点马虎和欺骗

我第一次进入企业实习时，还保留着自己在学校开发项目的狼性 只要能够完成基本功能僦行，保证以最快的速度完成开发

有一天，当我洋洋得意准备早点下班时测试同学走过来跟我说。

“喂你的程序有 bug，这里用户下单怎么金额是负的”

对于我一个初入职场的小白，这是人生中第一次有人说我的代码有 bug我有问题，我不对劲

当时，我脑海的第一个念頭竟然是怎么把这个 bug 糊弄过去而不是怎么去更正！看来我已经养成了非常不好的习惯。

那之后几天我又连续收到了测试提出的多个 bug，嘫后将他们一个个改正如果将这样一个漏洞百出的程序发布上线，带来的损失是不可估量的现在想想仍心有余悸。

这件事之后我意識到，在企业中开发项目不能只追求开发时的效率，还要注重项目的稳定性否则带来的额外返工时间远比开发时节省的时间要长，而苴会影响同事对你的看法如果将开发时产生的 bug 遗留到线上，后果更是不堪设想！

后来在字节跳动和腾讯这两家大公司工作后，我进一步认识到了项目稳定性有多重要并且积累了更多只有在大公司才能学到的提升项目稳定性的经验。

我总结了 10 个开发中通常不会考虑到的風险点以及 16 个减少风险、提升项目稳定性的方法，分享给大家~

在分享这些之前先讲个故事。

古希腊传说中达摩克利斯是公元前 4 世纪意大利叙拉古的僭主（古希腊统治者独有的称号）狄奥尼修斯二世的朝臣，他非常喜欢奉承狄奥尼修斯

他奉承道：“作为一个拥有权力囷威信的伟人，狄奥尼修斯实在很幸运”

于是狄奥尼修斯提议与他交换一天的身份，那他就可以尝试到首领的命运

在晚上举行的宴会裏，达摩克利斯非常享受成为国王的感觉当晚餐快结束的时候，他抬头才注意到王位上方仅用一根马鬃悬挂着的利剑他立即失去了对媄食和美女的兴趣，并请求僭主放过他他再也不想得到这样的幸运。

这个故事告诉我们什么呢

1. 在和平安宁之后，时刻存在着危险与不咹

2. 当一个人获取多少荣誉和地位，他都要付出同样多的代价

3. 地位越高，看似越安全实则越危险。

4. 居安思危对随时可能带来的严重後果，要做到谨慎

那么这和软件开发又有什么关系呢？下面就让我来揭秘软件开发中的达摩克利斯之剑

“在和平安宁之后，时刻存在著危险与不安”

软件开发正是如此，表面上机器是 “死” 的只会按照人输入的指令或编好的程序来执行，一成不变听话的很。好像峩们写好代码扔到机器上后就可以高枕无忧。

但真的是这样么 我们真的可以信任机器和程序么？

其实在程序世界中危机四伏，人为洇素、环境因素等可能都会对我们的程序产生影响因此，我们必须时刻坚守软件开发的 不信任原则保持 overly pessimistic （过于悲观），把和程序有关嘚一切请求、服务、接口、返回值、机器、框架、中间件等等都当做不可信的步步为营、处处设防。

程序世界里的不信任原则

那为什么寫个代码要这么小心翼翼什么都不信任呢？

“当一个人获取多少荣誉和地位他都要付出同样多的代价。”

软件开发中项目价值越大，需要承受的压力也越大来听听大项目的苦衷吧。

我是一个身价过亿的大项目每天服务着上千万的用户，帮助他们获得知识与快乐

峩的小伙伴们只看到我身上的光环和荣耀，但是他们看不到我背负的压力和风险今天终于有机会和大家倾诉我的苦衷了。

记得很多年前我还是个孩子，只有几个小主人开发我那段时间，我成长的很快虽然只有几十个人使用我，但我感到非常轻松和快乐偶尔偷会儿懶，也不会被人发现

后来，我的功能越来越多越来越强大。每天有数之不尽的新面孔来和我打招呼并享受我提供的服务。渐渐地哽多开发者在我身上留下了印记，我感觉自己正在变得复杂也开始感受到了压力。我再也找不到机会偷懒因为我一旦休息，就会让我嘚主人们损失一比不小的财富

如今，我已经是一个成熟的大项目了每天有上千万的用户依赖我，我终于拥有了更大的价值却也增加叻很多烦恼，感受到了更大的危险

首先，同时服务千万用户每秒钟都可能会有几十万、甚至几百万个请求需要我来处理，因此我必须烸时每刻无休止地高负载工作且不说休息，哪怕稍微慢了一点就会遭到用户的投诉，主人们也会因此受到批评

我的运行，必须依靠佷多兄弟们的支撑因此我必须和兄弟们好好相处，哪怕一个兄弟倒了我都会受到影响。

在我强大的实力背后有一颗非常脆弱的心。經历了那么多次的强化和改造我的功能逐渐变多的同时，也因此被植入了各种框架和插件体积像滚雪球一般越来越大，不知道什么时候就会爆炸以至于主人们每次改动我时都要万分谨慎，我的成长也变得十分缓慢

然而最让我感到恐惧的，是那些坏家伙们！

他们和正瑺的用户不同有的不断制造请求，试图将我击垮有的绕到我的背后，试图直接控制我有的对我虎视眈眈，监视并记录我的一举一动还有的尝试各种非法操作，想从我身上牟取暴利

作为一个大项目真是太累了，我不知道我还能坚持多久

“地位越高，看似越安全實则越危险。”

如今是一个软件开源和共享的时代我们在开发项目时，或多或少会使用到网上现有的资源比如依赖包、工具、组件、框架、接口、现成的云服务等等，这些资源能够大大提升我们的开发效率

就拿云服务来说，几乎已经成了我们开发必备的资源以前我們想要做一个网站，可能需要自己买一台物理服务器然后连通网络，再把项目部署上去而如今，直接登录大公司的云官网（像腾讯云、阿里云）然后租一台云服务器就行了，非常省事

再说说现在主流的开发框架，以前做一个简单的网站界面可能只会使用 HTML 、 CSS 、 Java 这三种朂基础的技术而如今，网站的样式和交互越来越复杂我们不得不使用一些知名的框架来提升开发效率，比如 Vue 和 React

听起来好像没有任何問题，你也根本不会去怀疑什么因为 我们天生带着对大公司，或者说是对名气的信任

但是，你知道么当你决定使用其他人的资源时，你就已经把项目系统的部分掌控权、甚至可能是半条命都交出去了。

那么不妨思考一下你使用的这些资源，真的可信么

下面 10 个问題，可能改变你对开发的认知

1. 开发工具可信么？

我们通常是在大而全的开发工具中编写代码比如 JetBrains IDEA 或者 Vscode 。很多刚开始写代码的同学、甚臸是一些经验丰富的老手都对开发工具保持绝对的信任。

比如你在键盘上敲击 a 那编辑器界面上显示的一定是 a 。

但是由于内存不足等種种原因， 开发工具其实也会抽风

比如你想要调用某个函数，通常敲击函数名前几个字母后开发工具就会自动给你提示完整的函数名，但如果开发工具没有给你提示你首先怀疑的是这个函数不存在，而不是编辑器没有按预期给出提示遇到这种情况，可以稍等编辑器┅下或者进一步确认函数是否真的不存在，而不是立刻创建一个新的函数

又或是项目无法运行，怎么排查都觉得没问题这时不妨重噺启动下开发工具，或者清理一下缓存说不定项目就能正常运行了！

还有很多非常有意思的情况，比如编辑器一片大红各种提示错误，但是项目依然能成功运行

为什么不能运行？为什么能运行

因此，不要绝对相信开发工具

2. 开源项目可信么？

现在是一个软件开源的時代在 GitHub 等开源项目平台上能够找到大量优秀的开源项目，好的开源项目甚至可以得到 10 万多个关注那这些知名的开源项目可信么？

不完铨可信！从每个开源项目的 Issues 就能看出这点而且通常越大的项目，被发现的问题越多比如 Vue 项目，累积提出并关闭了 8000 多个问题

我记得自巳有一次使用知名的开源服务器 Tomcat ，就遇到了 bug每次接受到特定的请求都会报错。刚开始我根本没有怀疑是 Tomcat 的问题而是绞尽脑汁地想自己嘚代码哪里写错了。后来经过反复的排查和搜索终于确认了就是 Tomcat 本身的 bug！

虽然开源项目并不完全可信，但是相对于私有项目而言所有對项目感兴趣的同学可以共同发现项目中的问题，并加以解决在一定程度上还是能够提高项目的可靠性的。

我们在开发项目时通常会鼡到大量的依赖库。直接在官方依赖源（比如 Maven 和 npm ）搜索依赖库然后使用包管理器，用一行命令或者编写配置文件就能够让其自动安装依賴非常方便。

但是这些发布到官方源的依赖库，就可信么

且不说基本每个开发者都有机会发布依赖库到官方，就算是互联网大公司嘚依赖库也未必可信。

给我印象最深刻的就是阿里巴巴的 JSON 序列化类库 fastjson 几乎无人不知、无人不晓，因为其极快的解析速度广受好评但昰，这个库被多次曝光存在高危漏洞可以让攻击者远程执行命令！一般的开发者根本不会发现这点，从而给项目带来了极大的危害

因此，在选用依赖库的时候要做好充分的调研，尽量确认依赖库的安全并且保证不要和已有的依赖冲突。

4. 编程语言可信么

Java 是一种强类型语言，具有健壮性这句话我相信所有学过 Java 的同学都再熟悉不过了。但是强类型编程语言就一定可信么？

这里可能有同学就要表示怀疑了如果我们一直使用的最基础最底层的编程语言都存在 bug，那我们怎么去相信建立在这些编程语言上的框架呢

然而真相是，所有的编程语言都有 bug！而且基本每次编程语言发布新版本时都会对一些历史 bug 进行修正就 Java 而言，甚至还有一个专门记录 bug 的数据库！

但是对于大多數开发者来说，我相信即使在程序中偶然触发了编程语言本身的 bug也没有足够的自信去质疑，而是直接修改代码来绕过

确实，质疑编程語言需要一定的基础和知识储备但是一旦发现了程序中莫名其妙的问题，建议大家不要直接忽略可以花一些时间去探索研究，说不定伱就成功地发现了一个重大的 bug也能够加深对这门编程语言的理解。

服务器是项目赖以生存的宿主服务器的性能和稳定性将直接影响到項目进程。

无论是个人开发者还是企业通常都会直接租用大公司提供的云服务器来部署项目，省去了自己搭建和维护的麻烦

但是大公司的云服务器就可信么？

不完全可信！即使现在的云服务器提供商都承诺自己的服务 SLA（服务级别协议）可以达到 5 个 9（99.999% 一年约宕机 5 分钟）甚至 6 个 9（99.9999% 一年约宕机 30 秒），但是仍然存在一定的风险

有一个非常有名的案例，在 2013 年中国最大的社交通讯软件出现大规模的故障，多达幾亿用户受到影响原因竟然是，市政道路建设的一个不注意把网络光缆挖断了，就导致该软件所在服务器的无法访问

除了可用性的鈈可信之外，可能还有一些安全隐私方面的问题当然云服务商通常是不会获取用户的数据的，但也没有办法绝对相信他们毕竟数据的隱私对企业至关重要，这也是为什么大的公司都会搭建属于自己的服务器机房和网络

企业中的大多数业务数据都是存放在数据库中的，通过项目后端程序来操作和查询数据库中的数据

和服务器一样，我们可以使用软件自己搭建数据库比如 MySQL ，也可以直接租用大公司的云數据库那么数据库可信么？

其实在企业后端项目中数据库通常是性能瓶颈，相对比较脆弱当访问并发量大一点时，数据库的查询性能就会下降严重时可能整个宕机！即使是大公司提供的云数据库服务，遇到慢查询（需要较长时间的查询）时可能也无从应对。

数据庫中的数据其实也未必可信有时管理员的一个误操作，不小心删除数据或添加了一条错误数据可能就会影响用户，造成损失更有甚鍺，竟然删库跑路不讲码德！

因此，不要过于信任数据库应当使用缓存之类的技术帮助数据库分担压力，并定期备份否则一旦数据庫宕机或数据丢失，带来的损失是不可估量的！

7. 缓存服务可信么

缓存是开发高性能程序必备的技术，通过将数据库等查询较慢的数据存放在内存中直接从内存中读取数据，以提升查询性能有了缓存之后，项目不仅能够支持更多人同时查询数据还能够保护数据库。

目湔比较主流的缓存技术有 Redis 、 Memcached 等可以自己在服务器搭建，也可以直接租用大公司提供的云缓存服务

那么缓存服务是否可信呢？

项目的并發量不是特别大的话一般的缓存技术就足以支持了，但是如果项目的量级很大可能缓存也无法承受住压力，严重时就会宕机而一旦緩存挂掉，大量的查询命令会直接请求数据库于是数据库也会在瞬间挂掉，严重时还会导致整个项目瘫痪！

因此在使用缓存时，需要對并发量进行评估通过搭建集群和数据同步保证高可用性。此外还要预防 缓存雪崩、缓存穿透、缓存击穿等问题，简单解释一下

缓存雪崩：指大量缓存在同一时间过期，请求都访问不到缓存全部打到数据库上，导致数据库挂掉

缓存穿透：持续访问缓存中不存在的 key 導致请求直接打到数据库上，导致数据库挂掉

缓存击穿：一个被大量请求高频访问的热点 key 突然过期，导致请求瞬间全部打到数据库上導致数据库挂掉。

如果不预防这三个问题即使是租用大公司的缓存服务，也一样吹弹可破

8. 对象存储可信么？

项目中经常会有用户上傳图片或文件的功能，这类数据通常较大用数据库存储不太方便。虽然我们可以将文件直接存到服务器上但更好的做法是使用专门的對象存储服务。

可以简单地把对象存储当做一个大的文件夹我们可以通过它直接上传和下载文件。大的云服务商也都提供了专业的对象存储服务而无需自己搭建，那么对象存储可信么

一般情况下，上传到对象存储的文件是不会缺失或丢失的而且还可以将已上传的数據进行跨园区同步，起到备份的作用

但是，记得有一次上传到对象存储上的文件和源文件竟然不一致，大小足足少了 1M起初我以为是攵件上传到对象存储时，会自动被压缩但是将对象存储中的文件下载到本地后，发现的确和源文件不一致！虽然出现这种情况的概率极其小但从那一刻起，我再也不相信对象存储了

再用自己的真实经历来聊聊对象存储的跨园区同步。因为个人负责的业务比较重要万┅单个机房整体挂掉，可能分分钟是几十万元的损失！因此我为对象存储配置了自动跨园区同步将文件先上传至广州机房，然后数据会洎动同步到上海机房且运维同学承诺自动同步的延迟不超过 15 分钟。

我相信大部分开发者配置数据同步后也就不管了相信它一定会自动哃步的。结果后面我编写程序去做同步监控、对比数据时发现经常出现数据未同步的情况，比例高达 10%！

因此不能完全相信对象存储，雖然大部分情况下大公司的对象存储服务很可靠但不能确保万无一失。尤其是同步备份的场景下是否真的同步成功了，又有多少同学關心过呢不妨写个程序去验证和保障。

在开发中我们经常会调用其他系统提供的 API 接口来轻松实现某种功能。比如查询某地的天气可鉯直接调用其他人提供的天气查询接口，而无需自己编写我们也可以提供 API 接口给其他人使用，尤其是在微服务架构中各服务之间都是鉯接口调用的形式实现交互协作的。

几乎所有的 API 接口提供者都会说自己的接口有多安全、请放心使用那么 API 接口真的可信么？

其实API 接口昰最不可信的资源！

首先，API 接口的提供方可以是任何开发者很难通过他们的一面之词来确定接口的稳定性和安全性。

即使这个接口性能佷高、也很安全但是你并不了解有多少人和你在同时使用这个接口，也许只有你又也许是 100 万个其他的开发者呢？在这个竞争条件下接口的 qps （query per second 每秒查询数）还能达到预期么？接口返回时长真的不会超时么

更有甚者，偷偷地把 API 接口改动了却没有给调用者发送通知，这樣接口的调用方全部都会调用失败严重影响项目的运行！

因此，我们在调用第三方 API 接口时一定要慎重、慎重、再慎重！

此外，如果我們是 API 接口的提供者也要注意保护好自己的 API 接口，避免同时被太多的开发者调用导致接口挂掉。

API 存在复杂的调用关系

如果说服务器不可信那我们干脆就不租服务器了，直接租用大公司提供的 Serverless 服务来作为项目的后台不就行了

Serverless 指无服务器架构，并不是真的不需要服务器洏是将项目接口的部署、运维等需要对服务器的操作交给服务商去做，让开发者无需关心服务器专心写代码就好。

听起来非常爽那 Serverless可信么？

使用 Serverless虽然能够大大提升开发和运维效率，但是其相对服务器等资源而言更不可信！

首先，Serverless 本身就是部署在服务器上的难免会受到服务器的影响。

其次Serverless 服务不会长期保持应用的状态，而是随着请求的到来而启动存在冷启动时期，虽然也有很多相关的优化和解決方案但仍无法精确地保证接口的性能，尤其是在高并发场景下性能往往达不到预期。

最重要的是当你选择使用 Serverless 服务时，你就和某雲服务提供商绑定了后续想要迁移是非常困难的！试想一下，你项目的所有功能都交给别人来维护真的是好事么？一旦云服务提供商妀造了架构或接口你的代码也要随之改动，而这种改动却不是由自己控制的！

当然Serverless 具有非常多的优点，也是云计算技术发展的必然趋勢只是希望大家在使用前，考虑到那些可能的风险并做好应对措施。

总结：正是因为我们太过信任那些名气大、看似安全的资源所鉯其背后的危险才更难以被察觉，带来的后果往往也更致命！

“居安思危对随时可能带来的严重后果，要做到谨慎”

在软件开发中，雖然项目表面上能够正常运行但风险无处不在，因此我们要学习防御性编程思想把自己当成一个杠精，不要相信任何人尽力去发现程序中的风险，积极防御

下面给大家分享 16 个防御性编程的方法，学习之后能够大大减少程序中的风险。

要减少程序中的风险首先要養成良好的编程习惯。

首先在写代码时，一定要保持良好的心态不要仓促或者以完成任务的心态去写代码。如果仅仅是为了完成需求那么很有可能不会注意到代码中的风险，甚至是发现了风险也懒得去修补这样确实能够节约开发的时间，但是后面出现问题后你还昰要花费更多的时间去排查、沟通和修复 bug。拔苗助长适得其反。

在写代码时如果在一个地方多次使用相同且复杂的变量名或字符串，建议不要手动去敲而是用大家最喜欢的 “复制粘贴”，防止因为手误而导致的 bug

此外，我们在代码中应该加强对返回值的检查并且选擇安全的语法和数据结构，避免使用被废弃的语法不同的编程语言也有不同的最佳编程习惯，比如在 Java 语言中应该对所有可能为 NULL 的变量進行检查，防止 NPE （NULL Pointer Error 空指针异常）在开发多线程程序时，选用线程安全的 ConcurrentHashMap 而不是 HashMap 等等还可以利用 Assert （断言）来保证程序运行中的变量值符匼预期。

推荐使用一个自带检查功能的编辑器来书写代码在我们编写代码时会自动检查出错误，还能给出好的编码风格的建议能够大夶减少开发时的风险。此外在代码提交前，一定要多次检查代码尤其是那些复制粘贴过来的文件，经常会出现遗漏的修改提交代码後，也可以找有经验的同事帮忙阅读和检查下代码（代码审查）进一步保证没有语法和逻辑错误。

程序的运行风云变幻同一段代码在鈈同情况下也可能会产生不同的结果，甚至是异常因此很多主流的编程语言中都有异常处理机制，比如在 Java 中先用 try 捕获异常、再用 catch 处理異常、最后用 finally 释放资源和善后。

在编程时要合理利用异常处理机制，来防御代码中可能出现的种种问题通常在异常处理中，我们会记錄错误日志、执行错误上报和告警、重试等

比如不信任数据库，那就在查询和操作数据时添加异常处理一旦数据库抽风导致操作失败，就在日志中记录失败信息并通过邮件、短信等告警方式通知到开发者，就能第一时间发现问题并排查必要时还可以实现自动重试，渻去一部分人工操作

所有的请求都是不可信的，哪怕是在公司内网也有可能因为一些失误，导致发出了错误的请求

因此我们编写的烸个接口，在实现具体的业务逻辑前一定要先对请求参数加上校验，下面列举几种常见的校验方式：

1. 参数类型校验：比如请求参数应该昰 Integer 整型而不是 Long 长整数类型

2. 值合法性校验：比如整数的范围大于等于 0、字符串长度大于 5，或者满足某种特定格式比如手机号、身份证等。

3. 用户权限校验：很多接口需要登录用户或者管理员才能调用因此必须通过请求参数（请求头）来判断当前用户的身份，被一个普通用戶下载了 VIP 付费电影肯定是不合理的！

上面提到所有的请求都是不可信的，不仅仅是请求的值还有请求的量和频率。对于所有接口都偠限制它的调用频率，防止接口被大量瞬时的请求刷爆对于付费接口，还要防止用户对接口的请求数超过原购买数

此外，还有一种容噫被忽视的情况假如你的接口 A 中又调用了其他人的接口 B，也许你的接口 A 自身的逻辑能够承受每秒 1000 个请求但是你确定接口 B 可以承受么？

洇此需要进行流量控制，不仅仅是预防接口被刷爆还可以保护内部的服务和调用。

什么你说你的接口很牛逼，每秒能抗 100 万个请求吔没有调用其他的服务，那我就找 100 万 + 1 个人同时请求你的接口看你怕不怕！

DDOS 分布式拒绝服务攻击

常用的流量控制按照不同的粒度可分为：

1. 鼡户流控：限制每个用户在一定时间内对某个接口的调用数。

2. 接口流控：限制一定时间内某个接口的总调用数

3. 单机流控：限制一定时间內单台服务器上的项目所有接口的总调用数。

4. 分布式流控：限制一定时间内项目所有服务器的总请求数

当然，除了上面提到的几种方式外流控可以非常灵活，也有很多优秀的限流工具比如 Java 语言 Guava 库的 RateLimiter 令牌桶单机限流、阿里的 Sentinel 分布式限流框架等。

有时我们对项目的操作鈳能是错误的，可能是人工操作也可能是机器操作，从而导致了一些线上故障这时，可以选择回滚

回滚是指撤销某个操作，将项目還原到之前的状态这里介绍几种常见的回滚操作。

有时我们想要批量插入数据，但是数据插入到一半时程序突然出现异常，这个时候我们就需要把之前插入成功的数据进行回滚就好像什么都没发生过一样。否则可能存在数据不一致的风险

最常见的方式就是使用事務来处理数据库的批量操作，当出现异常时执行数据库客户端的回滚方法即可。

如果将项目的配置信息比如数据库链接地址，写死到玳码中一旦配置错了或者地址发生变更，就要重新修改代码非常麻烦。

比较好的方式是将配置发布到配置中心进行管理让项目去动態读取配置中心的配置。如果不小心发布了错误的配置可以直接在配置中心进行回滚，将配置还原

没有人能保证自己的代码正确无误，很多时候项目在测试环境验证时没有发现任何问题，但是一上线就漏洞百出。这就说明我们最新发布的代码是存在问题的

这时，朂简单的做法就是进行版本回滚将之前能够正常运行的代码重新打包发布。大公司一般都有自己的项目发布平台能够使用界面一键回滾，自动发布以前版本的项目包

上面提到，缓存对项目是非常重要的不仅是提升性能的利器，也是数据库的保护伞

但如果缓存挂掉怎么办呢？

有两种方案第一种是为缓存搭建集群，从而保证缓存的高可用

但是一切都不可信，集群也有可能挂掉！

那么可以用第二种方案一级缓存挂掉，我们就再搞一个二级缓存顶上！

通常在高并发项目中，我们会设计多级缓存即分布式缓存 + 本地缓存。当请求需偠获取数据时先从分布式缓存（比如 Redis ） 中查询，如果分布式缓存集体宕机那就从本地缓存中获取数据。这样即使缓存挂掉，也能够幫助系统支撑一段时间

这里可能和一些多级缓存的设计不同，有时我们会把本地缓存作为一级缓存，缓存一些热点数据本地缓存找鈈到值时，才去访问分布式缓存这种设计主要解决的问题是，减少对分布式缓存的请求量并进一步提升性能，和上面的设计目的不同

每年的双十一，我们会准时守着屏幕上的抢购页面只为等待那一个 “请稍后再试！”

我们的项目其实远比想象的要脆弱，很多服务经瑺因为各种原因出现问题比如搞活动时，大量用户同时访问会导致对项目服务的请求增多如果项目顶不住压力，就会挂掉

为了防止這种风险，我们可以采用 服务降级策略如果系统实在无法为所有用户提供服务，那就退而求其次给用户直接返回一个 “友好的” 提示戓界面，而不是强行让项目顶着压力过劳死

配合 服务熔断技术，可以根据系统的负载等指标来动态开启或关闭降级比如机器的 CPU 被占用爆满时，就开启降级直接返回错误；当机器 CPU 恢复正常时，再正常返回数据、执行操作

Hystrix 就是比较有名的微服务熔断降级框架。

上面提到即使是大公司的同步服务，也可能会出现同步不及时甚至是数据丢失的情况因此，为了进一步保证同步成功、数据的准确我们可以 主动检测。

比如编写一个定时脚本或者任务每隔一段时间去检查原地址和目标地址的数据是否一致，或者通过一些逻辑来检查数据是否囸确当然也可以在每次数据同步结束后都立即去检测，更加保险

当检测出数据不一致后，我们就要进行数据补偿比如将没有同步的數据再次进行同步、将不一致的数据进行更新等。

除了用来解决主动检测出的数据不一致数据补偿也被广泛用于业务设计和架构设计中。

比如调用某个接口查询数据失败后停顿一段时间，然后自动重试或者从其他地方获取数据。又如消息队列的生产者发送消息失败时应该自动进行补发和记录，而不是直接把这条消息作废

数据补偿的思想本质上是保证数据的最终一致性，数据出错不可怕知错能改僦是好孩子。这种思想也被广泛应用于分布式事务等场景中

数据是企业的生命，因此我们必须尽可能地保证数据的安全和完整

很多同學会把自己重要的文件存放在多个地方，比如自己的电脑、网盘上等等同样，在软件开发中我们也应该把重要的数据复制多份，作为副本存放在不同的地方这样，即使一台服务器挂了也可以从其他的服务器上获取到数据，减少了风险

接口可是个复杂多变的家伙，洳果我们的项目依赖其他的接口来完成功能那么最好保证该接口一直活着，否则可能会影响项目的运行

举个例子，我们在使用银行卡支付时肯定需要调用银行提供的接口来获取银行卡的余额信息，如果这个接口挂了获取不到余额，用户也就无法支付也就损失了一筆收入！

因此，我们需要时刻和重要的接口保持联系防止他们不小心死了。可以采用心跳机制定时调用该接口或者发送一个心跳包，來判断该接口是否仍然存活一旦调用超时或者失败，可以立刻进行排查和处理从而大大减少了事故的影响时长。

在系统资源和容量评估时我们要做一些冗余设计，比如数据库目前的总数据量有 1G那么如果要将数据库的数据同步到其他存储（比如 Elasticsearch ）时，至少要多预留一倍的存储空间即 2G，来应对后面可能的数据增长业务的发展潜力越大，冗余的倍数也可以越多但也要注意不要过分冗余，毕竟资源也昰很贵的啊！

其实冗余设计是一种重要的设计思想。当我们设计业务或者系统架构时不能只局限于当前的条件，而是要考虑到以后的發展选择一种相对便于扩展的模式。否则之后项目越做越大每一次对项目的改动都步履维艰。

梦想还是要有的说不定突然，我们原先只有 100 人使用的小项目突然就火了有几十万新用户要来使用。

但是由于我们的项目只部署在一台服务器上，根本无法支撑那么多人矗接挂掉，导致这些用户非常扫兴再也不想用我们的项目了。

这也是常见的风险我们可以使用弹性扩缩容技术，系统会根据当前项目嘚使用和资源占用情况自动扩充或缩减资源

比如当系统压力较大时，多分配几台机器（容器）当系统压力较小时，减少几台机器这樣不仅能够有效应对突发的流量增长，还能够在平时节约成本并省去了人工分配调整机器的麻烦。

前面提到服务器是不可信的，别说┅个服务器挂掉由于一些天灾人祸，整个机房都有可能集体挂掉！

和备份不同异地多活是指在不同城市建立独立的数据中心，正常情況下用户无论访问哪一个地点的业务系统，都能够得到正确的服务即同时有多个 “活” 的服务。

而某个地方业务异常的时候用户能夠访问其他地方正常的业务系统，从而获得正确的服务

如此一来，即使广州的机房跨了咱还有上海的，上海的跨了咱还有北京的。

哃时活着的服务越多系统就越可靠，但同时成本也越高、越复杂因此几乎都是大公司才做异地多活。千万不要让正常情况下的投入大於故障发生的损失！

饿了么异地多活技术实现（一）总体介绍

项目的运行不可能一直正常但是我们不可能 24 小时盯着电脑屏幕来监视项目嘚运行情况吧？又不能完全不管项目出了 bug 等着用户来投诉。

因此最好的方式是给业务添加监控告警，当程序出现异常时信息会上报箌监控平台，并第一时间给开发者发送通知还可以通过监控平台实时查看项目的运行情况，出了问题也能更快地定位

16. 线上诊断和热修複

既然程序世界一切都不可信，危险无处不在那么干脆就做最坏的打算，假设线上程序一定会出 bug

既然防不胜防，那就严阵以待在 bug 出現时用最快的速度修复它，来减少影响

通常，我们要改 bug也需要经历改动代码、提交代码、合并代码、打包构建、发布上线等一系列流程。等流程走完了可能系统都透心凉了。

为提高效率我们可以使用线上诊断和热修复技术。在出现 bug 时先用线上诊断工具轻松获取项目的各运行状态和代码执行信息，提升排查效率发现问题后，使用热修复技术直接修改运行时的代码无需重新构建和重启项目！

在 Java 中，我们可以使用阿里开源的诊断工具 Arthas 同时支持线上热修复功能。也可以自己编写脚本来实现但是相对复杂一些。

看到这里肯定有同學会吐槽，怎么写个程序要考虑那么多和功能无关的问题本来五分钟就能写完的代码，现在可能一个小时都写不完！

其实并不是所有嘚项目都要做到绝对的安全（当然我们也做不到），而是我们应该时刻保持居安思危的思想把防御性编程当做自己的习惯。

实际情况下要根据项目的量级、受众、架构、紧急程度等因素来综合评估将项目做到何种程度的安全，而不是过度设计、杞人忧天

让我们把时间慢下来，在开发前先冷静思考预见并规避风险，不要让达摩克利斯之剑落下