file 提供了一套unix文件描述符操作管理接口。用于管理所有Linux文件操作和socket通信。并提供了相关的注册、更新、删除的api接口。
epoll是Linux提供的I/O event notification facility。在需要监听的fd数量很多（成千上万）而同一时刻可读/可写的数量又比较少（几个？几十个？几百个？）的情况下，性能要明显优于select、poll。
又到周六了，不过这周有点忙新文章还没有写，为了不跳票，就想着把早期还不错的文章，重新排版修改发一下，因为当时读者很少，现在而言完全可以当作一篇新文章(有种狡辩的意思)...
概述 Selector是NIO中实现I/O多路复用的关键类。Selector实现了通过一个线程管理多个Channel，从而管理多个网络连接的目的。 Channel代表这一个网络连接通道，我们可以将Channel注册到Selector中以实现Selector对其的管理。一个Channel可以注册到多个不同的Selector中。 当Channel注册到Selector后会返回一个SelectionKey对象，该SelectionKey对象则代表这这个Channel和它注册的Selector间的关系。并且Se
epoll简介 epoll 是Linux内核中的一种可扩展IO事件处理机制，最早在 Linux 2.5.44内核中引入，可被用于代替POSIX select 和 poll 系统调用，并且在具有大量应用程序请求时能够获得较好的性能（ 此时被监视的文件描述符数目非常大，与旧的 select 和 poll 系统调用完成操作所需 O(n) 不同， epoll能在O(1)时间内完成操作，所以性能相当高），epoll 与 FreeBSD的kqueue类似，都向用户空间提供了自己的文件描述符来进行操作。 [cpp]
输入输出(input/output)的对象可以是文件(file)， 网络(socket)，进程之间的管道(pipe)。在linux系统中，都用文件描述符(fd)来表示。
epoll机制是Linux下一种高效的IO复用方式，相较于select和poll机制来说。其高效的原因是将基于事件的fd放到内核中来完成，在内核中基于红黑树+链表数据结构来实现，链表存放有事件发生的fd集合，然后在调用epoll_wait时返回给应用程序，由应用程序来处理这些fd事件。
并不久远之前，设置单个Web服务器以支持10,000个并发连接还是一项伟大的壮举。有许多因素使开发这样的Web服务器成为可能，例如nginx，它比以前的服务器可以处理更多的连接，效率更高。最大的因素之一是用于监视文件描述符的常量时间polling（O(1)）机制，被大多数操作系统所采用。
这里需要了解vpp启动过程中存在初始化宏函数的执行顺序。当前unix cli相关资源的使用就依赖这个顺序来保证的。下面先来了解一下：
在用C++实现一个定时任务框架文章中实现了一个定时任务的框架，本文将将继续针对定时任务进行介绍帮助大家根据具体的应用场景选择合适的方式。
epoll有EPOLLLT和EPOLLET两种触发模式，水平触发和边缘触发. 此处略
虽然市面上已经有很多成熟的网络库，但是编写一个自己的网络库依然让我获益匪浅，这篇文章主要包含：
设想一个场景：有100万用户同一时候与一个进程保持着TCP连接，而每个时刻仅仅有几十个或几百个TCP连接时活跃的（接收到TCP包），也就是说，在每一时刻，进程值须要处理这100万连接中的一小部分连接。那么，怎样才干高效地处理这样的场景呢？进程是否在每次询问操作系统收集有事件发生的TCP连接时，把这100万个连接告诉操作系统，然后由操作系统找出当中有事件发生的几百个连接呢？实际上，在Linux内核2.4版本号曾经，那时的select或者poll事件驱动方式就是这样做的。
linux的空间分为kernel space 和 user space, 比例是1:3
在 Linux 系统之中有一个核心武器：epoll 池，在高并发的，高吞吐的 IO 系统中常常见到 epoll 的身影。
在之前的Netty之线程唤醒wakeup文章中, 介绍了如何唤醒Netty中的监听线程. 接下来我们通过部分源码,结合一些命令和实验,看一下它的实现.
在上一篇文章里我们介绍了 tomcat io 主要包含那些 items，在这里我们主要介绍tomcat io 的基础-多路复用。tomcat 服务器(tomcat7以上)默认使用 java NIO 模型，NIO 不仅仅需要 java 语言上的支持，同时还离不开各种操作系统对于多路复用的支持(linux，windows，mac 等等)，所以 tomcat的NIO 是建立在操作系统基础之上的。
什么是epoll epoll是什么？按照man手册的说法：是为处理大批量句柄而作了改进的poll。当然，这不是2.6内核才有的，它是在2.5.44内核中被引进的(epoll(4) is a new API introduced in Linux kernel 2.5.44)，它几乎具备了之前所说的一切优点，被公认为Linux2.6下性能最好的多路I/O就绪通知方法。 epoll的相关系统调用 epoll只有epoll_create,epoll_ctl,epoll_wait 3个系统调用。 1. int ep
相比于select，epoll最大的好处在于它不会随着监听fd数目的增长而降低效率。因为在内核中的select实现中，它是采用轮询来处理的，轮询的fd数目越多，自然耗时越多。 并且，在linux/posix_types.h头文件有这样的声明： #define __FD_SETSIZE 1024 表示select最多同时监听1024个fd，当然，可以通过修改头文件再重编译内核来扩大这个数目，但这似乎并不治本。
本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看
在这个连接的生命周期里，绝大部分时间都是空闲的，活跃时间（发送数据和接收数据的时间）占比极少，这样独占一个服务器是严重的资源浪费。事实上所有的服务器都是高并发的，可以同时为成千上万个客户端提供服务，这一技术又被称为IO复用。
epoll 是 Linux 平台下特有的一种 I/O 复用模型实现，于 2002 年在 Linux kernel 2.5.44 中被引入。在 epoll 之前，Unix/Linux 平台下的 I/O 复用模型包含 select 和 poll 两个系统调用。随着因特网的发展，因特网的用户量越来越大，C10K 问题出现。基于 select 和 poll 编写的网络服务已经不能满足不能满足用户的需求了，业界迫切希望更高效的系统调用出现。在此背景下，FreeBSD 的 kqueue 和 Linux 的 epoll 被研发了出来。kqueue 和 epoll 的出现，终结了 C10K 问题，C10K 问题就此作古。
通过前面的文章我们已经了解了「数据包从HTTP层->TCP层->IP层->网卡->互联网->目的地服务器」以及「数据包怎么从网线到进程，在被应用程序使用」涉及的知识。 本文将继续介绍网络编程中的各种细节和IO多路复用的原理。
Redis的高性能和他的事件模型是密不可分的，最大程度上利用了单线程、非阻塞IO模型来快速的处理请求（单线程处理多链接）。这里存在一个问题，其实严格意义上来讲，Redis 是单线程对外提供服务，redis内部并不单线程的，还存在一些关于数据持久化的线程。
同步阻塞IO在等待数据就绪上花去太多时间，而传统的同步非阻塞IO虽然不会阻塞进程，但是结合轮询来判断运维
I/O基础 1、java1.4之前，java对I/O支持不完善，存在以下问题： 没有数据缓冲区，I/O性能存在问题。 没有C或者C++的channel概念，只有输入输出流。 同步式阻塞式I/O通信，通常会导致通信线程被长时间阻塞。 支持的字符集有限，硬件可移植性不好。 2、Linux网络I/O模型 Linux内核将所有外部设备都看作一个文件来操作，对文件的操作都会调用内核提供的系统命令，返回一个fd(文件描述符)。 描述符就是一个数字，它指向内核中的一个结构体(文件路径，数据区等属性)。 fd演示:
所谓惊群现象,简单的来说就是当多个进程或线程在同时阻塞等待同一个事件时,如果该事件发生,会唤醒在等待的所有的进程/线程,但最终只可能有一个进程/线程对该事件进行处理,其他进程/线程会在失败后重新休眠,唤醒多个进程/线程这种不必要的行为会造成系统资源的浪费(涉及到进程的上下文切换)。而常见的惊群问题有accept惊群、epoll惊群。
在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在大数据、高并发、集群等一些名词唱得火热之年代，select和poll的用武之地越来越有限，风头已经被epoll占尽。
select、poll 和 epoll 都是 Linux API 提供的 IO 复用方式。
本文来自 Marek’s 博客中 I/O multiplexing part 系列之三和四，原文一共有四篇，主要讲 Linux 上 IO 多路复用的一些问题，本文加入了我的一些个人理解，如有不对之处敬请指出。原文链接如下：
在前文中讲述了Linux服务端TCP的某个链路变成CLOSE_WAIT状态，然后由于客户端已经关闭了（发送了RST标志的报文），那么服务端如果继续向这个链路中写入数据的话就会收到SIGPIPE信号而终止，这篇文章主要通过客户端进入CLOSE_WAIT后由于收到服务端产生的RST标志报文进入死循环的情况。注：RST表示复位，用来关闭异常的连接。
IO模型 只关注IO，不关注IO读写完成后的事情。 同步：程序（APP）自己进行读/写操作 异步：由Kernel完成读/写，程序跑起来感觉像没有访问IO，访问的是buffer 阻塞：BLOCKING，一直等待着方法有效的返回结果 非阻塞：NONBLOCKING，调用方法的时候就返回是否读取到，（java中要么返回null，要么返回具体的对象） 所以IO模型有： 同步阻塞：程序（APP）自己读取，调用了方法后一直等待着有效的返回结果 同步非阻塞：程序（APP）自己读取，调用方法的瞬间就给出是否读取到的返回结
本文从操作系统的角度来解释BIO，NIO，AIO的概念，含义和背后的那些事。本文主要分为3篇。 第一篇讲解BIO和NIO以及IO多路复用 第二篇讲解AIO和文件IO 第三篇讲解在这些机制上的一些应用的实现方式，比如nginx，nodejs，Java NIO等 到底什么是“IO Block” 很多人说BIO不好，会“block”，但到底什么是IO的Block呢？考虑下面两种情况： 用系统调用read从socket里读取一段数据 用系统调用read从一个磁盘文件读取一段数据到内存 如果你的直觉告诉你，这两种都算
I/O多路复用有很多种实现。在linux上，2.4内核前主要是select和poll，自Linux 2.6内核正式引入epoll以来，epoll已经成为了目前实现高性能网络服务器的必备技术。尽管他们的使用方法不尽相同，但是本质上却没有什么区别。本文将重点探讨将放在EPOLL的实现与使用详解。
很多人说BIO不好，会“block”，但到底什么是IO的Block呢？考虑下面两种情况：
在Linux系统编程中，IO流（Input/Output Streams）是一个非常重要的概念。高级IO流是基于基本IO操作（如read、write等）之上的扩展，提供了更强大的功能和更高效的操作方式。本文将深入探讨Linux中的高级IO流，重点介绍其原理和使用方法，并提供相应的C++代码示例。
首先,我们要了解IO复用模型之前,先要了解在Linux内核中socket事件机制在内核底层是基于什么机制实现的,它是如何工作的,其次,当我们对socket事件机制有了一个基本认知之后,那么我们就需要思考到底什么是IO复用,基于socket事件机制的IO复用是怎么实现的,然后我们才来了解IO复用具体的实现技术,透过本质看select/poll/epoll的技术优化,逐渐去理解其中是为了解决什么问题而出现的,最后本文将围绕上述思维导图列出的知识点进行分享,还有就是文章幅度较长且需要思考,需要认真阅读!
本文从操作系统的角度来解释BIO，NIO，AIO的概念，含义和背后的那些事。本文主要分为3篇。 第一篇 讲解BIO和NIO以及IO多路复用 第二篇 讲解磁盘IO和AIO 第三篇 讲解在这些机制上的一些应用的实现方式，比如nginx，nodejs，Java NIO等 磁盘IO 磁盘IO，简单来说就是读取硬盘一类设备的IO。这类设备包括传统的磁盘、SSD、闪存、CD等。操作系统将其统一抽象为”块设备“。所以磁盘IO又可以叫做”块IO“。这些设备上的数据一般用文件系统来组织，所以又可以成为”文件IO“。本文统
磁盘IO，简单来说就是读取硬盘一类设备的IO。这类设备包括传统的磁盘、SSD、闪存、CD等。操作系统将其统一抽象为”块设备“。所以磁盘IO又可以叫做”块IO“。这些设备上的数据一般用文件系统来组织，所以又可以成为”文件IO“。本文统一用”磁盘IO“这个术语。
如果出现了很多的客户端连接，比如1000个，那么应用程序就会启用1000个进程或线程阻塞等待。此时会出现性能问题：
我们都知道Linux的IO模型有阻塞、非阻塞、SIGIO、多路复用(select，epoll)、AIO（异步I/O）等。
作者：morganhuang，腾讯 IEG 后台工程师 "惊群"简单地来讲，就是多个进程(线程)阻塞睡眠在某个系统调用上，在等待某个 fd(socket)的事件的到来。当这个 fd(socket)的事件发生的时候，这些睡眠的进程(线程)就会被同时唤醒，多个进程(线程)从阻塞的系统调用上返回，这就是"惊群"现象。"惊群"被人诟病的是效率低下，大量的 CPU 时间浪费在被唤醒发现无事可做，然后又继续睡眠的反复切换上。本文谈谈 linux socket 中的一些"惊群"现象、原因以及解决方案。 1. A
socket编程的demo中使用的都是最基本的，但是一般不会真正用在项目中的代码。而实际项目中，需要面临复杂多变的需求环境，比如有多个socket连接，或者服务需要监听的时候，可能有很多socket连接进来。面对这种情况，最直接最简单的想法是，一个socket连接创建一个线程去处理。当然，在socket连接数较少的情况下，这种方式无可厚非，但是如果连接数量较大，就会出现意外情况。
网络I/O，可以理解为网络上的数据流。通常我们会基于socket与远端建立一条TCP或者UDP通道，然后进行读写。单个socket时，使用一个线程即可高效处理；然而如果是10K个socket连接，或者更多，我们如何做到高性能处理？
在linux 没有实现epoll事件驱动机制之前，我们一般选择用select或者poll等IO多路复用的方法来实现并发服务程序。在linux新的内核中，有了一种替换它的机制，就是epoll。
今天给大家分享一篇万字长文《微言 Netty：百万并发基石上的 epoll 之剑》。
Selector（选择器）是Java NIO中能够检测一到多个NIO通道，并能够知晓通道是否为诸如读写事件做好准备的组件。这样，一个单独的线程可以管理多个channel，从而管理多个网络连接。 首先看一下Selector相关API： 1.selector 的创建：
相信很多人知道石中剑这个典故，在此典故中，天命注定的亚瑟很容易的就拔出了这把石中剑，但是由于资历不被其他人认可，所以他颇费了一番周折才成为了真正意义上的英格兰全境之王，亚瑟王。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
