什么是gcc#

gcc的全称是GNU Compiler Collection，它是一个能够编译多种语言的编译器。

最开始gcc是作为C语言的编译器（GNU C Compiler），现在除了c语言，还支持C++、java、Pascal等语言。

gcc工作流程#

• 预处理（—E）

  • 宏替换
  • 头文件展开
  • 去掉注释
  • .c文件变成了.i文件（本质上还是.c文件，只不过#include中的程序给链接进去）

• 编译（—S）

  • gcc调用不同语言的编译器
  • .i文件编程.s（汇编文件）
  • 生成汇编文件

• 汇编（-c）

  • .s文件转化成.o文件
  • 翻译成机器语言指令
  • 二进制文件

• 链接

  • .o文件变成可执行文件，一般不加后缀

预处理实际上是将头文件、宏进行展开。

编译阶段gcc调用不同语言的编译器。gcc实际上是个工具链，在编译程序的过程中调用不同的工具。

汇编阶段gcc调用汇编器进行汇编。汇编语言是一种低级语言，在不同的设备中对应着不同的机器语言指令，一种汇编语言专用于某种计算机体系结构，可移植性比较差。通过相应的汇编程序可以将汇编语言转换成可执行的机器代码这一过程叫做汇编过程。汇编器生成的是可重定位的目标文件，在源程序中地址是从0开始的，这是一个相对地址，而程序真正在内存中运行时的地址肯定不是从0开始的，而且在编写源代码的时候也不能知道程序的绝对地址，所以重定位能够将源代码的代码、变量等定位为内存具体地址。

链接过程会将程序所需要的目标文件进行链接成可执行文件。

gcc常用参数#

• -v/—version：查看gcc的版本
• -I：编译的时候指定头文件路径，不然头文件找不到
• -c：将汇编文件转换成二进制文件，得到.o文件
• -g：gdb调试的时候需要加
• -D：编译的时候指定一个宏（调试代码的时候需要使用例如printf函数，但是这种函数太多了对程序性能有影响，因此如果没有宏，则#ifdefine的内容不起作用）
• -wall：添加警告信息
• -On：-O是优化代码，n是优化级别：1，2，3

静态库和动态库#

1. 什么是库？

   • 库是写好的现有的，成熟的，可以复用的代码。

   • 现实中每个程序都要依赖很多基础的底层库，不可能每个人的代码都从零开始，因此库的存在意义非同寻常。

   • 库是二进制文件，.o文件

   • 将源代码变成二进制的源代码

   • 主要起到加密的作用，为了防止泄露

2. 静态库的制作

   • 原材料：源代码（.c或.cpp文件）

   • 将.c文件生成.o文件（ex：g++ a.c -c）

   • 将.o文件打包

     • ar rcs 静态库名称 原材料(ex: ar rcs libtest.a a.0)

   • 态库的使用

   

3. 动态库的制作(so代表动态库)

   • 命名规则：libxxx.so
   • 制作步骤
     • 将源文件生产.o文件（gcc a.c -c -fpic）
     • 打包（gcc -shared a.o -o libxxx.so）
   • 动态库的使用
     • 跟静态库一样
   • 动态库无法加载的问题
     • 使用环境变量（临时设置和全局设置）

gdb相关问题#

• gdb 不能显示代码（No symbol table is loaded. Use the “file” command）
  • 要是用-g 比如： g++ map_test.cpp -g -o mao

linux权限相关问题#

对任意一个文件使用ls -l命令，如下图所示：

任意取一行，如：drwxr-xr-x 2 root root 4096 2009-01-14 17<34> bin

用序列表示为：0123456789

• 第一列

  • d：代表目录
  • -：代表文件
  • l：代表链接，如同windows的快捷方式

• 第一到九列

  • r：可读
  • w：可写
  • x：可执行文件
  • 0：代表文件类型
  • 123：表示文件所有者的权限
  • 456：表示同组用户的权限
  • 789：表示其他用户的权限

• 权限的数字表示

  • 读取的权限等于4，用r表示
  • 写入的权限等于2，用w表示
  • 执行的权限等于1，用x表示

• 改变文件权限命令

  chmod 权限数字（如777） filename

• 改变目录下所有的文件的权限命令

  chmod -R 权限数字（如777） 目录(如/home)

套接字类型#

下面是创建套接字所用的socket所用的函数

1
#include<sys/socket.h>
2
int socket(int domain,int type,int protocol);

• 协议簇（Protocol Family）（int domain）

  套接字有许多不同的通信协议分类，由socket函数第一个参数进行传递。其中最重要的是PF_INET（IPv4互联网协议族）

• 套接字类型（Type）（int type）

  socket函数的第二个参数决定套接字数据传输的方式。

  协议族并不能决定数据传输方式，因为一个协议族也有很多数据传输方式

  • 面向连接的套接字（SOCK_STREAM）

    面向连接的套接字类似于传送带

    

    有如下特点

    1. 传输的过程中数据不会丢失
    2. 按需传送数据
    3. 传输数据不存在数据边界问题
    4. 两端套接字必须一一对应

    收发的套接字内部有缓冲，就是有字节数组。因此通过套接字传输的数据将保存在数组，因此数据可以填满缓冲一次被读取，也可以分段被读取，不存在数据边界问题。当缓冲区占满后，套接字无法接受数据，停止传输。所以不存在数据丢失问题

  • 面向消息的套接字（SOCK_DGRAM）

    面向消息的套接字类似于快递

    有如下特点

    1. 强调快速传送而非顺序传送
    2. 传输的数据可能丢失也可能损坏
    3. 传输的数据有边界
    4. 限制每次传输的数据大小

• 协议信息（int protocol）

  由于socket函数前两个参数的存在，大部分情况可以向第三个参数传递0。但若同一个协议族中存在多个数据传输方式相同的协议，即数据传输方式相同，协议不同，需要第三个参数制定具体协议

  1
  //IPv4中面向连接的套接字
  2
  int tcp_socket=(PF_INET,SOCK_STREAM,IPPROTO_TCP)
  3
  //IPv4中面向消息的套接字
  4
  int tcp_socket=(PF_INET,SOCK_STREAM,IPPROTO_UDP)

实现基于TCP/IP的客户端服务端#

• TCP服务端默认函数调用顺序

  1. socket() 创建套接字
  2. bind() 分配套接字地址
  3. listen() 等待连接请求状态
  4. accpet() 允许连接
  5. read()/write() 交换数据
  6. close() 断开连接

• TCP客户端默认函数调用顺序

  1. socket() 创建套接字

  2. connect() 请求连接

  3. read()/write() 交换数据

  4. close() 断开连接

     实现服务器端重要/必经过程就是给套接字分配IP和端口号（bind），但是客户端实现过程并未出现套接字的分配，而是创建套接字后立即调用了connect函数，为什么？

     答：客户端其实是分配了IP和端口号的。在调用connect的时候分配的（何时），在操作系统内核中进行分配（何地），IP用的是主机的IP，端口号随机分配（何种方式）

• 注意事项

  • 服务器端创建套接字后连续调用bind、listen函数进入等待状态，客户端通过connect函数发起连接请求
  • 客户端只能等到服务端调用listen后才能调用connect函数
  • 客户端调用connect函数前，服务器可能率先调用accept函数，然后服务端进入阻塞状态，直到客户端调用connect为止

• TCP套接字中的I/O缓冲

  write函数调用后并不是立刻传送数据，read函数调用后也不是马上接收数据。而是将这些数据移到输入和输出缓冲中

  如下图所示：

  

  I/O缓冲有以下特点：

  1. I/O缓冲在每个TCP套接字中单独存在
  2. I/O缓冲在创建套接字时自动生成
  3. 即使关闭套接字也会继续传递输出缓冲中遗留的数据
  4. 关闭套接字将丢失输入缓冲中的数据

• 套接字的断开

  close()函数表示完全断开套接字链接，并且不能收发任何数据。很显然这样做是不好的，若A主机断开连接后，完全无法调用接收数据和发送数据相关函数，这会导致B向A发送数据，A必须接受的数据也被销毁

  套接字中会生成两个I/O流，如下图：

​ 一旦两台主机间建立了套接字链接，每个主机就会拥有单独的输入流和输出流

Linux操作系统中断#

• 中断概念

  中断是指在CPU正常运行期间，由于内外部事件或由程序预先安排的事件引起的CPU暂时停止正在运行的程序，转而为该内部或外部事件或预先安排的事件服务的程序中去，服务完毕后再返回去继续运行被暂时中断的程序。这样的中断机制极大的提高了CPU运行效率。

  根据CSAPP中所描述，中断是异常的一种类别。（p504）什么是异常？比如说在处理器中，依次执行对应的指令流程，这样的控制转移序列叫做控制流。但是系统会出现一些变化，系统必须对这种变化做出反应，而且这种变化是随机的，也不一定跟执行当前的程序关联，比若说子进程终止时父进程必须得到通知，硬盘定时器定期产生一个信号。这种叫做控制流发生突变，这些突变成为异常控制流。计算机的各个层次都会发生异常。(p502)

  异常可以分为：中断、陷阱、故障、终止

  类别	原因	同步/异步	返回行为
  中断	来自I/O设备的信号	异步	总是返回到下一条指令
  陷阱	有意的异常	同步	总是返回到下一条指令
  故障	潜在可恢复的错误	同步	可能返回到当前指令
  终止	不可恢复的错误	同步	不会返回

• 硬中断

  硬中断是我们通常所说的中断的概念。硬中断是由硬件产生的，比如，像磁盘，网卡，键盘，时钟等。每个设备或设备集都有它自己的IRQ（中断请求）。内核中维护了一个IDT（中断描述符表），表中是中断处理函数的地址和一些其他的控制位。0-31号中断号位系统为预定义的中断和异常保留的，用户不得使用，所以硬件中断号从32开始分发。每当CPU接收到一个中断或者异常信号，CPU首先要做的决定是否响应这个中断（具体由中断控制器根据中断优先级决定是否给CPU发送中断信号），如果决定响应，就终止当前运行进程的运行，根据IDTR寄存器获取中断描述符表基地址，然后根据中断号定位具体的中断描述符。

• 软中断

  软中断是由当前正在运行的进程所产生的。 软中断并不会直接中断CPU。这种中断是一种需要内核为正在运行的进程去做一些事情（通常为I/O）的请求。

  中断在本质上是软件或者硬件发生了某种情形而通知处理器的行为，处理器进而停止正在运行的指令流，去转去执行预定义的中断处理程序。软件中断也就是通知内核的机制的泛化名称，目的是促使系统切换到内核态去执行异常处理程序。这里的异常处理程序其实就是一种系统调用，软件中断可以当做一种异常。总之，软件中断是当前进程切换到系统调用的过程。

系统调用知识点#

对事件的两种处理方式#

preactor#

在 Reactor 模式中，Reactor 等待某个事件或者可应用或者操作的状态发生（比如文件描述符可读写，或者是 Socket 可读写）。 然后把这个事件传给事先注册的 Handler（事件处理函数或者回调函数），由后者来做实际的读写操作。 其中的读写操作都需要应用程序同步操作，所以 Reactor 是非阻塞同步网络模型。 如果把 I/O 操作改为异步，即交给操作系统来完成就能进一步提升性能，这就是异步网络模型 Proactor。

preactor模型如下图所示：

工作流程如下：

1. Proactor Initiator 负责创建 Proactor 和 Handler 对象，并将 Proactor 和 Handler 都通过 Asynchronous Operation Processor 注册到内核；
2. Asynchronous Operation Processor 负责处理注册请求，并处理 I/O 操作；
3. Asynchronous Operation Processor 完成 I/O 操作后通知 Proactor；
4. Proactor 根据不同的事件类型回调不同的 Handler 进行业务处理；
5. Handler 完成业务处理；

理论上 Proactor 比 Reactor 效率更高，异步 I/O 更加充分发挥 DMA(Direct Memory Access，直接内存存取)的优势。 但是Proactor有如下缺点：

1. 编程复杂性，由于异步操作流程的事件的初始化和事件完成在时间和空间上都是相互分离的，因此开发异步应用程序更加复杂。应用程序还可能因为反向的流控而变得更加难以 Debug；
2. 内存使用，缓冲区在读或写操作的时间段内必须保持住，可能造成持续的不确定性，并且每个并发操作都要求有独立的缓存，相比 Reactor 模式，在 Socket 已经准备好读或写前，是不要求开辟缓存的；
3. 操作系统支持，Windows 下通过 IOCP 实现了真正的异步 I/O，而在 Linux 系统下，Linux 2.6 才引入，目前异步 I/O 还不完善。
4. Reactor处理耗时长的操作会造成事件分发的阻塞，影响到后续事件的处理；

可惜的是，在 Linux 下的异步 I/O 是不完善的， aio 系列函数是由 POSIX 定义的异步操作接口，不是真正的操作系统级别支持的，而是在用户空间模拟出来的异步，并且仅仅支持基于本地文件的 aio 异步操作，网络编程中的 socket 是不支持的，这也使得基于 Linux 的高性能网络程序都是使用 Reactor 方案。

而 Windows 里实现了一套完整的支持 socket 的异步编程接口，这套接口就是 IOCP，是由操作系统级别实现的异步 I/O，真正意义上异步 I/O，因此在 Windows 里实现高性能网络程序可以使用效率更高的 Proactor 方案。

文件(不带缓存的)I/O和标准(带缓存的)I/O#

​ 首先要明确一个问题：有无缓存是相对于用户层面来说的，而不是系统内核层面。在系统内核层面，一直都存在有“内核高速缓存”

• 不带缓存的概念

  所谓不带缓存，并不是指内核不提供缓存，而是在用户进程层次没有提供缓存。不带缓存的I/O只存在系统调用(write和read函数)，不是函数库的调用。系统内核对磁盘的读写都会提供一个块缓冲（在有些地方也被称为内核高速缓存），当用write函数对其写数据时，直接调用系统调用，将数据写入到块缓存进行排队，当块缓存达到一定的量时，才会把数据写入磁盘。因此所谓的不带缓存的I/O是指用户进程层面不提供缓存功能（但内核还是提供缓冲的）。

  文件I/O以文件标识符（整型）作为文件唯一性的判断依据。这种操作与系统有关，移植有一定的问题。

• 带缓存的概念

  与之相对的就是带缓存I/O。而带缓存的是在不带缓存的基础之上封装了一层，在用户进程层次维护了一个输入输出缓冲区，使之能跨OS，成为ASCI标准，称为标准IO库。其实就是在用户层再建立一个缓存区，这个缓存区的分配和优化长度等细节都是标准IO库代你处理好了，不用去操心。第一次调用带缓存的文件操作函数时标准库会自动分配内存并且读出一段固定大小的内容存储在缓存中。所以以后每次的读写操作并不是针对硬盘上的文件直接进行的，而是针对内存中的缓存的。

  不带缓存的文件操作通常都是系统提供的系统调用， 更加低级，直接从硬盘中读取和写入文件，由于IO瓶颈的原因，速度并不如意，而且原子操作需要程序员自己保证，但使用得当的话效率并不差。另外标准库中的带缓存文件IO 是调用系统提供的不带缓存IO实现的。

  • 因此，标准I/O函数有两个优点：

    ​ 1. 具有良好的移植性

    ​ 2. 利用用户层提供的缓存区（流缓冲）提高性能

  • 标准I/O函数缺点

    1. 不容易进行双向通信
    2. 有时可能频繁调用fflush函数
    3. 需要以FILE结构体指针的形式返回文件描述符

• 举例说明

  **带缓冲的I/O在往磁盘写入相同的数据量时，会比不带缓冲的I/O调用系统调用的次数要少。**比如内核缓冲存储器长度为100字节，在进行写操作时每次写入10个字节，则你需要调用10次write函数才能把内核缓冲区写满。但是要注意此时数据还在缓冲区，不在磁盘中，缓冲区满时才进行实际的I/O操作，把数据写入到磁盘，这样调用了太多次系统调用，显得效率很低。但是若调用标准I/O函数，假设用户层缓冲区为50字节（称为流缓存），则用fwrite将数据写入到流缓存，等到流缓存区存满之后再进入内核缓存区，在调用write函数将数据写入到内核缓冲区中，若内核缓冲区满或执行fflush操作，那么内核缓冲区的数据会写入到磁盘中

  • 无缓存IO操作数据流向路径：数据——内核缓存区——磁盘
  • 标准IO操作数据流向路径：数据——流缓存区——内核缓存区——磁盘

• apue三种io的总结

  在apue中有三种io类型，如下：

  1. 文件I/O（不带缓冲的I/O）：open、read、write、lseek、close
  2. 标准I/O（带缓冲的I/O）：标准I/O库由ISO C标准说明
  3. 高级I/O：非阻塞I/O、I/O多路转接、异步I/O、readv和writev

阻塞非阻塞，同步异步的区别#

参考

参考2，这个比较符合我的想法

进程通讯层面，阻塞就是同步，非阻塞就是异步，一个意思

IO层面，就不一样。要记住，IO操作只有两个阶段：

1. 数据准备阶段
2. 内核缓冲区（内核空间）复制数据到用户进程缓冲区（用户空间）阶段

对于数据准备阶段，是阻塞和非阻塞的层面。对于数据从内核转移到用户空间，就是同步异步阶段。

阻塞和非阻塞的区别在于内核数据还没准备好时，用户进程在一阶段数据准备时是否会阻塞；

同步IO与异步IO的区别在于当数据从内核copy到用户空间时，用户进程是否会阻参与第二阶段的数据读写，是由用程序完成还是由内核完成。

对于套接字socket的理解#

这里我类比一下插座和套接字，为什么这样类比呢？因为套接字的中文有插座的含义…

电器如何才能供电？电器需要连接上电网。如何连接到电网？需要把电器插销插到插座上，通过插座连接到电网，这样电器就有电可以工作

计算机如何收发消息？计算机需要连接上互联网。如何连接互联网？硬件层面我们可以拉一根网线，软件层面需要套接字。通过套接字连接到互联网，进而可以和互利网上的所有主机进行通信。

socket 其实就是操作系统提供给程序员操作「网络协议栈」的接口，说人话就是，你能通过socket 的接口，来控制协议找工作，从而实现网络通信

C++网络通信中send和receive的为什么会阻塞#

使用tcp协议进行通讯的双方，都各自有一个发送缓冲区和一个接收缓冲区。而缓冲区是有大小的，因此发生阻塞的本质原因是缓冲区满了，别的字节流消息无法进入缓冲区。

send函数只是将内存中的数据拷贝到内核中tcp的发送缓冲区或者说写缓冲区，但是什么时候发送数据是send无法控制的。同时tcp是一个可靠传输协议，发送端必须收到确认报文信息后才会清空发送缓冲区中的内容。对于读缓冲区来，收到数据放到自己的读缓冲区，同时要给发送端发送一个确认消息表明自己收到了信息。这个时候如果读缓冲区的数据被填满，由于滑动窗口协议，导致接收端不在读取数据，进而写缓冲区也会阻止发送数据。这个时候write函数就会阻塞。总结：接收端接收数据的速度小于发送端发送数据的速度，导致接收端的读缓冲区填满，接收端发送报文给发送端告诉他我已经满了，先别发。这样发送端的写缓冲区被占满了，导致阻塞

receive阻塞是因为读缓冲区中没数据。

记住，send是等到写缓冲区被填满之后才发送，但是write只要发现读缓冲区有数据，就将数据拷贝。

send和receive在阻塞和非阻塞模式下的表现#

1
//第一个参数：指定发送端套接字
2
//第二个参数：指明需要发送数据的缓冲区
3
//第三个参数：指明实际发送的数据的字节
4
//第四个参数：一般不写。可以临时设置为非阻塞
5
int send( SOCKET s, const char *buf, int len, int flags );
6

7
//第一个参数：指定接收端文件描述符
8
//第二个参数：指明一个缓冲区，存放接受来的数据
9
//第三个参数：指明缓冲区的长度
10
//第四个参数：一般不写。可以临时设置为非阻塞
11
int recv( SOCKET s, char *buf, int len, int flags);

• recv和send两种模式设置

  对于一个socket是阻塞还是非阻塞有两种方式来处理：

  1. 用fcntl函数

     1
     flags = fcntl(sockfd, F_GETFL, 0);                        //获取文件的flags值。
     2
     fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);          //设置成非阻塞模式；
     3
     fcntl(sockfd,F_SETFL,flags&~O_NONBLOCK);          //设置成阻塞模式；

  2. 将recv和send函数的最后一个flag 参数设置成MSG_DONTWAIT

     注意！这种方法是临时的，不管之前是否阻塞

     1
     recv(sockfd, buff, buff_size,MSG_DONTWAIT);     //非阻塞模式的消息发送
     2
     send(scokfd, buff, buff_size, MSG_DONTWAIT);   //非阻塞模式的消息接受

• 整体来看

  • 当socket处于阻塞模式时,继续调用send/recv函数,程序会阻塞在send/recv调用处
  • 当socket处于非阻塞模式时,继续调用send/recv函数,会返回错误码

• 阻塞和非阻塞条件下read/recv的区别

  阻塞和非阻塞的区别在于没有数据到达的时候是否立刻返回

  读或者收的本质是从底层缓冲的数据copy到我们制定的buffer中

  • 阻塞条件下

    1. 如果读缓冲区中没有数据会一直等待

    2. 如果读缓冲区有数据，则会把数据读到用户指定的缓冲区。如果读取的数据量比函数参数中指定的长度要小，read会返回读到的数据长度。

       一般情况下我们都需要采取循环读的方式读取数据

  • 非阻塞条件下

    1. 如果没有数据直接返回EWOULDBLOCK
    2. 读缓冲区有数据，有多少读多少

• 阻塞和非阻塞条件下send/write的区别

  写或者发的本质是把buffer(用户态)中的数据copy到内核态，然后就返回了。发送操作是由系统底层和tcp协议进行。send返回成功，表示数据已经copy到底层缓冲区，而不是表示数据已经发送

  • 阻塞情况下

    一直等待，直到write将数据发送完(发送过程中可能会中断)。

    读的时候我们并不知道是否有数据，以及数据是何时结束发送，如果一直等待就会造成死循环

    对于写由于长度是已知的，所以可以随便写，直到写完。不过写会被打断，造成一次write只能写一部分，可以用循环write。

  • 非阻塞情况下

    对于本地网络阻塞的情况来说，写缓冲区没有足够的内存来存储buf中的数据，因此会出现写不成功的情况。非阻塞不会等到数据全部发送再返回，而是写多少算多少，

    返回值是WSAEWOULDDBLOCK

• write和read返回值详解

IO多路复用#

IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备读取，它就通知该进程。IO多路复用适用如下场合：

1. 当客户处理多个描述字时（一般是交互式输入和网络套接口），必须使用I/O复用。
2. 如果一个TCP服务器既要处理监听套接口，又要处理已连接套接口，一般也要用到I/O复用。
3. 如果一个服务器即要处理TCP，又要处理UDP，一般要使用I/O复用。
4. 如果一个服务器要处理多个服务或多个协议，一般要使用I/O复用。

与多进程和多线程技术相比，I/O多路复用技术的最大优势是系统开销小，系统不必创建进程/线程，也不必维护这些进程/线程，从而大大减小了系统的开销。

1
int epoll_create(int size);
2
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
3
int epoll_wait(int epfd, struct epoll_event *events,int maxevents, int timeout);

tcp 在调用connect失败后要不要重新socket？#

connect（套接字默认阻塞）出错返回的情况：

1. 调用connect时内核发送一个SYN分节，若无响应则等待6s后再次发送一个，仍无响应则等待24s再发送一个，若总共等了75s后仍未收到响应则返回ETIMEDOUT错误；

2. 若对客户的SYN的响应是RST，则表示该服务器主机在我们指定的端口上面没有进程在等待与之连接，例如服务器进程没运行，客户收到RST就马上返回ECONNREFUSED错误；

3. 若客户发出的SYN在中间的某个路由上引发了一个“destination unreachable”（目的不可达）ICMP错误，客户主机内核保存该消息，并按1中所述的时间间隔发送SYN，在某个规定的时间（4.4BSD规定75s）仍未收到响应，则把保存的ICMP错误作为EHOSTUNREACH或ENETUNREACH错误返回给进程。

若connect失败则该套接字不再可用，必须关闭，我们不能对这样的套接字再次调用connect函数。在每次connect失败后，都必须close当前套接字描述符并重新调用socket。

Linux零拷贝技术#

splice( )函数

tee( )函数

由来：#

如果服务端要提供文件传输的功能，我们能想到的最简单的方式是：将磁盘上的文件读取出来，然后通过网络协议发送给客户端。传统 I/O 的工作方式是，数据读取和写入是从用户空间到内核空间的复制，而内核空间的数据是通过操作系统层面的 I/O 接口从磁盘读取或写入。其过程如下图所示：

可以想想一下这个过程。服务器读从磁盘读取文件的时候，发生一次系统调用，产生用户态到内核态的转换，将磁盘文件拷贝到内核的内存中。然后将位于内核内存中的文件数据拷贝到用户的缓冲区中。用户应用缓冲区需要将这些数据发送到socket缓冲区中，进行一次用户态到内核态的转换，复制这些数据。此时这些数据在内核的socket的缓冲区中，在进行一次拷贝放到网卡上发送出去。

所以整个过程一共进行了四次拷贝，四次内核和用户态的切换。这种简单又传统的文件传输方式，存在冗余的上文切换和数据拷贝，在高并发系统里是非常糟糕的，多了很多不必要的开销，会严重影响系统性能。

accept()、connect()发生在三次握手的哪一步？#

看上图就很明白了，刚准备发SYN同步报文时候，connect函数阻塞，然后服务端收到SYN同步报文的时候，调用accept()阻塞，服务器发送SYN+ACK给客户端，此时connect连接上就返回了，然后等服务器收到ACK报文时，accept也返回。

所以只说返回状态的话connect成功返回是在第二步，accept成功返回是在第三步

accept的队列#

处于“LISTENING”状态的TCP socket，有两个独立的队列：

1. SYN队列(SYN Queue)
2. Accept队列(Accept Queue)

SYN队列

SYN队列存储了收到SYN包的连接(对应内核代码的结构体： struct inet_request_sock)。它的职责是回复SYN+ACK包，并且在没有收到ACK包时重传，直到超时。发送完SYN+ACK之后，SYN队列等待从客户端发出的ACK包(也即三次握手的最后一个包)。当收到ACK包时，首先找到对应的SYN队列，再在对应的SYN队列中检查相关的数据看是否匹配，如果匹配，内核将该连接相关的数据从SYN队列中移除

accept队列

内核将该连接相关的数据从SYN队列中移除，创建一个完整的连接(对应内核代码的结构体： struct inet_sock )，并将这个连接加入Accept队列。Accept队列中存放的是已建立好的连接，也即等待被上层应用程序取走的连接。当进程调用accept()，这个socket从队列中取出，传递给上层应用程序。一般来说都是select或者epoll上有事件发生时再取走

调用close()在哪一步？#

首先注意EOF这个东西。当客户端调用close主动断开时，会在FIN报文后面放入一个文件结束符EOF，会放在服务器端读缓存队列的最后，当接收到EOF时，服务器需要处理这种异常情况，表示以后不会有任何数据到达。因此服务器会返回一个ACK确认报文然后进入closed_wait状态

等服务器处理完后，发送FIN报文后也调用close。

Posix 信号量与System v信号量的区别#

参考

参考

参考

Posix<是>“可移植操作系统接口（Portable Operating System Interface ）的首字母简写，但它并不是一个单一的标准，而是一个电气与电子工程学会即IEEE开发的一系列标准，它还是由ISO（国际标准化组织）和IEC（国际电工委员会）采纳的国际标准。

System v是Unix操作系统众多版本的一个分支，它最初是由AT&T在1983年第一次发布，System v一共有四个版本，而最成功的是System V Release 4，或者称为SVR4。这样看来，一个是Unix 的标准之一（另一个标准是Open Group），一个是Unix众多版本的分支之一（其他的分支还有Linux跟BSD），应该来说，Posix标准正变得越来越流行，很多厂家开始采用这一标准。

区别如下：

1. System v信号量指的是计数信号量集；Posix 信号量指的是单个计数信号量。
2. Posix信号量是基于内存的，即信号量值是放在共享内存中的，它是由可能与文件系统中的路径名对应的名字来标识的。System v信号量测试基于内核的，它放在内核里面，相同点都是它们都可以用于进程或者线程间的同步。
3. POSIX信号量常用于线程；system v信号量常用于进程的同步。
4. POSIX 信号量的头文件是 <semaphore.h>，而 System V 信号量的头文件是 <sys/sem.h>。

信号通知流程和处理机制#

Linux下的信号采用的异步处理机制，信号处理函数和当前进程是两条不同的执行路线。具体的，当进程收到信号时，操作系统会中断进程当前的正常流程，转而进入信号处理函数执行操作，完成后再返回中断的地方继续执行。为避免信号竞态现象发生，信号处理期间系统不会再次触发它。所以，为确保该信号不被屏蔽太久，信号处理函数需要尽可能快地执行完毕。

一般的信号处理函数需要处理该信号对应的逻辑，当该逻辑比较复杂时，信号处理函数执行时间过长，会导致信号屏蔽太久。提供一种解决方案是，信号处理函数仅仅发送信号通知程序主循环，将信号对应的处理逻辑放在程序主循环中，由主循环执行信号对应的逻辑代码。

统一事件源

统一事件源，是指将信号事件与其他事件一样被处理。

具体的，信号处理函数使用管道将信号传递给主循环，信号处理函数往管道的写端写入信号值，主循环则从管道的读端读出信号值，使用I/O复用系统调用来监听管道读端的可读事件，这样信号事件与其他文件描述符都可以通过epoll来监测，从而实现统一处理。

信号处理机制如下图：

• 信号的接收

  • 接收信号的任务是由内核代理的，当内核接收到信号后，会将其放到对应进程的信号队列中，同时向进程发送一个中断，使其陷入内核态。注意，此时信号还只是在队列中，对进程来说暂时是不知道有信号到来的。

• 信号的检测

  • 进程从内核态返回到用户态前进行信号检测

  • 进程在内核态中，从睡眠状态被唤醒的时候进行信号检测

  • 进程陷入内核态后，有两种场景会对信号进行检测：

  • 当发现有新信号时，便会进入下一步，信号的处理。

• 信号的处理

  • ( 内核 )信号处理函数是运行在用户态的，调用处理函数前，内核会将当前内核栈的内容备份拷贝到用户栈上，并且修改指令寄存器（eip）将其指向信号处理函数。

  • ( 用户 )接下来进程返回到用户态中，执行相应的信号处理函数。

  • ( 内核 )信号处理函数执行完成后，还需要返回内核态，检查是否还有其它信号未处理。

  • ( 用户 )如果所有信号都处理完成，就会将内核栈恢复（从用户栈的备份拷贝回来），同时恢复指令寄存器（eip）将其指向中断前的运行位置，最后回到用户态继续执行进程。

• 至此，一个完整的信号处理流程便结束了，如果同时有多个信号到达，上面的处理流程会在第2步和第3步骤间重复进行。

服务器端有100万个TCP长连接，可能会出现的问题#

参考1

参考2

epoll是同步还是异步的？#

1. IO层面
2. 消息处理层面
3. 从IO层面来看,epoll绝对是同步的；
4. 从消息处理层面来看，epoll是异步的.

select，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的（可能通过while循环来检测内核将数据准备的怎么样了， 而不是属于内核的一种通知用户态机制），仍然需要read、write去读写数据。

用户线程定期轮询epoll文件描述符上的事件，事件发生后，读取事件对应的epoll_data，该结构中包含了文件fd和数据地址，由于采用了mmap，程序可以直接读取数据（epoll_wait函数）。有人把epoll这种方式叫做同步非阻塞（NIO），因为用户线程需要不停地轮询，自己读取数据，看上去好像只有一个线程在做事情。也有人把这种方式叫做异步非阻塞（AIO），因为毕竟是内核线程负责扫描fd列表，并填充事件链表的。个人认为真正理想的异步非阻塞，应该是内核线程填充事件链表后，主动通知用户线程，或者调用应用程序事先注册的回调函数来处理数据，如果还需要用户线程不停的轮询来获取事件信息，就不是太完美了，所以也有不少人认为epoll是伪AIO，还是有道理的。

原子操作的原理#

原子操作（atomic operation）意为”不可被中断的一个或一系列操作”

signal机制#

使用epoll或select时需要将socket设为非阻塞吗？#

先说结论：

需要的。但是一个 socket 是否设置为阻塞模式，只会影响到 connect/accept/send/recv 等四个 socket API 函数，不会影响到 select/poll/epoll_wait 函数，后三个函数的超时或者阻塞时间是由其函数自身参数控制的。

socket 是否被设置成阻塞模式对下列 API 造成的影响：

connfd：该端调用 connect 函数主动发起连接；

listenfd：调用 listen 函数发起侦听的一端（服务端）；即监听的socket

clientfd：调用 accept 函数接受连接，由 accept 函数返回的 socket（服务端）。即连接的socket

当connfd 被设置成阻塞模式时（默认行为，无需设置），connect 函数会一直阻塞到连接成功或超时或出错，超时值需要修改内核参数。当 connfd 被设置成非阻塞模式，无论连接是否建立成功，connect 函数都会立刻返回，那如何判断 connect 函数是否连接成功呢？接下来使用 select 和 epoll_wait 函数去判断 socket 是否可写即可，当然，Linux 系统上还需要额外加一步——使用 getsockopt 函数判断此时 socket 是否有错误(因为select中通知有数据达到但是可能数据error checksum或者discard了)，这就是所谓的异步 connect 或者叫非阻塞 connect。

当 listenfd 设置成阻塞模式（默认行为，无需额外设置）时，如果连接 pending(待办) 队列中有需要处理的连接，accept 函数会立即返回，否则会一直阻塞下去，直到有新的连接到来。当 listenfd 设置成非阻塞模式，无论连接 pending 队列中是否有需要处理的连接，accept 都会立即返回，不会阻塞。如果有连接，则 accept 返回一个大于 0 的值，这个返回值即是我们上文所说的 clientfd；如果没有连接，accept 返回值小于 0，错误码 errno 为 EWOULDBLOCK（或者是 EAGAIN，这两个错误码值相等）。

当 connfd 或 clientfd 设置成阻塞模式时：send 函数会尝试发送数据，如果对端因为 TCP 窗口太小导致本端无法将数据发送出去，send 函数会一直阻塞直到对端 TCP 窗口变大足以发数据或者超时；recv 函数则正好相反，如果此时没有数据可收获，recv函数会一直阻塞直到收取到数据或者超时，有的话，取到数据后返回。send 和 recv 函数的超时时间可以分别使用 SO_SNDTIMEO 和 SO_RCVTIMEO 两个 socket 选项来设置。当 connfd 或 clientfd 设置成非阻塞模式时，send 和 recv 函数都会立即返回，send 函数即使因为对端 TCP 窗口太小发不出去也会立即返回，recv 函数如果无数据可收也会立即返回，此时这两个函数的返回值都是 -1，错误码 errno 是 EWOULDBLOCK（或 EAGIN，与上面同）。

select/poll/epoll_wait 函数的等待或超时时间

select、poll、epoll_wait 函数的超时时间分别由传给各自函数的时间参数决定的，我们来看下这三个函数的签名：

1
int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
2
int poll(struct pollfd *fds, nfds_t nfds, int timeout);
3
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

三个函数最后一个参数是 timeout，只不过 select 函数的 timeout 参数的类型是一个结构体指针

select 函数的 timeout 参数含义有三种：

1. timeout 为 NULL 时，select 函数将一直阻塞下去，直到出错或者绑定其上的 socket 有事件；
2. 当 timeout->tv_sec 和 timeout->tv_usec 同时为 0 时，select 函数会检查一下绑定在其上的 socket 是否有事件，然后立刻返回；
3. 当 timeout->tv_sec 和 timeout->tv_usec 之和大于 0 时，select 函数检测到绑定其上的 socket 有时间才会返回或者阻塞时长为 timeout->tv_sec + timeout->tv_usec 。

poll 和 epoll_wait 函数的超时时间为毫秒，设置为 0，和 select 函数一样，检测一下绑定其上的 socket 是否有事件，然后立即返回。

为什么使用epoll时候需要将socket设置成阻塞的？

首先epoll 模型通常用于服务端，那讨论的 socket 只有 listenfd 和 clientfd 了。

对于listenfd，可以阻塞可以非阻塞。有很多的服务器程序结构确实采用的就是阻塞的 listenfd，为了不让 accept 函数在没有连接时阻塞对程序其他逻辑执行流造成影响，我们通常将 accept 函数放在一个独立的线程中。但是如果不在一个独立线程中获得listenfd的话，如果默认一个监听socket是阻塞的话，有如下场景：客户端通过connect向服务器发起三次握手，三次握手后触发select或者epoll上的事件，但是呢此时客户端发送过来RST报文取消了连接，而此时服务器端调用了accept接收了次连接区去内核队列中取时内核队列中是空的（因为该客户端连接被取消），那么服务器就会阻塞在accept调用，无法响应其他就绪的监听socket，所以我们要吧监听socket即listenfd也设置为阻塞的。

对于clientfd，主要涉及到的是读写的问题。当读取的数据很小，比如有个buffer是1024字节，读取的数据小于1024的话，水平边缘触发搭配阻塞和非阻塞其实都一样。那么很多时候我们接受的数据都很大，一个buffer装不下，就需要while循环多次读。那么这种情况水平触发模式显得很鸡肋，阻塞和非阻塞效果都一样。所以我们主要讨论的是边缘触发情况下clientfd的阻塞和非阻塞。首先是ET+阻塞的情况，当最后一个数据读取完后，程序是无法立刻跳出while循环的，因为阻塞IO会在 while(true){ int len=recv(); }这里阻塞住，除非对方关闭连接或者recv出错，这样程序就无法继续往下执行，因为我就绪的文件描述符都在等着处理，这一次的epoll_wait没有办法处理其它的连接，会造成延迟、并发度下降。其次的话select或者epoll返回可读，和recv去读，这是两个独立的系统调用，两个操作之间是有窗口的，也就是说 select 返回可读，紧接着去 read，不能保证一定可读。man select中说了数据到达了但是可能error checksum或者discard了，如果你用阻塞的，就阻塞了进行不下去，这显然不行。如果是ET+非阻塞IO的话，当读取完数据后，recv会立即返回-1，并将errno设置为EAGAIN或EWOULDBLOCK,这就表示数据已经读取完成，已经没有数据了，可以退出循环了。这样就不会像阻塞IO一样卡在那里，这就减少了不必要的等待时间，性能自然更高。

用过哪些linux命令？#

1
scp  local_file    remote_username@remote_ip:remote_file

1
find . -name '[A-Z]*.txt' -print

Linux惊群效应详解#

参考链接

**定义：**惊群效应（thundering herd）是指多进程（多线程）在同时阻塞等待同一个事件的时候（休眠状态），如果等待的这个事件发生，那么他就会唤醒等待的所有进程（或者线程），但是最终却只能有一个进程（线程）获得这个时间的“控制权”，对该事件进行处理，而其他进程（线程）获取“控制权”失败，只能重新进入休眠状态，这种现象和性能浪费就叫做惊群效应。

危害：

1. Linux 内核对用户进程（线程）频繁地做无效的调度、上下文切换等使系统性能大打折扣。上下文切换（context switch）过高会导致 cpu 像个搬运工，频繁地在寄存器和运行队列之间奔波，更多的时间花在了进程（线程）切换，而不是在真正工作的进程（线程）上面。直接的消耗包括 cpu 寄存器要保存和加载（例如程序计数器）、系统调度器的代码需要执行。间接的消耗在于多核 cache 之间的共享数据。
2. 为了确保只有一个进程（线程）得到资源，需要对资源操作进行加锁保护，加大了系统的开销。目前一些常见的服务器软件有的是通过锁机制解决的，比如 Nginx（它的锁机制是默认开启的，可以关闭）；还有些认为惊群对系统性能影响不大，没有去处理，比如 lighttpd

Linux 解决方案之 Accept

Linux 2.6 版本之前，监听同一个 socket 的进程会挂在同一个等待队列上，当请求到来时，会唤醒所有等待的进程。Linux 2.6 版本之后，通过引入一个标记位 WQ_FLAG_EXCLUSIVE，解决掉了 Accept 惊群效应。

pthread_cond_wait 为什么需要传递 mutex 参数？#

本质上这个问题想问这个锁是用来保护什么的？其实这个互斥锁不是用来保护条件变量的内部状态的，而是用来保护外部条件的，就是那个while()循环中的判断。

游双书里面说”pthread_cond_wait函数用于等待目标条件变量，mutex是保护条件变量的互斥锁，以确保pthread_cond_wait的原子性。“在看完这个回答你就该知道，pthread_cond_wait的原子性指的是while条件判断成立和这个线程调用wait函数进入唤醒队列的原子性。

• 错误写法

  1
  //threadA
  2
  pthread_mutex_lock(&mutex);
  3
  while (false == ready) {
  4
     pthread_cond_wait(&cond, &mutex);
  5
  }
  6
  pthread_mutex_unlock(&mutex);
  7
  
  8
  //threadB
  9
  ready = true;
  10
  pthread_cond_signal(&cond);

  这个写法为什么有错误？如图：

  

  ThreadA进入while循环后，准备进入唤醒队列，此时ThreadB进来横插一脚，把ready改成true然后提前唤醒，这个时候线程A还没有进入唤醒队列，因此A会丢失唤醒条件进而永久wait

• 正确写法

  1
  //Thread A
  2
  pthread_mutex_lock(&mutex);
  3
  while (false == ready) {
  4
      pthread_cond_wait(&cond, &mutex);
  5
  }
  6
  pthread_mutex_unlock(&mutex);
  7
  
  8
  //Thread B
  9
  pthread_mutex_lock(&mutex);
  10
  ready = true;
  11
  pthread_mutex_unlock(&mutex);
  12
  pthread_cond_signal(&cond);

参考链接

什么是虚假唤醒？#

一般来说我们要在等待wait的时候用while循环。因为会产生虚假唤醒。

pthread 的条件变量等待 pthread_cond_wait 是使用阻塞的系统调用实现的（比如 Linux 上的 futex），这些阻塞的系统调用在进程被信号中断后，通常会中止阻塞、直接返回 EINTR 错误。同样是阻塞系统调用，你从 read 拿到 EINTR 错误后可以直接决定重试，因为这通常不影响它本身的语义。而条件变量等待则不能，因为本线程拿到 EINTR 错误和重新调用 futex 等待之间，可能别的线程已经通过 pthread_cond_signal 或者 pthread_cond_broadcast发过通知了。所以，虚假唤醒的一个可能性是条件变量的等待被信号中断。

在多核处理器下，pthread_cond_signal可能会激活多于一个线程（阻塞在条件变量上的线程）。结果是，当一个线程调用pthread_cond_signal()后，因为多个线程都被唤醒了，很可能其中一个唤醒的线程，先一步改变的condition. 此时另一个线程的condition已经不满足，因此需要加Where再次判断。这种效应成为”虚假唤醒”(spurious wakeup)。所以我们把判断条件从if改成while，pthread_cond_wait中的while()不仅仅在等待条件变量前检查条件变量，实际上在等待条件变量后也检查条件变量。

套接字文件描述符和端口号的关系#

个socket句柄代表两个地址对 “本地ip”—“远程ip”

在windows下叫句柄，在linux下叫文件描述符

socket为内核对象，由操作系统内核来维护其缓冲区，引用计数，并且可以在多个进程中使用。

进程线程协程#

参考链接

linux栈大小#

用命令ulimit -s查看

8M左右

服务器集群#

Linux进程、进程组、会话、僵尸#

研究 Linux 之前，首先要对进程、进程组、会话，线程有个整体的了解：一个会话包含多个进程组，一个进程组包含多个进程，一个进程包含多个线程。

进程：

进程是 Linux 操作系统环境的基础，它控制着系统上几乎所有的活动。每个进程都有自己唯一的标识：进程 ID，也有自己的生命周期。进程都有父进程，父进程也有父进程，从而形成了一个以 init 进程 （PID = 1）为根的家族树。除此以外，进程还有其他层次关系：进程组和会话。

有几种比较特殊的进程：

1. 孤儿进程：一个父进程退出，而它的一个或多个子进程还在运行，那么那些子进程将成为孤儿进程。孤儿进程将被 init 进程(进程号为1)所收养，并由 init 进程对它们完成状态收集工作。
2. 僵尸进程：一个进程使用 fork 创建子进程，如果子进程先退出，而父进程并没有调用 wait 或 waitpid 获取子进程的状态信息，那么子进程的进程描述符仍然保存在系统中。这种进程称之为僵死进程。
3. 守护进程：（英语：daemon）是一种在后台执行的程序。此类程序会被以进程的形式初始化。守护进程程序的名称通常以字母“d”结尾：例如，syslogd 就是指管理系统日志的守护进程。

进程ID：

Linux每个进程都会有一个非负整数表示的唯一进程 ID，简称 pid。Linux 提供了getpid 函数来获取进程的 pid，同时还提供了 getppid 函数来获取父进程的 pid。

进程组：

进程组的概念并不难理解，可以将人与人之间的关系做类比。一起工作的同事，自然比毫不相干的路人更加亲近。shell 中协同工作的进程属于同一个进程组，就如同协同工作的人属于同一个部门一样。引入了进程组的概念，可以更方便地管理这一组进程了。比如这项工作放弃了，不必向每个进程一一发送信号，可以直接将信号发送给进程组，进程组内的所有进程都会收到该信号。

会话(session)：

一般是指 shell session。Shell session 是终端中当前的状态，在终端中只能有一个 session。当我们打开一个新的终端时，总会创建一个新的 shell session。

就进程间的关系来说，session 由一个或多个进程组组成。我们可以通过下图来理解进程、进程组和 session 之间的关系：

守护进程#

概念：

守护进程（Daemon）是运行在后台的一种特殊进程。它独立于控制终端并且周期性地执行某种任务或等待处理某些发生的事件。守护进程是一种很有用的进程。 Linux的大多数服务器就是用守护进程实现的。比如，Internet服务器inetd，Web服务器httpd等。同时，守护进程完成许多系统任务。 比如，作业规划进程crond，打印进程lpd等。守护进程的编程本身并不复杂，复杂的是各种版本的Unix的实现机制不尽相同，造成不同 Unix环境下守护进程的编程规则并不一致。

当我们在命令行提示符后输入类似./helloworld程序时，在程序运行时终端被占用，此时无法执行其它操作。即使使用./helloworld &方式后台运行，当连接终端的网络出现问题，那么也会导致运行程序中断。这些因素对于长期运行的服务来说很不友好，而「守护进程」可以很好的解决这个问题。

特性：

守护进程最重要的特性是后台运行。其次，守护进程必须与其运行前的环境隔离开来。这些环境包括未关闭的文件描述符，控制终端，会话和进程组，工作目录以及文件创建掩模等。这些环境通常是守护进程从执行它的父进程（特别是shell）中继承下来的。最后，守护进程的启动方式有其特殊之处。它可以在Linux系统启动时从启动脚本/etc/rc.d中启动，可以由作业规划进程crond启动，还可以由用户终端（通常是 shell）执行。总之，除开这些特殊性以外，守护进程与普通进程基本上没有什么区别。因此，编写守护进程实际上是把一个普通进程按照上述的守护进程的特性改造成为守护进程。如果对进程有比较深入的认识就更容易理解和编程了。

编程：

setsid()函数主要是重新创建一个session,子进程从父进程继承了SessionID、进程组ID和打开的终端,子进程如果要脱离父进程，不受父进程控制，我们可以用这个setsid命令。想脱离父进程，自己自由自在的活着，就要用这个命令执行后面的操作，简单粗暴。

编写守护进程过程如下：

1. 创建子进程，父进程退出

   进程 fork 后，父进程退出。这么做的原因有 2 点：

   • 如果守护进程是通过 Shell 启动，父进程退出，Shell 就会认为任务执行完毕，这时子进程由 init 收养
   • 子进程继承父进程的进程组 ID，保证了子进程不是进程组组长，因为后边调用setsid()要求必须不是进程组长

2. 子进程创建新会话

​ 调用setsid()创建一个新的会话，并成为新会话组长。这个步骤主要是要与继承父进程的会话、进程组、终端脱离关系。fork()的目的是想成功调用setsid()来建 立新会话，子进程有单独的sid，并且成为新进程组的组长，不关联任何终端。

3. 禁止子进程重新打开终端

   此刻子进程是会话组长，为了防止子进程重新打开终端，再次 fork 后退出父进程，也就是此子进程。这时子进程 2 不再是会话组长，无法再打开终端。其实这一步骤不是必须的，不过加上这一步骤会显得更加严谨。

4. 设置当前目录为根目录

   如果守护进程的当前工作目录是/usr/home目录，那么管理员在卸载/usr分区时会报错的。为了避免这个问题，可以调用chdir()函数将工作目录设置为根目录/。

5. 设置文件权限掩码

   文件权限掩码是指屏蔽掉文件权限中的对应位。由于使用 fork()函数新建的子进程继承了父进程的文件权限掩码，这就给该子进程使用文件带来了诸多的麻烦。因此，把文件权限掩码设置为 0，可以大大增强该守护进程的灵活性。通常使用方法是umask(0)。

6. 关闭文件描述符

   子进程会继承已经打开的文件，它们占用系统资源，且可能导致所在文件系统无法卸载。此时守护进程与终端脱离，常说的输入、输出、错误描述符也应该关闭。

1
pid_t pid, sid;
2
int i;
3
pid = fork(); // 第1步
4
if (pid < 0)
5
    exit(-1);
6
else if (pid > 0)
7
    exit(0);  // 父进程第一次退出
8

9
if ((sid = setsid()) < 0)  // 第2步
10
{
11
    syslog(LOG_ERR, "%s\n", "setsid");
12
    exit(-1);
13
}
14

15
// 第3步 第二次父进程退出
16
if ((pid = fork()) > 0)
17
    exit(0);
18
if ((sid = chdir("/")) < 0) // 第4步
19
{
20
    syslog(LOG_ERR, "%s\n", "chdir");
21
    exit(-1);
22
}
23

24
umask(0); // 第5步
25

26
// 第6步：关闭继承的文件描述符
27
for(i = 0; i < getdtablesize(); i++)
28
{
29
    close(i);
30
}
31
while(1)
32
{
33
    do_something();
34
}
35
closelog();
36
exit(0);

系统调用的详细过程#

**系统调用：**系统调用是操作系统为用户提供的一系列API；系统调用将用户的请求发给内核，内核执行完以后，将结果返回给用户；

参考