javaepoll网络编程(java基于nio网络编程代码)

Java学会那些知识找工作才不费力?

很多Java初学者会关心这么一个问题——Java学到什么程度就可以出去找工作了?大家的目标都很明确，也很实在，学习Java无非就是为了找个工作，使自己和家人生活更好。那到底要学到那些Java知识，就可以去找第一份工作了呢?下面咱们就以公司大小运用到的技术来解答，为什么这样说呢，小型的公司肯定没有大型公司运用到的知识多，从另一个角度来看，大家也可以来测试一下自我学到的知识符合去一个什么样的企业。下面是我给大家总结和介绍。1、中小型公司：这类公司可以说特别的多，招聘和培训可能会有自己的一套标准，比如学历上可能稍微做一些要求，技术上的把关也会有一定的方法，除了Java基础知识和项目经历之外，可能还会考查你的debug能力，代码规范、异常处理能力，以及对一些Java高级特性的理解能力，可能最好多用过一些框架。总而言之，这类公司选人的标准已经拥有了自我体系，不会像一些特别小的公司，招人很随意，领导拍个板就行。当然，这类公司也吸引不到太多优秀人的人才，但是也确实可能会有一些踏实能干的勤奋员工。2、大中型公司：这类公司一般都会要求本科学历，对Java基础知识要比较熟悉，最好能够看过源码，如果没看过，那么源码方面的面试题好歹也要准备一下，除此之外，一般来说还会考察你的后端技术知识，比如数据库、网络、操作系统，考察的不会太难，能把面经上的知识点掌握了就算是比较扎实了。这类公司一般不会考太复杂的题目，更希望招一些水平能力都是中等的人才，只要知识面能比较广，题目都能说到点子上，不需要掌握得特别深入，也可以有机会拿到offer。其实归结原因，就是因为二三线互联网不太可能和一线公司争夺一线人才，所以一般争取的都是二线人才，不需要太优秀，但是至少要是中等水平，所以这些公司对很多程序员来说还是比较有机会的。3、特大型公司：要进这些公司，不仅要做到之前那些事情：掌握Java基础、计算机基础知识，并且是非常熟练地掌握，你需要深入理解每一个知识点，因为面试官会不断深入地向你提问，了解你的知识深度，同时，你需要对源码有所理解，在读懂源码的基础上去理解框架的实现、JDK的实现。另外，你需要对JVM有一个清晰的认识，不仅要了解其结构，垃圾回收原理，甚至还要知道如何在遇到线上问题时通过JVM调优来解决它们。同理，你还需要对Java并发编程和网络编程的使用方法与底层实现原理非常熟悉，不仅仅答出NIO和BIO的区别，或者是synchronized和lock的区别，你还需要知道NIO的底层实现epoll是什么，synchronized对应的mutexlock是什么，lock和condition的实现原理又是什么，而lock本身也是通过AQS、CAS操作类等组件来实现的，其中的内容实在太多，绝不只是几道面试题就可以搞定的。当然，除此之外，这些公司对数据库、缓存、分布式技术等方面的要求都会比其他公司要高得多，你最好要搞懂MySQL的存储引擎、索引和锁的实现原理，Redis缓存的数据结构、备份方式、底层实现。同时如果你能理解负载均衡算法、CAP理论，甚至是raft和paxos算法，以及分布式常用技术如消息队列、zookeeper等等，那么无疑也是可以为你加分的技能。为什么大公司的要求这么高，因为它们是最好的互联网公司，要招的自然也是最优秀的人才，如果考察底层原理还不能满足他们筛选人才的需要，他们也会考察面试者的算法能力，比如LeetCode上medium难度的原题，或者是剑指offer的变式题等等，算法题相对考察理论基础而言，筛选度更高，可以淘汰的人也更多。

java自学到什么程度就能找工作了

很多同学都关心Java学到什么程度才可以找到满意的工作。大家的目标都很明确，也很实在，学习Java无非就是为了找工作。

那到底要学多少Java知识，掌握多少技能，才可以找到一份满意的工作呢？

其实想要找一份小公司的开发工作不算非常难，毕竟互联网公司很多，要求也是天差地别，对技术、学历、实践能力的要求和评价标准也有很大的差距。但是进大厂的要求可就非常高了。

所以，到底Java学到什么程度才能找到第一份工作，我想应该用公司来作为变量，这样回答这个问题才有意义。

1、中小型公司

说到中小型公司，我们泛指那些500名以下员工，有稳定资金来源并且可以自我造血的公司，这类公司招聘和培训可能会有自己的一套标准。

比如学历上可能稍微做一些要求，技术上的把关更严格一点，除了Java基础知识和项目经历之外，可能还会考查你的debug能力，代码规范、异常处理能力，以及对一些Java高级特性的理解能力，以及框架的应用水平。

总而言之，这类公司选人的标准更加有体系，标准也更高。

2、二三线互联网公司

这类公司范围就很广了，比如搜狐、新浪、360、携程这类现状比较不错的企业等等，这类公司挤不到BAT TMD等一线互联网行列，但是在二三线阵容还算是比较不错的公司，它们对于人才的要求其实还是相对比较高的。

比如一般都会要求本科学历，对Java基础知识要比较熟悉，最好能够看过源码，如果没看过，那么源码方面的面试题好歹也要准备一下，除此之外，一般来说还会考察你的后端技术知识，比如数据库、网络、操作系统，考察的不会太难，能把面经上的知识点掌握了就算是比较扎实了。

这类公司一般不会考太复杂的题目，更希望招一些水平能力都是中上等的人才，只要知识面能比较广，题目都能说到点子上，也可以有机会拿到offer。

3、一线互联网公司

BAT、TMD等互联网名企都属于这类公司，这类公司和二三线互联网公司的发展差距还是比较大的，体现在公司的规模、市值、甚至是股价等方面，业务以技术为基础，因此这些公司的技术往往也是业界最顶尖的，比如阿里的云计算和中间件，头条的推荐算法、腾讯的游戏技术等等。

要进这些公司，不仅要做到之前那些事情：掌握Java基础、计算机基础知识，并且是非常熟练地掌握，你需要深入理解每一个知识点，因为面试官会不断深入地向你提问，了解你的知识深度，同时，你需要对源码有所理解，在读懂源码的基础上去理解框架的实现、JDK的实现。

并且，你还需要对Java并发编程和网络编程的使用方法与底层实现原理非常熟悉，不仅仅答出NIO和BIO的区别，或者是synchronized和lock的区别，你还需要知道NIO的底层实现epoll是什么，synchronized对应的mutex lock是什么，lock和condition的实现原理又是什么，而lock本身也是通过AQS、CAS操作类等组件来实现的，其中的内容实在太多，绝不只是几道面试题就可以搞定的。

当然，除此之外，这些公司对数据库、缓存、分布式技术等方面的要求都会比其他公司要高得多，你最好要搞懂MySQL的存储引擎、索引和锁的实现原理，Redis缓存的数据结构、备份方式、底层实现。

同时如果你能理解负载均衡算法、CAP理论，甚至是raft和paxos算法，以及分布式常用技术如消息队列、zookeeper等等，那么无疑也是可以为你加分的技能。

分享下学习路线，按照上面的路线学习，学完后找到工作不成问题！

世上无难事，只怕有心人，只要你真的想学并努力去学，你就能成功。

另外，如果自学没有资料的话，可私聊我获取，免费提供哦~

希望能帮到你，望采纳！

java网络io模型有几种

#BIO---Blocking IO

- 每个socket一个线程，读写时线程处于阻塞状态。

优点：实现简单

缺点：无法满足高并发，高接入的需求

- 不使用线程池的BIO模型，除了无法满足高并发需求外，由于需要为每个请求创建一个线程，还可能因为接入大量不活跃连接而耗尽服务器资源。

- 使用线程池的BIO模型，虽然控制了线程数量，但由于其本质上读写仍是阻塞的，仍无法满足高并发需求。

#NIO---Non-Blocking IO（非阻塞IO）

##非阻塞IO和多路复用

非阻塞IO和多路复用实际上是两个不用的概念，由于两者通常结合在一起使用，因此两者往往被混为一谈。下面我将试着分清这两个概念：

###非阻塞IO

与BIO相对应，非阻塞IO的读写方法无论是否有数据都立即返回，因此可以通过轮询方式来实现，但轮询方式的效率并不比BIO有显著提高，因为每个连接仍然需要占用一个线程。下面是轮询方式实现的IO模式图：

###多路复用

- 多路复用结合非阻塞IO能够明显提高IO的效率，这也是Java1.4把非阻塞IO和多路复用同时发布的原因。

- 多路复用的核心是多路复用器(Selector)，它是需要操作系统底层支持的，简单的说，就是进程把多个socket和它们关心的事件（比如连接请求或数据已准备好）都注册在多路复用器上，操作系统会在事件发生时通知多路复用器，这样进程就可以通过多路复用器知道在那个socket上发生了什么时间，从而进行对应的处理。

- 多路复用的优点在于只需要一个线程监测（阻塞或轮询方式均可）多路选择器的状态，只有在有事件需要发生时才会真正的创建线程进行处理，因此更适合高并发多接入的应用环境。

- 在Linux系统下，多路复用的底层实现是epoll方法，与select/poll的顺序扫描不同，epoll采用效率更高的事件驱动方式，而且epoll方式并没有socket个数限制。

##BIO和NIO的比较

- BIO适用于连接长期保持的应用，比如一个复杂系统中模块之间通过长连接来进行通信。

- NIO加多路复用的模式更适合短连接、高并发、多接入的情形，比如网络服务器。

##NIO网络编程的常用接口

##Reactor模式

Reactor模式用于解决事件分发处理的问题，Handler把自己的channel和关注的事件注册到Selector中，当对应的事件发生在自己的channel上时，对应的handler就会得到通知并进行处理。

- 单线程的Reactor

消息的分发、读写、处理都在一个线程中处理，是Reactor最简单的实现方式，如果消息的处理需要较长时间，会影响效率。

```java

//Reactor类，负责分发事件并调用对应的handler

class Reactor implements Runnable {

final Selector selector;

final ServerSocketChannel serverSocket;

//Reactor初始化

Reactor(int port) throws IOException {

selector = Selector.open();

serverSocket = ServerSocketChannel.open();

serverSocket.socket().bind(new InetSocketAddress(port));

serverSocket.configureBlocking(false); //必须配置为非阻塞

//Acceptor会在Reactor初始化时就注册到Selector中，用于接受connect请求

SelectionKey sk = serverSocket.register(selector, SelectionKey.OP_ACCEPT);

sk.attach(new Acceptor()); //attach callback object, Acceptor

}

//分发消息并调用对应的handler

public void run() {

try {

while (!Thread.interrupted()) {

selector.select();

Set selected = selector.selectedKeys();

Iterator it = selected.iterator();

while (it.hasNext())

dispatch((SelectionKey)(it.next()); //Reactor负责dispatch收到的事件

selected.clear();

}

} catch (IOException ex) { /* ... */ }

}

void dispatch(SelectionKey k) {

Runnable r = (Runnable)(k.attachment()); //调用之前注册的callback对象

if (r != null)

r.run();

}

//Acceptor也是一个handler，负责创建socket并把新建的socket也注册到selector中

class Acceptor implements Runnable { // inner

public void run() {

try {

SocketChannel c = serverSocket.accept();

if (c != null)

new Handler(selector, c);

}

catch(IOException ex) { /* ... */ }

}

}

}

//Concrete Handler：用于收发和处理消息。

//在当前的实现中，使用Runnable接口作为每个具体Handler的统一接口

//如果在处理时需要参数和返回值，也可以为Handler另外声明一个统一接口来代替Runnable接口

final class Handler implements Runnable {

final SocketChannel socket;

final SelectionKey sk;

ByteBuffer input = ByteBuffer.allocate(MAXIN);

ByteBuffer output = ByteBuffer.allocate(MAXOUT);

static final int READING = 0, SENDING = 1;

int state = READING;

Handler(Selector sel, SocketChannel c) throws IOException {

socket = c; c.configureBlocking(false);

// Optionally try first read now

sk = socket.register(sel, 0);

sk.attach(this); //将Handler作为callback对象

sk.interestOps(SelectionKey.OP_READ); //第二步,接收Read事件

sel.wakeup();

}

boolean inputIsComplete() { /* ... */ }

boolean outputIsComplete() { /* ... */ }

void process() { /* ... */ }

public void run() {

try {

if (state == READING) read();

else if (state == SENDING) send();

} catch (IOException ex) { /* ... */ }

}

void read() throws IOException {

socket.read(input);

if (inputIsComplete()) {

process();

state = SENDING;

// Normally also do first write now

sk.interestOps(SelectionKey.OP_WRITE); //第三步,接收write事件

}

}

void send() throws IOException {

socket.write(output);

if (outputIsComplete()) sk.cancel(); //write完就结束了, 关闭select key

}

}

//上面 的实现用Handler来同时处理Read和Write事件, 所以里面出现状态判断

//我们可以用State-Object pattern来更优雅的实现

class Handler { // ...

public void run() { // initial state is reader

socket.read(input);

if (inputIsComplete()) {

process();

sk.attach(new Sender()); //状态迁移, Read后变成write, 用Sender作为新的callback对象

sk.interest(SelectionKey.OP_WRITE);

sk.selector().wakeup();

}

}

class Sender implements Runnable {

public void run(){ // ...

socket.write(output);

if (outputIsComplete()) sk.cancel();

}

}

}

```

- 多线程Reacotr

处理消息过程放在其他线程中执行

```java

class Handler implements Runnable {

// uses util.concurrent thread pool

static PooledExecutor pool = new PooledExecutor(...);

static final int PROCESSING = 3;

// ...

synchronized void read() { // ...

socket.read(input);

if (inputIsComplete()) {

state = PROCESSING;

pool.execute(new Processer()); //使用线程pool异步执行

}

}

synchronized void processAndHandOff() {

process();

state = SENDING; // or rebind attachment

sk.interest(SelectionKey.OP_WRITE); //process完,开始等待write事件

}

class Processer implements Runnable {

public void run() { processAndHandOff(); }

}

}

```

- 使用多个selector

mainReactor只负责处理accept并创建socket，多个subReactor负责处理读写请求

```java

Selector[] selectors; //subReactors集合, 一个selector代表一个subReactor

int next = 0;

class Acceptor { // ...

public synchronized void run() { ...

Socket connection = serverSocket.accept(); //主selector负责accept

if (connection != null)

new Handler(selectors[next], connection); //选个subReactor去负责接收到的connection

if (++next == selectors.length) next = 0;

}

}

```

#AIO

AIO是真正的异步IO，它于JDK1.7时引入，它和NIO的区别在于：

- NIO仍然需要一个线程阻塞在select方法上，AIO则不需要

- NIO得到数据准备好的消息以后，仍然需要自己把消息复制到用户空间，AIO则是通过操作系统的支持把数据异步复制到用户空间以后再给应用进程发出信号。

面试必问的epoll技术，从内核源码出发彻底搞懂epoll

epoll是linux中IO多路复用的一种机制，I/O多路复用就是通过一种机制，一个进程可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。当然linux中IO多路复用不仅仅是epoll，其他多路复用机制还有select、poll，但是接下来介绍epoll的内核实现。

events可以是以下几个宏的集合：

epoll相比select/poll的优势 ：

epoll相关的内核代码在fs/eventpoll.c文件中，下面分别分析epoll_create、epoll_ctl和epoll_wait三个函数在内核中的实现，分析所用linux内核源码为4.1.2版本。

epoll_create用于创建一个epoll的句柄，其在内核的系统实现如下：

sys_epoll_create:

可见，我们在调用epoll_create时，传入的size参数，仅仅是用来判断是否小于等于0，之后再也没有其他用处。

整个函数就3行代码，真正的工作还是放在sys_epoll_create1函数中。

sys_epoll_create - sys_epoll_create1:

sys_epoll_create1 函数流程如下：

sys_epoll_create - sys_epoll_create1 - ep_alloc:

sys_epoll_create - sys_epoll_create1 - ep_alloc - get_unused_fd_flags:

linux内核中，current是个宏，返回的是一个task_struct结构（我们称之为进程描述符）的变量，表示的是当前进程，进程打开的文件资源保存在进程描述符的files成员里面，所以current-files返回的当前进程打开的文件资源。rlimit(RLIMIT_NOFILE) 函数获取的是当前进程可以打开的最大文件描述符数，这个值可以设置，默认是1024。

相关视频推荐：

支撑亿级io的底层基石 epoll实战揭秘

网络原理tcp/udp，网络编程epoll/reactor，面试中正经“八股文”

学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂

需要更多C/C++ Linux服务器架构师学习资料加群 812855908 获取（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享

__alloc_fd的工作是为进程在[start,end)之间(备注：这里start为0， end为进程可以打开的最大文件描述符数)分配一个可用的文件描述符,这里就不继续深入下去了，代码如下：

sys_epoll_create - sys_epoll_create1 - ep_alloc - get_unused_fd_flags - __alloc_fd:

然后，epoll_create1会调用anon_inode_getfile，创建一个file结构，如下：

sys_epoll_create - sys_epoll_create1 - anon_inode_getfile:

anon_inode_getfile函数中首先会alloc一个file结构和一个dentry结构，然后将该file结构与一个匿名inode节点anon_inode_inode挂钩在一起，这里要注意的是，在调用anon_inode_getfile函数申请file结构时，传入了前面申请的eventpoll结构的ep变量，申请的file-private_data会指向这个ep变量，同时，在anon_inode_getfile函数返回来后，ep-file会指向该函数申请的file结构变量。

简要说一下file/dentry/inode，当进程打开一个文件时，内核就会为该进程分配一个file结构，表示打开的文件在进程的上下文，然后应用程序会通过一个int类型的文件描述符来访问这个结构，实际上内核的进程里面维护一个file结构的数组，而文件描述符就是相应的file结构在数组中的下标。

dentry结构（称之为“目录项”）记录着文件的各种属性，比如文件名、访问权限等，每个文件都只有一个dentry结构，然后一个进程可以多次打开一个文件，多个进程也可以打开同一个文件，这些情况，内核都会申请多个file结构，建立多个文件上下文。但是，对同一个文件来说，无论打开多少次，内核只会为该文件分配一个dentry。所以，file结构与dentry结构的关系是多对一的。

同时，每个文件除了有一个dentry目录项结构外，还有一个索引节点inode结构，里面记录文件在存储介质上的位置和分布等信息，每个文件在内核中只分配一个inode。 dentry与inode描述的目标是不同的，一个文件可能会有好几个文件名（比如链接文件），通过不同文件名访问同一个文件的权限也可能不同。dentry文件所代表的是逻辑意义上的文件，记录的是其逻辑上的属性，而inode结构所代表的是其物理意义上的文件，记录的是其物理上的属性。dentry与inode结构的关系是多对一的关系。

sys_epoll_create - sys_epoll_create1 - fd_install:

总结epoll_create函数所做的事：调用epoll_create后，在内核中分配一个eventpoll结构和代表epoll文件的file结构，并且将这两个结构关联在一块，同时，返回一个也与file结构相关联的epoll文件描述符fd。当应用程序操作epoll时，需要传入一个epoll文件描述符fd，内核根据这个fd，找到epoll的file结构，然后通过file，获取之前epoll_create申请eventpoll结构变量，epoll相关的重要信息都存储在这个结构里面。接下来，所有epoll接口函数的操作，都是在eventpoll结构变量上进行的。

所以，epoll_create的作用就是为进程在内核中建立一个从epoll文件描述符到eventpoll结构变量的通道。

epoll_ctl接口的作用是添加/修改/删除文件的监听事件，内核代码如下：

sys_epoll_ctl:

根据前面对epoll_ctl接口的介绍，op是对epoll操作的动作（添加/修改/删除事件），ep_op_has_event(op)判断是否不是删除操作，如果op != EPOLL_CTL_DEL为true，则需要调用copy_from_user函数将用户空间传过来的event事件拷贝到内核的epds变量中。因为，只有删除操作，内核不需要使用进程传入的event事件。

接着连续调用两次fdget分别获取epoll文件和被监听文件（以下称为目标文件）的file结构变量（备注：该函数返回fd结构变量，fd结构包含file结构）。

接下来就是对参数的一些检查，出现如下情况，就可以认为传入的参数有问题，直接返回出错：

当然下面还有一些关于操作动作如果是添加操作的判断，这里不做解释，比较简单，自行阅读。

在ep里面，维护着一个红黑树，每次添加注册事件时，都会申请一个epitem结构的变量表示事件的监听项，然后插入ep的红黑树里面。在epoll_ctl里面，会调用ep_find函数从ep的红黑树里面查找目标文件表示的监听项，返回的监听项可能为空。

接下来switch这块区域的代码就是整个epoll_ctl函数的核心，对op进行switch出来的有添加(EPOLL_CTL_ADD)、删除(EPOLL_CTL_DEL)和修改(EPOLL_CTL_MOD)三种情况，这里我以添加为例讲解，其他两种情况类似，知道了如何添加监听事件，其他删除和修改监听事件都可以举一反三。

为目标文件添加监控事件时，首先要保证当前ep里面还没有对该目标文件进行监听，如果存在(epi不为空)，就返回-EEXIST错误。否则说明参数正常，然后先默认设置对目标文件的POLLERR和POLLHUP监听事件，然后调用ep_insert函数，将对目标文件的监听事件插入到ep维护的红黑树里面：

sys_epoll_ctl - ep_insert:

前面说过，对目标文件的监听是由一个epitem结构的监听项变量维护的，所以在ep_insert函数里面，首先调用kmem_cache_alloc函数，从slab分配器里面分配一个epitem结构监听项，然后对该结构进行初始化，这里也没有什么好说的。我们接下来看ep_item_poll这个函数调用：

sys_epoll_ctl - ep_insert - ep_item_poll:

ep_item_poll函数里面，调用目标文件的poll函数，这个函数针对不同的目标文件而指向不同的函数，如果目标文件为套接字的话，这个poll就指向sock_poll，而如果目标文件为tcp套接字来说，这个poll就是tcp_poll函数。虽然poll指向的函数可能会不同，但是其作用都是一样的，就是获取目标文件当前产生的事件位，并且将监听项绑定到目标文件的poll钩子里面（最重要的是注册ep_ptable_queue_proc这个poll callback回调函数），这步操作完成后，以后目标文件产生事件就会调用ep_ptable_queue_proc回调函数。

接下来，调用list_add_tail_rcu将当前监听项添加到目标文件的f_ep_links链表里面，该链表是目标文件的epoll钩子链表，所有对该目标文件进行监听的监听项都会加入到该链表里面。

然后就是调用ep_rbtree_insert，将epi监听项添加到ep维护的红黑树里面,这里不做解释，代码如下：

sys_epoll_ctl - ep_insert - ep_rbtree_insert:

前面提到，ep_insert有调用ep_item_poll去获取目标文件产生的事件位，在调用epoll_ctl前这段时间，可能会产生相关进程需要监听的事件，如果有监听的事件产生，(revents event-events 为 true)，并且目标文件相关的监听项没有链接到ep的准备链表rdlist里面的话，就将该监听项添加到ep的rdlist准备链表里面，rdlist链接的是该epoll描述符监听的所有已经就绪的目标文件的监听项。并且，如果有任务在等待产生事件时，就调用wake_up_locked函数唤醒所有正在等待的任务，处理相应的事件。当进程调用epoll_wait时，该进程就出现在ep的wq等待队列里面。接下来讲解epoll_wait函数。

总结epoll_ctl函数：该函数根据监听的事件，为目标文件申请一个监听项，并将该监听项挂人到eventpoll结构的红黑树里面。

epoll_wait等待事件的产生，内核代码如下：

sys_epoll_wait:

首先是对进程传进来的一些参数的检查：

参数全部检查合格后，接下来就调用ep_poll函数进行真正的处理：

sys_epoll_wait - ep_poll:

ep_poll中首先是对等待时间的处理，timeout超时时间以ms为单位，timeout大于0，说明等待timeout时间后超时，如果timeout等于0，函数不阻塞，直接返回，小于0的情况，是永久阻塞，直到有事件产生才返回。

当没有事件产生时（(!ep_events_available(ep))为true）,调用__add_wait_queue_exclusive函数将当前进程加入到ep-wq等待队列里面，然后在一个无限for循环里面，首先调用set_current_state(TASK_INTERRUPTIBLE)，将当前进程设置为可中断的睡眠状态，然后当前进程就让出cpu，进入睡眠，直到有其他进程调用wake_up或者有中断信号进来唤醒本进程，它才会去执行接下来的代码。

如果进程被唤醒后，首先检查是否有事件产生，或者是否出现超时还是被其他信号唤醒的。如果出现这些情况，就跳出循环，将当前进程从ep-wp的等待队列里面移除，并且将当前进程设置为TASK_RUNNING就绪状态。

如果真的有事件产生，就调用ep_send_events函数，将events事件转移到用户空间里面。

sys_epoll_wait - ep_poll - ep_send_events:

ep_send_events没有什么工作，真正的工作是在ep_scan_ready_list函数里面：

sys_epoll_wait - ep_poll - ep_send_events - ep_scan_ready_list:

ep_scan_ready_list首先将ep就绪链表里面的数据链接到一个全局的txlist里面，然后清空ep的就绪链表，同时还将ep的ovflist链表设置为NULL，ovflist是用单链表，是一个接受就绪事件的备份链表，当内核进程将事件从内核拷贝到用户空间时，这段时间目标文件可能会产生新的事件，这个时候，就需要将新的时间链入到ovlist里面。

仅接着，调用sproc回调函数(这里将调用ep_send_events_proc函数)将事件数据从内核拷贝到用户空间。

sys_epoll_wait - ep_poll - ep_send_events - ep_scan_ready_list - ep_send_events_proc:

ep_send_events_proc回调函数循环获取监听项的事件数据，对每个监听项，调用ep_item_poll获取监听到的目标文件的事件，如果获取到事件，就调用__put_user函数将数据拷贝到用户空间。

回到ep_scan_ready_list函数，上面说到，在sproc回调函数执行期间，目标文件可能会产生新的事件链入ovlist链表里面，所以，在回调结束后，需要重新将ovlist链表里面的事件添加到rdllist就绪事件链表里面。

同时在最后，如果rdlist不为空（表示是否有就绪事件），并且由进程等待该事件，就调用wake_up_locked再一次唤醒内核进程处理事件的到达（流程跟前面一样，也就是将事件拷贝到用户空间）。

到这，epoll_wait的流程是结束了，但是有一个问题，就是前面提到的进程调用epoll_wait后会睡眠，但是这个进程什么时候被唤醒呢？在调用epoll_ctl为目标文件注册监听项时，对目标文件的监听项注册一个ep_ptable_queue_proc回调函数，ep_ptable_queue_proc回调函数将进程添加到目标文件的wakeup链表里面，并且注册ep_poll_callbak回调，当目标文件产生事件时，ep_poll_callbak回调就去唤醒等待队列里面的进程。

总结一下epoll该函数： epoll_wait函数会使调用它的进程进入睡眠（timeout为0时除外），如果有监听的事件产生，该进程就被唤醒，同时将事件从内核里面拷贝到用户空间返回给该进程。

高性能网络服务器编程：为什么linux下epoll

基本的IO编程过程（包括网络IO和文件IO）是，打开文件描述符（windows是handler，Java是stream或channel），多路捕获（Multiplexe，即select和poll和epoll）IO可读写的状态，而后可以读写的文件描述符进行IO读写，由于IO设备速度和CPU内存比速度会慢，为了更好的利用CPU和内存，会开多线程，每个线程读写一个文件描述符。

但C10K问题，让我们意识到在超大数量的网络连接下，机器设备和网络速度不再是瓶颈，瓶颈在于操作系统和IO应用程序的沟通协作的方式。

举个例子，一万个socket连接过来，传统的IO编程模型要开万个线程来应对，还要注意，socket会关闭打开，一万个线程要不断的关闭线程重建线程，资源都浪费在这上面了，我们算建立一个线程耗1M内存，1万个线程机器至少要10G内存，这在IA-32的机器架构下基本是不可能的（要开PAE），现在x64架构才有可能舒服点，要知道，这仅仅是粗略算的内存消耗。别的资源呢？

所以，高性能的网络编程（即IO编程），第一，需要松绑IO连接和应用程序线程的对应关系，这就是非阻塞（nonblocking）、异步（asynchronous）的要求的由来（构造一个线程池，epoll监控到有数的fd，把fd传入线程池，由这些worker thread来读写io）。第二，需要高性能的OS对IO设备可读写（数据来了）的通知方式：从level-triggered notification到edge-triggered notification，关于这个通知方式，我们稍后谈。

需要注意异步，不等于AIO（asynchronous IO），Linux的AIO和java的AIO都是实现异步的一种方式，都是渣，这个我们也接下来会谈到。

针对前面说的这两点，我们看看select和poll的问题

这两个函数都在每次调用的时候要求我们把需要监控（看看有没有数据）的文件描述符，通过数组传递进入内核，内核每次都要扫描这些文件描述符，去理解它们，建立一个文件描述符和IO对应的数组（实际内核工作会有好点的实现方式，但可以这么理解先），以便IO来的时候，通知这些文件描述符，进而通知到进程里等待的这些select、poll。当有一万个文件描述符要监控的时候呢（一万个网络连接）？这个工作效率是很低的，资源要求却很高。

我们看epoll

epoll很巧妙，分为三个函数，第一个函数创建一个session类似的东西，第二函数告诉内核维持这个session，并把属于session内的fd传给内核，第三个函数epoll_wait是真正的监控多个文件描述符函数，只需要告诉内核，我在等待哪个session，而session内的fd，内核早就分析过了，不再在每次epoll调用的时候分析，这就节省了内核大部分工作。这样每次调用epoll，内核不再重新扫描fd数组，因为我们维持了session。

说道这里，只有一个字，开源，赞，众人拾柴火焰高，赞。

epoll的效率还不仅仅体现在这里，在内核通知方式上，也改进了，我们先看select和poll的通知方式，也就是level-triggered notification，内核在被DMA中断，捕获到IO设备来数据后，本来只需要查找这个数据属于哪个文件描述符，进而通知线程里等待的函数即可，但是，select和poll要求内核在通知阶段还要继续再扫描一次刚才所建立的内核fd和io对应的那个数组，因为应用程序可能没有真正去读上次通知有数据后的那些fd，应用程序上次没读，内核在这次select和poll调用的时候就得继续通知，这个os和应用程序的沟通方式效率是低下的。只是方便编程而已（可以不去读那个网络io，方正下次会继续通知）。

于是epoll设计了另外一种通知方式：edge-triggered notification，在这个模式下，io设备来了数据，就只通知这些io设备对应的fd，上次通知过的fd不再通知，内核不再扫描一大堆fd了。

基于以上分析，我们可以看到epoll是专门针对大网络并发连接下的os和应用沟通协作上的一个设计，在linux下编网络服务器，必然要采用这个，nginx、PHP的国产异步框架swool、varnish，都是采用这个。

注意还要打开epoll的edge-triggered notification。而java的NIO和NIO.2都只是用了epoll，没有打开edge-triggered notification，所以不如JBoss的Netty。

接下来我们谈谈AIO的问题，AIO希望的是，你select，poll，epoll都需要用一个函数去监控一大堆fd，那么我AIO不需要了，你把fd告诉内核，你应用程序无需等待，内核会通过信号等软中断告诉应用程序，数据来了，你直接读了，所以，用了AIO可以废弃select，poll，epoll。

但linux的AIO的实现方式是内核和应用共享一片内存区域，应用通过检测这个内存区域（避免调用nonblocking的read、write函数来测试是否来数据，因为即便调用nonblocking的read和write由于进程要切换用户态和内核态，仍旧效率不高）来得知fd是否有数据，可是检测内存区域毕竟不是实时的，你需要在线程里构造一个监控内存的循环，设置sleep，总的效率不如epoll这样的实时通知。所以，AIO是渣，适合低并发的IO操作。所以java7引入的NIO.2引入的AIO对高并发的网络IO设计程序来说，也是渣，只有Netty的epoll+edge-triggered notification最牛，能在linux让应用和OS取得最高效率的沟通。