标签：文件 就绪 epoll 描述符 fd poll select

1. 文件描述符 fd 与 socket

1.1 什么是文件描述符

文件描述符（file descriptor）是一个非负整数，从 0 开始。进程使用文件描述符来标识一个打开的文件。

系统为每一个进程维护了一个文件描述符表，表示该进程打开文件的记录表，而文件描述符实际上就是这张表的索引。当进程打开（open）或者新建（create）文件时，内核会在该进程的文件列表中新增一个表项，同时返回一个文件描述符 —— 也就是新增表项的下标。

一般来说，每个进程最多可以打开 64 个文件，fd ∈ 0~63。在不同系统上，最多允许打开的文件个数不同，Linux 2.4.22 强制规定最多不能超过 1,048,576。

每个进程默认都有 3 个文件描述符：0 (stdin)、1 (stdout)、2 (stderr)。

这篇文章Linux的进程、线程、文件描述符是什么对文件描述符作了深入地讲解，可以进一步阅读。

1.2 fd 与 socket 关系

socket 是 Unix 中的术语。socket 可以用于同一台主机的不同进程间的通信，也可以用于不同主机间的通信。一个 socket 包含地址、类型和通信协议等信息，通过 socket() 函数创建：

int socket(int domain, int type, int protocol)

返回的就是这个 socket 对应的文件描述符 fd。操作系统将 socket 映射到进程的一个文件描述符上，进程就可以通过读写这个文件描述符来和远程主机通信。

可以这样理解：socket 是进程间通信规则的高层抽象，而 fd 提供的是底层的具体实现。socket 与 fd 是一一对应的。通过 socket 通信，实际上就是通过文件描述符 fd 读写文件。这也符合 Unix“一切皆文件”的哲学。

本文可以将 socket 和 fd 视为同义词。

2. 内核接收网络数据全过程

如下图所示，进程在recv阻塞期间，计算机收到了对端传送的数据（步骤①）。数据经由网卡传送到内存（步骤②），然后网卡通过中断信号通知cpu有数据到达，cpu执行中断程序（步骤③）。此处的中断程序主要有两项功能，先将网络数据写入到对应socket的接收缓冲区里面（步骤④），再唤醒进程A（步骤⑤），重新将进程A放入工作队列中。

唤醒进程的过程如下图所示。

以上是内核接收数据全过程
这里有两个问题:
其一，操作系统如何知道网络数据对应于哪个socket？
其二，如何同时监视多个socket的数据？
第一个问题：因为一个socket对应着一个端口号，而网络数据包中包含了ip和端口的信息，内核可以通过端口号找到对应的socket。当然，为了提高处理速度，操作系统会维护端口号到socket的索引结构，以快速读取。
第二个问题是多路复用的重中之重

3. 从阻塞 I/O 到 I/O 多路复用

阻塞 I/O，是指进程发起调用后，会被挂起（阻塞），直到收到数据再返回。如果调用一直不返回，进程就会一直被挂起。因此，当使用阻塞 I/O 时，需要使用多线程来处理多个文件描述符。

多线程切换有一定的开销，因此引入非阻塞 I/O。非阻塞 I/O 不会将进程挂起，调用时会立即返回成功或错误，因此可以在一个线程里轮询多个文件描述符是否就绪。

但是非阻塞 I/O 的缺点是：每次发起系统调用，只能检查一个文件描述符是否就绪。当文件描述符很多时，系统调用的成本很高。

因此引入了 I/O 多路复用，可以通过一次系统调用，检查多个文件描述符的状态。这是 I/O 多路复用的主要优点，相比于非阻塞 I/O，在文件描述符较多的场景下，避免了频繁的用户态和内核态的切换，减少了系统调用的开销。

I/O 多路复用相当于将「遍历所有文件描述符、通过非阻塞 I/O 查看其是否就绪」的过程从用户线程移到了内核中，由内核来负责轮询。

进程可以通过 select、poll、epoll 发起 I/O 多路复用的系统调用，这些系统调用都是同步阻塞的：如果传入的多个文件描述符中，有描述符就绪，则返回就绪的描述符；否则如果所有文件描述符都未就绪，就阻塞调用进程，直到某个描述符就绪，或者阻塞时长超过设置的 timeout 后，再返回。I/O 多路复用内部使用非阻塞 I/O 检查每个描述符的就绪状态。

如果 timeout 参数设为 NULL，会无限阻塞直到某个描述符就绪；如果 timeout 参数设为 0，会立即返回，不阻塞。

I/O 多路复用引入了一些额外的操作和开销，性能更差。但是好处是用户可以在一个线程内同时处理多个 I/O 请求。如果不采用 I/O 多路复用，则必须通过多线程的方式，每个线程处理一个 I/O 请求。后者线程切换也是有一定的开销的。

为什么 I/O 多路复用内部需要使用非阻塞 I/O

I/O 多路复用内部会遍历集合中的每个文件描述符，判断其是否就绪：

for fd in read_set
    if（ readable(fd) ) // 判断 fd 是否就绪
        count++
        FDSET(fd, &res_rset) // 将 fd 添加到就绪集合中
        break
...
return count

这里的 readable(fd) 就是一个非阻塞 I/O 调用。试想，如果这里使用阻塞 I/O，那么 fd 未就绪时，select 会阻塞在这个文件描述符上，无法检查下个文件描述符。

注意：这里说的是 I/O 多路复用的内部实现，而不是说，使用 I/O 多路复用就必须使用非阻塞 I/O，见文章这部分为什么边缘触发必须使用非阻塞 I/O。

4. select

函数签名与参数

int select(int nfds,
            fd_set *restrict readfds,
            fd_set *restrict writefds,
            fd_set *restrict errorfds,
            struct timeval *restrict timeout);

readfds、writefds、errorfds 是三个文件描述符集合。select 会遍历每个集合的前 nfds 个描述符，分别找到可以读取、可以写入、发生错误的描述符，统称为“就绪”的描述符。然后用找到的子集替换参数中的对应集合，返回所有就绪描述符的总数。

timeout 参数表示调用 select 时的阻塞时长。如果所有文件描述符都未就绪，就阻塞调用进程，直到某个描述符就绪，或者阻塞超过设置的 timeout 后，返回。如果 timeout 参数设为 NULL，会无限阻塞直到某个描述符就绪；如果 timeout 参数设为 0，会立即返回，不阻塞。

4.1 fd_set 文件描述符集合

fd_set 结构体：

typedef long int __fd_mask;

/* fd_set for select and pselect.  */
typedef struct {
    #ifdef __USE_XOPEN
        __fd_mask fds_bits[__FD_SETSIZE / __NFDBITS];
    # define __FDS_BITS(set) ((set)->fds_bits)
    #else
        __fd_mask __fds_bits[__FD_SETSIZE / __NFDBITS];
    # define __FDS_BITS(set) ((set)->__fds_bits)
    #endif
} fd_set;

参数中的 fd_set 类型表示文件描述符的集合。

由于文件描述符 fd 是一个从 0 开始的无符号整数，所以可以使用 fd_set 的二进制每一位来表示一个文件描述符。某一位为 1，表示对应的文件描述符已就绪。比如比如设 fd_set 长度为 1 字节，则一个 fd_set 变量最大可以表示 8 个文件描述符。当 select 返回 fd_set = 00010011 时，表示文件描述符 1、2、5 已经就绪。

fd_set 的使用涉及以下几个 API：
```c
#include <sys/select.h>   
int FD_ZERO(int fd, fd_set *fdset);  // 将 fd_set 所有位置 0
int FD_CLR(int fd, fd_set *fdset);   // 将 fd_set 某一位置 0
int FD_SET(int fd, fd_set *fd_set);  // 将 fd_set 某一位置 1
int FD_ISSET(int fd, fd_set *fdset); // 检测 fd_set 某一位是否为 1

4.2 执行流程

1. 用户线程调用select，将fd_set从用户空间拷贝到内核空间
2. 内核在内核空间对fd_set遍历一遍，检查是否有就绪的socket描述符，如果没有的话，就会进入休眠，直到有就绪的socket描述符
3. 内核返回select的结果给用户线程，即就绪的文件描述符数量
4. 用户拿到就绪文件描述符数量后，再次对fd_set进行遍历，找出就绪的文件描述符
5. 用户线程对就绪的文件描述符进行读写操作

select 需要将所有文件描述符传到内核空间里面主要是出于安全考虑:

1. 用户空间的指针所指向的虚拟地址，在内核态访问的时候，不能保证还存在在物理页面上
2. 如果在内核态直接访问用户空间的地址，当发生“Page Fault“缺页错误时，内核会死机。而将数据从用户空间拷贝到内核空间的函数 copy_from_user，在发生缺页错误时会优雅地返回一个错误码，保证程序不崩掉。
3. 为了安全，在读取/写入用户空间的指针之前，必须先验证这个指针是否确实是用户空间的、是否有相应的权限。这是为了防止用户空间访问内核空间。copy_from_user 的入口封装了这个逻辑。

4. 执行系统调用的线程有可能在验证用户内存之后、但在实际完成系统调用之前被调度出来，这可能导致用户空间的指针，指向了一段包含恶意程序的代码。所以从安全性和（最终）性能等方面来说，先制作一份拷贝会更好。

4.3 select 使用示例

下图的代码说明：

• 先声明一个 fd_set 类型的变量 readFDs
• 调用 FD_ZERO，将 readFDs 所有位置 0
• 调用 FD_SET，将 readFDs 感兴趣的位置 1，表示要监听这几个文件描述符
• 将 readFDs 传给 select，调用 select
• select 会将 readFDs 中就绪的位置 1，未就绪的位置 0，返回就绪的文件描述符的数量
• 当 select 返回后，调用 FD_ISSET 检测给定位是否为 1，表示对应文件描述符是否就绪

比如进程想监听 1、2、5 这三个文件描述符，就将 readFDs 设置为 00010011，然后调用 select。

如果 fd=1、fd=2 就绪，而 fd=5 未就绪，select 会将 readFDs 设置为 00000011 并返回 2。

如果每个文件描述符都未就绪，select 会阻塞 timeout 时长，再返回。这期间，如果 readFDs 监听的某个文件描述符上发生可读事件，则 select 会将对应位置 1，并立即返回。

4.4 select 优点

1. 跨平台，几乎所有平台都支持；
2. 时间精度高，ns 级别。

4.5 select 缺点

1. 最大限制：单个进程能够监视的文件描述符的数量存在最大限制。(基于数组存储的赶脚)一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。它由FD_SETSIZE设置，32位机默认是1024个。64位机默认是2048.
   时间复杂度： 对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低，时间复杂度O(n)。
2. 当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历一遍。这会浪费很多CPU时间。它仅仅知道有I/O事件发生了，却并不知道是哪那几个流（可能有一个，多个，甚至全部），我们只能无差别轮询所有流，找出能读出数据，或者写入数据的流，对他们进行操作。所以select具有O(n)的无差别轮询复杂度，同时处理的流越多，无差别轮询时间就越长。
3. 内存拷贝：需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大。

5. poll

poll 和 select 几乎没有区别。poll 在用户态通过数组方式传递文件描述符，在内核会转为链表方式存储，没有最大数量的限制。
poll 的函数签名

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

pollfd 的结构体

struct pollfd {
    int   fd;         /* file descriptor */
    short events;     /* requested events */
    short revents;    /* returned events */
};

5.1 与select的异同点

相同点：

• 内核线程都需要遍历文件描述符，并且当内核返回就绪的文件描述符数量后，还需要遍历一次找出就绪的文件描述符
• 需要将文件描述符数组或链表从用户空间拷贝到内核空间
• 性能开销会随文件描述符的数量而线性增大

不同点：

• select存储的数据结构是文件描述符数组，poll采用链表
• select有最大连接数限制，poll没有最大限制，因为poll采用链表存储

5.2 执行过程（基本与 select 类型）

1. 用户线程调用 poll 系统调用，并将文件描述符链表拷贝到内核空间
2. 内核对文件描述符遍历一遍，如果没有就绪的描述符，则内核开始休眠，直到有就绪的文件描述符
3. 返回给用户线程就绪的文件描述符数量
4. 用户线程再遍历一次文件描述符链表，找出就绪的文件描述符
5. 用户线程对就绪的文件描述符进行读写操作

5.3 poll 优点

没有最大连接数的限制。（基于链表来存储的）

5.4 poll 缺点

1. 时间复杂度： 对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低，时间复杂度O(n)。它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。
2. 内存拷贝：大量的fd数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。大量的fd数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。
3. 水平触发：如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

注意：select和poll都需要在返回后，通过遍历文件描述符来获取已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。

6. epoll

epoll 是对 select 和 poll 的改进，避免了“性能开销大”和“文件描述符数量少”两个缺点。

核心代码：

#include <sys/epoll.h>

// 数据结构
// 每一个epoll对象都有一个独立的eventpoll结构体
// 红黑树用于存放通过epoll_ctl方法向epoll对象中添加进来的事件
// epoll_wait检查是否有事件发生时，只需要检查eventpoll对象中的rdlist双链表中是否有epitem元素即可
struct eventpoll {
    ...
    /*红黑树的根节点，这颗树存储着所有添加到epoll中的需要监控的事件*/
    struct rb_root  rbr;
    /*双链表存储所有就绪的文件描述符*/
    struct list_head rdlist;
    ...
};

// API
int epoll_create(int size); // 内核中间加一个 eventpoll 对象，把所有需要监听的 socket 都放到 eventpoll 对象中
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); // epoll_ctl 负责把 socket 增加、删除到内核红黑树
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);// epoll_wait 检测双链表中是否有就绪的文件描述符，如果有，则返回

简而言之，epoll 有以下几个特点：

• 使用红黑树存储文件描述符集合
• 使用双链表存储就绪的文件描述符
• 每个文件描述符只需在添加时传入一次，通过事件 callback 更改文件描述符状态。

select、poll 模型都只使用一个函数，而 epoll 模型使用三个函数：epoll_create、epoll_ctl 和 epoll_wait。

• epoll_create 创建 eventpoll对象（红黑树，双链表）
• 一棵红黑树，存储监听的所有文件描述符，并且通过 epoll_ctl 将文件描述符添加、删除到红黑树
• 一个双链表，存储就绪的文件描述符列表，epoll_wait调用时，检测此链表中是否有数据，有的话直接返回
• 所有添加到 eventpoll 中的事件都与设备驱动程序建立回调关系

6.1 epoll_create

int epoll_create(int size);

内核在 epoll 文件系统中建了个file结点

• epoll_create 会创建一个 epoll 实例，同时返回一个引用该实例的文件描述符
• 返回的文件描述符仅仅指向对应的 epoll 实例，并不表示真实的磁盘文件节点。其他 API 如 epoll_ctl、epoll_wait 会使用这个文件描述符来操作相应的 epoll 实例
• 使用完，必须调用close()关闭，否则导致fd被耗尽

epoll 实例内部存储：

• 监听列表：所有要监听的文件描述符，使用红黑树，由 epoll_ctl 传来
• 就绪列表：所有就绪的文件描述符，使用双向链表

6.2 epoll_ctl

epoll_ctl 会监听文件描述符 fd 上发生的 event 事件

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

参数说明

• epfd 即 epoll_create 返回的文件描述符，指向一个 epoll 实例
• fd 表示要监听的目标文件描述符
• event 表示要监听的事件（可读、可写、发送错误…）
• op 表示要对 fd 执行的操作，有以下几种：
  • EPOLL_CTL_ADD：为 fd 添加一个监听事件 event
  • EPOLL_CTL_MOD：Change the event event associated with the target file descriptor fd（event 是一个结构体变量，这相当于变量 event 本身没变，但是更改了其内部字段的值）
  • EPOLL_CTL_DEL：删除 fd 的所有监听事件，这种情况下 event 参数没用
• 返回值 0 或 -1，表示上述操作成功与否。

epoll_ctl 会将文件描述符 fd 添加到 epoll 实例的监听列表里，同时为 fd 设置一个回调函数，并监听事件 event，如果红黑树中已经存在立刻返回。当 fd 上发生相应事件时，会调用回调函数，将 fd 添加到 epoll 实例的就绪队列上。

6.3 epoll_wait

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

epoll 模型的主要函数，功能相当于 select

参数说明：

• epfd 即 epoll_create 返回的文件描述符，指向一个 epoll 实例
• events 是一个数组，保存就绪状态的文件描述符，其空间由调用者负责申请
• maxevents 指定 events 的大小
• timeout 类似于 select 中的 timeout。如果没有文件描述符就绪，即就绪队列为空，则 epoll_wait 会阻塞 timeout 毫秒。如果 timeout 设为 -1，则 epoll_wait 会一直阻塞，直到有文件描述符就绪；如果 timeout 设为 0，则 epoll_wait 会立即返回
• 返回值表示 events 中存储的就绪描述符个数，最大不超过 maxevents。

6.4 mmap 内存映射

6.5 epoll 优点

epoll 是对 select 和 poll 的改进，避免了“性能开销大”和“文件描述符数量少”两个缺点。对于“文件描述符数量少”，select 使用整型数组存储文件描述符集合，而 epoll 使用红黑树存储，数量较大。对于“性能开销大”，epoll_ctl 中为每个文件描述符指定了回调函数，并在就绪时将其加入到就绪列表，因此 epoll 不需要像 select 那样遍历检测每个文件描述符，只需要判断就绪列表是否为空即可。这样，在没有描述符就绪时，epoll 能更早地让出系统资源。相当于时间复杂度从 O(n) 降为 O(1)。此外，每次调用 select 时都需要向内核拷贝所有要监听的描述符集合，而 epoll 对于每个描述符，只需要在 epoll_ctl 传递一次，之后 epoll_wait 不需要再次传递。这也大大提高了效率。

1. 没有最大连接数的限制。（基于 红黑树+双链表 来存储的:1G的内存上能监听约10万个端口）
2. 时间复杂度低： 边缘触发和事件驱动，监听回调，时间复杂度O(1)。只有活跃可用的fd才会调用callback函数；即epoll最大的优点就在于它只管“活跃”的连接，而跟连接总数无关，因此实际网络环境中，Epoll的效率就会远远高于select和poll。
   3.内存拷贝：利用mmap()文件映射内存加速与内核空间的消息传递，减少拷贝开销。

6.6 epoll 缺点

依赖于操作系统：Linux

6.7 应用场景

适合用epoll的应用场景：

• 对于连接特别多，活跃的连接特别少
• 典型的应用场景为一个需要处理上万的连接服务器，例如各种app的入口服务器，例如qq

不适合epoll的场景：

• 连接比较少，数据量比较大，例如ssh
• epoll 的惊群问题：因为epoll 多用于多个连接，只有少数活跃的场景，但是万一某一时刻，epoll 等的上千个文件描述符都就绪了，这时候epoll 要进行大量的I/O，此时压力太大。

6.8 epoll 两种模式

epoll对文件描述符的操作有两种模式：LT(level trigger) 和 ET(edge trigger)。LT是默认的模式，ET是“高速”模式。

• LT（水平触发）模式下，只要有数据就触发，缓冲区剩余未读尽的数据会导致 epoll_wait都会返回它的事件；
• ET（边缘触发）模式下，只有新数据到来才触发，不管缓存区中是否还有数据，缓冲区剩余未读尽的数据不会导致epoll_wait返回。

水平触发、边缘触发的名称来源：数字电路当中的电位水平，高低电平切换瞬间的触发动作叫边缘触发，而处于高电平的触发动作叫做水平触发。

LT 模式

LT(level triggered)是缺省的工作方式，并且同时支持 block 和no-block socket。在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的 fd 进行 IO 操作。如果你不作任何操作，内核还是会继续通知你的,只要这个文件描述符还有数据可读，每次 epoll_wait都会返回它的事件，提醒用户程序去操作。

ET 模式

ET(edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)。
在它检测到有 I/O 事件时，通过 epoll_wait 调用会得到有事件通知的文件描述符，对于每一个被通知的文件描述符，如可读，则必须将该文件描述符一直读到空，让 errno 返回 EAGAIN （提示你的应用程序现在没有数据可读请稍后再试）为止，否则下次的 epoll_wait 不会返回余下的数据，会丢掉事件。

ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

7. select、poll、epoll的区别

	select	poll	epoll
底层数据结构	数组存储文件描述符	链表存储文件描述符	红黑树存储监控的文件描述符，双链表存储就绪的文件描述符
如何从fd数据中获取就绪的fd	遍历fd_set	遍历链表	回调
时间复杂度	获得就绪的文件描述符需要遍历fd数组，O(n)	获得就绪的文件描述符需要遍历fd链表，O(n)	当有就绪事件时，系统注册的回调函数就会被调用，将就绪的fd放入到就绪链表中。O(1)
FD数据拷贝	每次调用select，需要将fd数据从用户空间拷贝到内核空间	每次调用poll，需要将fd数据从用户空间拷贝到内核空间	使用内存映射(mmap)，不需要从用户空间频繁拷贝fd数据到内核空间
最大连接数	有限制，一般为1024	无限制	无限制

注意

1. 在select/poll中，进程只有在调用一定的方法后，内核才对所有监视的文件描述符进行扫描，而epoll事先通过epoll_ctl()来注册一个文件描述符，一旦基于某个文件描述符就绪时，内核会采用类似callback的回调机制，迅速激活这个文件描述符，当进程调用epoll_wait()时便得到通知。此处去掉了遍历文件描述符，而是通过监听回调的的机制。这正是epoll的魅力所在。
2. 如果没有大量的idle-connection或者dead-connection，epoll的效率并不会比select/poll高很多，但是当遇到大量的idle-connection，就会发现epoll的效率大大高于select/poll。

8. 参考文献

• Zuckerbery EPOLL原理详解（图文并茂）
• 老宋有个好主意 IO多路复用之select、poll、epoll
• 【操作系统】I/O 多路复用，select / poll / epoll 详解
• IO多路复用，select、poll、epoll区别

标签：文件,就绪,epoll,描述符,fd,poll,select
来源： https://www.cnblogs.com/cscshi/p/16525332.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。