1.select?内核ں?Դ??
2.Linux内核poll/select机制简析
3.搞懂epoll和select和poll的区别|Linux高并发网络编程
4.深入select多路复用内核源码加驱动实现
5.Linux内核阻塞IO(wait_queue)和非阻塞IO(轮询poll)
6.深入理解Linux的epoll机制

select?ں?Դ??

       epoll是什么手表？

       不是手表，epoll是源码源码Linux内核为处理大批量文件描述符而作了改进的poll，是内核Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的源码源码情况下的系统CPU利用率。

       epoll和select区别总结？

       epoll是内核Linux内核为处理大批量文件描述符而作了改进的poll，是源码源码matlab教程源码Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的内核情况下的系统CPU利用率。

       elect是源码源码一个计算机函数，位于头文件#include。内核该函数用于监视文件描述符的源码源码变化情况——读写或是异常。

       fd文件夹是内核什么意思？

       fd，即filedescriptor，源码源码文件描述符。内核linux下，源码源码所有的内核操作都是对文件进行操作，而对文件的操作是利用文件描述符(filedescriptor)来实现的。

       每个文件进程控制块中都有一份文件描述符表（可以把它看成是一个数组，里面的元素是指向file结构体指针类型），这个数组的下标就是文件描述符。在源代码中，一般用fd作为文件描述符的标识。

       linux什么数据结构存放进程打开的文件信息？

       linux系统下查看进程打开文件在/proc下，对应每个进程有一个以进程号命名的目录，该目录下有一个fd目录，该目录下面的每个文件是一个符号连接，其文件名对应该进程占用的一个文件描述符，而连接指向的内容表示文件描述符对应的实际文件，有多少个文件描述符表示该进程打开了多少文件。

       另外Linux默认的进程打开文件上限是个，可以通过ulimit-n查看。很多系统上限可以通过修改/etc/security/limits.conf文件改变，这个文件有详细的注释，对如何修改做了说明。

       如果希望把所有用户的进程打开文件上限改为，可以加入下面两行*softnofile*hardnofile还可以只真对某个用户或某个组做修改，具体方法参见文件注释。修改后需要重新启动系统才能生效。

       linux如何设置进程所能打开的最大文件描述符个数？

       每个进程的文件描述符都是唯一的;文件描述符是file_struct结构中的file(打开文件创建的对象)指针数组的索引,file对象只有打开文件时才会创建并与文件描述符相关联fd_install(fd,f)

       ;进程间传递文件描述符除了父子进程外,没啥意义.父子进程之间会将file_struct的file指针数组全部拷贝,所以子进程才可以用父进程fd.

Linux内核poll/select机制简析

       I/O多路复用机制提供了同时监测多个文件描述符的能力，以判断是否可以执行IO操作。本文将详细解析Linux内核中的poll和select机制实现原理。首先，我们简要介绍这两个函数的调用方式。

       select函数将监听的文件描述符分为三组，分别为可读、可写和异常事件的集合。通过调用此函数，可以监控多个描述符，并在某个描述符就绪时立即通知相应程序进行读或写操作。timeout参数允许指定超时时间，函数会阻塞到有文件描述符可以进行操作或被信号打断，或在指定时间内无事件发生。

       poll函数则不需要分别设置可读、可写和异常事件的文件描述符集，而是通过构造pollfd结构的数组来指定描述符和感兴趣的事件。当poll调用返回时，每个描述符上产生的事件都会被保存在revents成员内。同样有timeout参数用于指定超时时间。

       在Linux内核源码中，poll和select函数的实现机制主要涉及系统调用和内核空间与用户空间的交互。poll函数在fs/select.c文件中定义，首先会将pollfd结构体数组从用户空间拷贝到内核空间，并在内存中组织一个链表存储这些描述符。随后调用do_poll函数执行实际的poll操作，最后将每个描述符产生的事件返回给用户空间。

       do_poll函数遍历链表，对每一个描述符调用do_pollfd函数，将当前进程加入到描述符关联的底层驱动等待队列中。如果描述符已产生事件，后续遍历过程中无需再次将进程加入队列。经过遍历并检查等待条件后，将最终产生的事件返回给用户空间。

       总结而言，poll和select函数提供了高效的1000001的源码I/O多路复用机制，允许同时监控多个文件描述符，并在某个描述符就绪时立即通知程序进行操作。通过分析内核源码，我们可以深入了解这两个函数在Linux系统中的实现细节，从而更好地理解和使用这些重要的I/O管理工具。

搞懂epoll和select和poll的区别|Linux高并发网络编程

       在深入理解Linux高并发网络编程中，理解epoll、select和poll的原理至关重要。它们都是多路复用机制，让单个线程能同时处理多个socket的I/O事件，但实现方式有所不同。

       首先，select和poll的共同点是，用户进程将待监控的socket的描述符（fd）传递给内核，内核会检查这些socket是否有活动。如果没有活动，线程会阻塞，等待socket被唤醒。它们的局限性在于，select的fd集合大小有的限制，而poll虽然改善了fd结构，但实际使用中已不太常见。

       epoll则是在优化上做了重大改进。它在内核中维护一个socket集合，通过epoll_ctl动态添加或删除socket，避免了每次调用都拷贝描述符。epoll使用红黑树存储socket，当socket有数据时，回调仅在ready_list中唤醒，减少了无用遍历。此外，epoll还利用内存映射技术，避免了拷贝，提高了效率。

       ET和LT模式是epoll的不同实现。ET是边沿触发，socket被读取事件后不再加入ready_list，若后续出现数据包，需要新事件触发。而LT是水平触发，每次读取后socket会再次加入ready_list，确保不会错过后续数据包。

       理解这些原理后，尽管源码阅读和深入探究是提升理解的途径，但到这个程度，基本能应对大部分场景。对于更深入的学习，视频课程是个不错的选择。

深入select多路复用内核源码加驱动实现

       本文主要探讨了select多路复用内核源码的驱动实现过程。用户空间调用select库后，系统调用sys_select引导到内核处理。核心内容涉及四个关键结构体：poll_wqueues、poll_table_page、poll_table_entry和poll_table_struct。每个进程在select调用时，都会对应一个poll_wqueues结构体，用于统一管理所有fd的轮询操作，这是整个流程的基础。

       poll_wqueues的inline_entries数组有限，当空间不足时，会动态扩展为物理内存页。当fd调用poll函数时，会分配poll_table_entry，首先从inline_entries开始，直到用完才分配新的物理页。poll_table_entry在__pollwait函数中起到关键作用，它存储了特定fd的file指针、硬件驱动的等待队列头和进程的poll_wqueues结构体。

       总结来说，硬件驱动的事件等待队列头数量有限，每个进程仅有一个poll_wqueues结构体，但fd的股城源码数量取决于驱动程序的事件队列头数量。每个fd可能对应多个poll_table_entry，这些结构体在驱动程序中用于记录等待事件。当多个进程同时使用select监控同一设备，每个进程的poll_table_entry数量将保持一致。

       do_select函数通过遍历n个fd，调用它们的poll函数，驱动程序如字符设备evdev中的poll函数会与poll_wqueues.poll_table关联。poll_table结构简单，包含函数指针和key值，key值会根据fd的监测需求变化。当设备有IO事件时，驱动程序会调用相关函数，唤醒select进程，最后select函数检查并返回用户空间。

       本文还通过实例，如字符设备驱动和内存字符设备驱动模拟，展示了select在内核中实际操作的过程。通过驱动程序实现poll接口，使得设备支持select机制，用户空间的应用程序可以灵活监控多个fd的事件。

Linux内核阻塞IO(wait_queue)和非阻塞IO(轮询poll)

       Linux内核提供了两种IO访问模式：阻塞和非阻塞。阻塞IO在设备不可用时会使进程挂起，而非阻塞IO则会不断查询直到设备可用。主要通过wait_queue（等待队列）实现阻塞，它包括等待队列头、添加和移除队列项，以及唤醒机制。例如，DECLARE_WAIT_QUEUE宏为当前进程创建等待队列，wake_up和wake_up_interruptible函数用于唤醒队列中的进程。

       轮询方式，如select、poll和epoll，是通过file_operations的poll函数来实现非阻塞IO。poll函数接收一个poll_table_struct指针，通常通过poll_wait函数添加应用程序到该表中，但并不会阻塞进程。当设备状态改变时，驱动程序会更新poll_table，应用程序将根据返回的资源状态进行相应操作。

       理解这两种IO模型的关键在于理解如何在设备操作中实现进程的挂起和唤醒，以及如何在非阻塞模式下有效地轮询。深入学习Linux内核源码，例如xxetb.xet.tech/s/3jDmTD，可以更好地掌握这些概念。此外，还有丰富的学习资源如书籍、视频等，可以加入学习交流群获取更多资料。

深入理解Linux的epoll机制

       在Linux系统之中有一个核心武器：epoll池，在高并发的，高吞吐的IO系统中常常见到epoll的身影。

IO多路复用

       在Go里最核心的是Goroutine，也就是所谓的协程，协程最妙的一个实现就是异步的代码长的跟同步代码一样。比如在Go中，网络IO的read，write看似都是同步代码，其实底下都是异步调用，一般流程是：

write(/*IO参数*/)请求入队等待完成后台loop程序发送网络请求唤醒业务方

       Go配合协程在网络IO上实现了异步流程的同步代码化。核心就是用epoll池来管理网络fd。

       实现形式上，后台的程序只需要1个就可以负责管理多个fd句柄，负责应对所有的业务方的IO请求。这种一对多的IO模式我们就叫做IO多路复用。

       多路是指？多个业务方（句柄）并发下来的IO。

       复用是指？复用这一个后台处理程序。

       站在IO系统设计人员的角度，业务方咱们没办法提要求，因为业务是上帝，只有你服从的份，他们要创建多个fd，源码输出优点那么你就需要负责这些fd的处理，并且最好还要并发起来。

       业务方没法提要求，那么只能要求后台loop程序了！

       要求什么呢？快！快！快！这就是最核心的要求，处理一定要快，要给每一个fd通道最快的感受，要让每一个fd觉得，你只在给他一个人跑腿。

       那有人又问了，那我一个IO请求（比如write）对应一个线程来处理，这样所有的IO不都并发了吗？是可以，但是有瓶颈，线程数一旦多了，性能是反倒会差的。

       这里不再对比多线程和IO多路复用实现高并发之间的区别，详细的可以去了解下nginx和redis高并发的秘密。

最朴实的实现方式？

       我不用任何其他系统调用，能否实现IO多路复用？

       可以的。那么写个for循环，每次都尝试IO一下，读/写到了就处理，读/写不到就sleep下。这样我们不就实现了1对多的IO多路复用嘛。

whileTrue:foreach句柄数组{ read/write(fd,/*参数*/)}sleep(1s)

       慢着，有个问题，上面的程序可能会被卡死在第三行，使得整个系统不得运行，为什么？

       默认情况下，我们没有加任何参数create出的句柄是阻塞类型的。我们读数据的时候，如果数据还没准备好，是会需要等待的，当我们写数据的时候，如果还没准备好，默认也会卡住等待。所以，在上面伪代码第三行是可能被直接卡死，而导致整个线程都得到不到运行。

       举个例子，现在有，，这3个句柄，现在读写都没有准备好，只要read/write(,/*参数*/)就会被卡住，但，这两个句柄都准备好了，那遍历句柄数组，，的时候就会卡死在前面，后面，则得不到运行。这不符合我们的预期，因为我们IO多路复用的loop线程是公共服务，不能因为一个fd就直接瘫痪。

       那这个问题怎么解决？

       只需要把fd都设置成非阻塞模式。这样read/write的时候，如果数据没准备好，返回EAGIN的错误即可，不会卡住线程，从而整个系统就运转起来了。比如上面句柄还未就绪，那么read/write(,/*参数*/)不会阻塞，只会报个EAGIN的错误，这种错误需要特殊处理，然后loop线程可以继续执行，的读写。

       以上就是最朴实的IO多路复用的实现了。但是日本tron源码好像在生产环境没见过这种IO多路复用的实现？为什么？

       因为还不够高级。for循环每次要定期sleep1s，这个会导致吞吐能力极差，因为很可能在刚好要sleep的时候，所有的fd都准备好IO数据，而这个时候却要硬生生的等待1s，可想而知。。。

       那有同学又要质疑了，那for循环里面就不sleep嘛，这样不就能及时处理了吗？

       及时是及时了，但是CPU估计要跑飞了。不加sleep，那在没有fd需要处理的时候，估计CPU都要跑到%了。这个也是无法接受的。

       纠结了，那sleep吞吐不行，不sleep浪费cpu，怎么办？

       这种情况用户态很难有所作为，只能求助内核来提供机制协助来。因为内核才能及时的管理这些通知和调度。

       我们再梳理下IO多路复用的需求和原理。IO多路复用就是1个线程处理多个fd的模式。我们的要求是：这个“1”就要尽可能的快，避免一切无效工作，要把所有的时间都用在处理句柄的IO上，不能有任何空转，sleep的时间浪费。

       有没有一种工具，我们把一箩筐的fd放到里面，只要有一个fd能够读写数据，后台loop线程就要立马唤醒，全部马力跑起来。其他时间要把cpu让出去。

       能做到吗？能，这种需求只能内核提供机制满足你。

这事Linux内核必须要给个说法？

       是的，想要不用sleep这种辣眼睛的实现，Linux内核必须出手了，毕竟IO的处理都是内核之中，数据好没好内核最清楚。

       内核一口气提供了3种工具select，poll，epoll。

       为什么有3种？

       历史不断改进，矬->较矬->卧槽、高效的演变而已。

       Linux还有其他方式可以实现IO多路复用吗？

       好像没有了！

       这3种到底是做啥的？

       这3种都能够管理fd的可读可写事件，在所有fd不可读不可写无所事事的时候，可以阻塞线程，切走cpu。fd有情况的时候，都要线程能够要能被唤醒。

       而这三种方式以epoll池的效率最高。为什么效率最高？

       其实很简单，这里不详说，其实无非就是epoll做的无用功最少，select和poll或多或少都要多余的拷贝，盲猜（遍历才知道）fd，所以效率自然就低了。

       举个例子，以select和epoll来对比举例，池子里管理了个句柄，loop线程被唤醒的时候，select都是蒙的，都不知道这个fd里谁IO准备好了。这种情况怎么办？只能遍历这个fd，一个个测试。假如只有一个句柄准备好了，那相当于做了1千多倍的无效功。

       epoll则不同，从epoll_wait醒来的时候就能精确的拿到就绪的fd数组，不需要任何测试，拿到的就是要处理的。

epoll池原理

       下面我们看一下epoll池的使用和原理。

epoll涉及的系统调用

       epoll的使用非常简单，只有下面3个系统调用。

epoll_createepollctlepollwait

       就这？是的，就这么简单。

       epollcreate负责创建一个池子，一个监控和管理句柄fd的池子；

       epollctl负责管理这个池子里的fd增、删、改；

       epollwait就是负责打盹的，让出CPU调度，但是只要有“事”，立马会从这里唤醒；

epoll高效的原理

       Linux下，epoll一直被吹爆，作为高并发IO实现的秘密武器。其中原理其实非常朴实：epoll的实现几乎没有做任何无效功。我们从使用的角度切入来一步步分析下。

       首先，epoll的第一步是创建一个池子。这个使用epoll_create来做：

       原型：

intepoll_create(intsize);

       示例：

epollfd=epoll_create();if(epollfd==-1){ perror("epoll_create");exit(EXIT_FAILURE);}

       这个池子对我们来说是黑盒，这个黑盒是用来装fd的，我们暂不纠结其中细节。我们拿到了一个epollfd，这个epollfd就能唯一代表这个epoll池。

       然后，我们就要往这个epoll池里放fd了，这就要用到epoll_ctl了

       原型：

intepoll_ctl(intepfd,intop,intfd,structepoll_event*event);

       示例：

if(epoll_ctl(epollfd,EPOLL_CTL_ADD,,&ev)==-1){ perror("epoll_ctl:listen_sock");exit(EXIT_FAILURE);}

       上面，我们就把句柄放到这个池子里了，op（EPOLL_CTL_ADD）表明操作是增加、修改、删除，event结构体可以指定监听事件类型，可读、可写。

       第一个跟高效相关的问题来了，添加fd进池子也就算了，如果是修改、删除呢？怎么做到时间快？

       这里就涉及到你怎么管理fd的数据结构了。

       最常见的思路：用list，可以吗？功能上可以，但是性能上拉垮。list的结构来管理元素，时间复杂度都太高O(n)，每次要一次次遍历链表才能找到位置。池子越大，性能会越慢。

       那有简单高效的数据结构吗？

       有，红黑树。Linux内核对于epoll池的内部实现就是用红黑树的结构体来管理这些注册进程来的句柄fd。红黑树是一种平衡二叉树，时间复杂度为O(logn)，就算这个池子就算不断的增删改，也能保持非常稳定的查找性能。

       现在思考第二个高效的秘密：怎么才能保证数据准备好之后，立马感知呢？

       epoll_ctl这里会涉及到一点。秘密就是：回调的设置。在epoll_ctl的内部实现中，除了把句柄结构用红黑树管理，另一个核心步骤就是设置poll回调。

       思考来了：poll回调是什么？怎么设置？

       先说说file_operations->poll是什么？

       在fd篇说过，Linux设计成一切皆是文件的架构，这个不是说说而已，而是随处可见。实现一个文件系统的时候，就要实现这个文件调用，这个结构体用structfile_operations来表示。这个结构体有非常多的函数，我精简了一些，如下：

structfile_operations{ ssize_t(*read)(structfile*,char__user*,size_t,loff_t*);ssize_t(*write)(structfile*,constchar__user*,size_t,loff_t*);__poll_t(*poll)(structfile*,structpoll_table_struct*);int(*open)(structinode*,structfile*);int(*fsync)(structfile*,loff_t,loff_t,intdatasync);//....};

       你看到了read，write，open，fsync，poll等等，这些都是对文件的定制处理操作，对于文件的操作其实都是在这个框架内实现逻辑而已，比如ext2如果有对read/write做定制化，那么就会是ext2_read，ext2_write，ext4就会是ext4_read，ext4_write。在open具体“文件”的时候会赋值对应文件系统的file_operations给到file结构体。

       那我们很容易知道read是文件系统定制fd读的行为调用，write是文件系统定制fd写的行为调用，file_operations->poll呢？

       这个是定制监听事件的机制实现。通过poll机制让上层能直接告诉底层，我这个fd一旦读写就绪了，请底层硬件（比如网卡）回调的时候自动把这个fd相关的结构体放到指定队列中，并且唤醒操作系统。

       举个例子：网卡收发包其实走的异步流程，操作系统把数据丢到一个指定地点，网卡不断的从这个指定地点掏数据处理。请求响应通过中断回调来处理，中断一般拆分成两部分：硬中断和软中断。poll函数就是把这个软中断回来的路上再加点料，只要读写事件触发的时候，就会立马通知到上层，采用这种事件通知的形式就能把浪费的时间窗就完全消失了。

       划重点：这个poll事件回调机制则是epoll池高效最核心原理。

       划重点：epoll池管理的句柄只能是支持了file_operations->poll的文件fd。换句话说，如果一个“文件”所在的文件系统没有实现poll接口，那么就用不了epoll机制。

       第二个问题：poll怎么设置？

       在epoll_ctl下来的实现中，有一步是调用vfs_poll这个里面就会有个判断，如果fd所在的文件系统的file_operations实现了poll，那么就会直接调用，如果没有，那么就会报告响应的错误码。

staticinline__poll_tvfs_poll(structfile*file,structpoll_table_struct*pt){ if(unlikely(!file->f_op->poll))returnDEFAULT_POLLMASK;returnfile->f_op->poll(file,pt);}

       你肯定好奇poll调用里面究竟是实现了什么？

       总结概括来说：挂了个钩子，设置了唤醒的回调路径。epoll跟底层对接的回调函数是：ep_poll_callback，这个函数其实很简单，做两件事情：

       把事件就绪的fd对应的结构体放到一个特定的队列（就绪队列，readylist）；

       唤醒epoll，活来啦！

       当fd满足可读可写的时候就会经过层层回调，最终调用到这个回调函数，把对应fd的结构体放入就绪队列中，从而把epoll从epoll_wait出唤醒。

       这个对应结构体是什么？

       结构体叫做epitem，每个注册到epoll池的fd都会对应一个。

       就绪队列很高级吗？

       就绪队列就简单了，因为没有查找的需求了呀，只要是在就绪队列中的epitem，都是事件就绪的，必须处理的。所以就绪队列就是一个最简单的双指针链表。

       小结下：epoll之所以做到了高效，最关键的两点：

       内部管理fd使用了高效的红黑树结构管理，做到了增删改之后性能的优化和平衡；

       epoll池添加fd的时候，调用file_operations->poll，把这个fd就绪之后的回调路径安排好。通过事件通知的形式，做到最高效的运行；

       epoll池核心的两个数据结构：红黑树和就绪列表。红黑树是为了应对用户的增删改需求，就绪列表是fd事件就绪之后放置的特殊地点，epoll池只需要遍历这个就绪链表，就能给用户返回所有已经就绪的fd数组；

哪些fd可以用epoll来管理？

       再来思考另外一个问题：由于并不是所有的fd对应的文件系统都实现了poll接口，所以自然并不是所有的fd都可以放进epoll池，那么有哪些文件系统的file_operations实现了poll接口？

       首先说，类似ext2，ext4，xfs这种常规的文件系统是没有实现的，换句话说，这些你最常见的、真的是文件的文件系统反倒是用不了epoll机制的。

       那谁支持呢？

       最常见的就是网络套接字：socket。网络也是epoll池最常见的应用地点。Linux下万物皆文件，socket实现了一套socket_file_operations的逻辑（net/socket.c）：

staticconststructfile_operationssocket_file_ops={ .read_iter=sock_read_iter,.write_iter=sock_write_iter,.poll=sock_poll,//...};

       我们看到socket实现了poll调用，所以socketfd是天然可以放到epoll池管理的。

       还有吗？

       有的，其实Linux下还有两个很典型的fd，常常也会放到epoll池里。

       eventfd：eventfd实现非常简单，故名思义就是专门用来做事件通知用的。使用系统调用eventfd创建，这种文件fd无法传输数据，只用来传输事件，常常用于生产消费者模式的事件实现；

       timerfd：这是一种定时器fd，使用timerfd_create创建，到时间点触发可读事件；

       小结一下：

       ext2，ext4，xfs等这种真正的文件系统的fd，无法使用epoll管理；

       socketfd，eventfd，timerfd这些实现了poll调用的可以放到epoll池进行管理；

       其实，在Linux的模块划分中，eventfd，timerfd，epoll池都是文件系统的一种模块实现。

思考

       前面我们已经思考了很多知识点，有一些简单有趣的知识点，提示给读者朋友，这里只抛砖引玉。

       问题：单核CPU能实现并行吗？

       不行。

       问题：单线程能实现高并发吗？

       可以。

       问题：那并发和并行的区别是？

       一个看的是时间段内的执行情况，一个看的是时间时刻的执行情况。

       问题：单线程如何做到高并发？

       IO多路复用呗，今天讲的epoll池就是了。

       问题：单线程实现并发的有开源的例子吗？

       redis，nginx都是非常好的学习例子。当然还有我们Golang的runtime实现也尽显高并发的设计思想。

总结

       IO多路复用的原始实现很简单，就是一个1对多的服务模式，一个loop对应处理多个fd；

       IO多路复用想要做到真正的高效，必须要内核机制提供。因为IO的处理和完成是在内核，如果内核不帮忙，用户态的程序根本无法精确的抓到处理时机；

       fd记得要设置成非阻塞的哦，切记；

       epoll池通过高效的内部管理结构，并且结合操作系统提供的poll事件注册机制，实现了高效的fd事件管理，为高并发的IO处理提供了前提条件；

       epoll全名eventpoll，在Linux内核下以一个文件系统模块的形式实现，所以有人常说epoll其实本身就是文件系统也是对的；

       socketfd，eventfd，timerfd这三种”文件“fd实现了poll接口，所以网络fd，事件fd，定时器fd都可以使用epoll_ctl注册到池子里。我们最常见的就是网络fd的多路复用；

       ext2，ext4，xfs这种真正意义的文件系统反倒没有提供poll接口实现，所以不能用epoll池来管理其句柄。那文件就无法使用epoll机制了吗？不是的，有一个库叫做libaio，通过这个库我们可以间接的让文件使用epoll通知事件，以后详说，此处不表；

后记

       epoll池使用很简洁，但实现不简单。还是那句话，Linux内核帮你包圆了。

       今天并没有罗列源码实现，以很小的思考点为题展开，简单讲了一些epoll的思考，以后有机会可以分享下异步IO（aio）和epoll能产生什么火花？Golang是怎样使用epoll池的？敬请期待哦。

       原创不易，更多干货，关注：奇伢云存储

select，poll，epoll的区别以及使用方法

       在Linux网络编程中，I/O多路复用技术如select、poll和epoll，旨在提高服务器与多个客户端连接的并发处理能力。原生socket的阻塞特性限制了它无法同时处理多个请求。为了解决这个问题，我们有以下选项：

       1. select：最早出现在年的4.2BSD中，它允许监控多个描述符，一旦就绪即通知程序。尽管跨平台支持好，但存在最大文件描述符数量（Linux默认）的限制，且随着文件描述符增多，复制开销和扫描所有socket的开销会增加。

       2. poll：年System V Release 3引入，没有select的最大文件描述符限制。同样会复制大量描述符，开销随描述符数量线性增加。poll也采用水平触发机制，但处理大量就绪描述符时效率较低。

       3. epoll：Linux 2.6及以后引入，是最高效的方法。epoll支持事件回调，减少拷贝开销，对大量描述符更友好。它支持水平触发和边缘触发，边缘触发理论上性能更高，但实现复杂。epoll_wait只需检查就绪链表，而不是遍历所有描述符，节省CPU时间。

       总结来说，epoll通过内核回调机制，优化了描述符的管理，降低了开销，并提供了灵活性。使用epoll时，可以借助epoll_create、epoll_ctl和epoll_wait这三个核心函数，如在echo服务器的示例中操作。具体实现和详细机制请参考《select，poll，epoll的区别以及使用方法》文章及源代码。

一文分析Linux内核OOM机制（值得收藏）

       Linux内核通过过度分配内存策略，间接利用未被完全使用的内存，以提高整体内存效率。然而，当内存需求超过物理内存时，OOM killer机制会介入，通过杀掉占用内存过大的进程来保证系统运行。这就像银行面对全民取款压力时，会限制部分账户的取款。oom killer会在日志中记录操作，如"Out of Memory: Kill process (sshd)"，表明sshd进程被杀以缓解内存压力。

       oom killer机制针对内存占用过大且瞬间消耗的进程进行监控，通过内核源代码linux/mm/oom_kill.c中的算法，如select_bad_process()和oom_badness()来决定优先杀死哪个进程。进程的oom_score是决定因素，调整oom_adj参数可以控制进程被优先级杀掉的可能性，如将MySQL进程的oom_adj设置为-，可以降低其被杀概率。

       在极端情况下，可以通过设置内核参数vm.overcommit_memory来调整内存分配策略，甚至完全禁止过度分配。此外，可以通过查看/proc/PID/oom_adj或oom_score来找出最易被oom killer杀死的进程，并进行相应的调整。需要注意，oom killer不适用于解决内存泄漏问题，且在某些旧版本的内核中，oom killer的精确性可能存在不足。

       为了验证OOM机制，可以手动创建大内存占用的进程，观察其被杀死的动态过程。通过设置oom_adj参数，可以主动控制哪些进程在内存不足时被优先保护。同时，内核提供了设置来决定在内存严重不足时是直接panic还是执行oom killer，以便在必要时进行系统重启或保护关键进程。

Linux之字符设备驱动-poll方法（select多路监控原理与实现）

       本文主要介绍Linux高级字符设备驱动中的poll方法，特别是select多路监控原理与实现。了解此方法对深入理解Linux内核机制具有重要参考价值。

       首先，需明确poll方法定义及其功能。它是一种多路监控技术，允许系统同时监控多个文件描述符，当有一个或多个描述符准备就绪时，系统将返回这些描述符。

       具体而言，select系统调用是实现这一功能的关键。其参数包括最大文件描述符范围、读取监控的文件描述符集、写入监控的文件描述符集、异常监控的文件描述符集以及定时器。调用时，若文件描述符满足条件，返回文件描述符个数；若等待超时，返回0；若中断由信号触发，返回-1并设置errno为EINTR；若发生错误，则返回-1并设置相应errno。

       使用方法包括：添加监控文件描述符、调用select开始监控、判断文件描述符变化。此外，系统提供四个性能提升宏：FD_SET、FD_CLR、FD_ZERO、FD_ISSET，用于文件描述符集操作。调用select后，使用FD_ISSET检测描述符变化。

       对于poll方法，其功能在于简化select调用，允许驱动程序登记设备状态，由系统决定何时阻塞。该方法返回设备的可读性和可写性掩码，通常返回设备可读或可写的状态。

       通过实例分析，可以更直观地理解poll方法在memdev.h、memdev.c和app-read.c源码中的应用。这些实例展示了如何将poll方法应用于实际驱动程序中，实现高效、灵活的设备管理。

       总之，poll方法是Linux高级字符设备驱动中实现多路监控的核心技术。理解其原理和应用，对于深入掌握Linux内核机制具有重要意义。