epoll

水平触发LT和边沿触发ET 内核中有一个与socket关联的读写缓冲区。 水平触发的意思是只要缓冲区不为空就触发可读事件，只要缓冲区不满就触发可写事件。 而边缘触发的意思是当缓冲区从满到不满的时间点触发一次可写事件，当缓冲区从空到非空的时间点触发一次可读事件。 水平触发只要缓冲区不空就持续触发可读事件，只要缓冲组不满就持续触发可写事件。 而边缘触发只在缓冲区从满到不满的时间点触发一次可写事件，后续不会再次触发可写事件，只在缓冲区从空到不空的时间点触发一次可读事件，后续不会再次触发可读事件。 所谓的边缘就是状态发生改变的点，从空到不空（可读），从满到不满（可写）。只在状态发生改变的时候触发一次的触发方式叫边缘触发，只要可读或者可写，就持续发送可读或者可写事件的触发模式叫水平触发。 水平触发可读， 水平触发可写， 边沿触发可读， 边沿触发可写， 阻塞模式和非阻塞 socket分为监听socket和连接socket。 阻塞和非阻塞主要是针对连接socket的读写来说的。即阻塞读写还是非阻塞读写。 监听socket阻塞和非阻塞效果都一样，水平触发和边缘触发效果也一样，数据固定，一次读取完毕。 连接socket如果是阻塞的模式，无数据可读或者无空间可写的情况下，都会阻塞当前的连接socket。 连接socket如果是非阻塞模式的，无论有没有数据可读，也无论有没有空间可写

文末提供本文学习资源获取方式，需要请自取。 文章是由我笔试面试腾讯笔记整理而来，主要是针对面试的C++后台开发岗位，涵盖了大部分C++后台开发相关可能会考察和被问到的技术点。 自认为这篇笔记比较全面的总结，不管你是已经工作准备参加社招，还是在校学生准备参加校招，笔记都可以作为技术面试准备阶段参考查阅，查缺补漏。 这篇笔记是基础C++知识点总结，没有过多的阐述后台开发的系统架构和分布式后台服务设计相关，还有c++11新特性，这些笔试面试也会被问到但不在这篇讨论范围，可以关注我后面有时间再补上。 阅读提示 文章约12839字，阅读时长预计33分钟。建议关注收藏方便回头查阅。 gdb调试命令 step和next的区别？ 当前line有函数调用的时候,next会直接执行到下一句 ,step会进入函数. 查看内存 (gdb)p &a //打印变量地址 (gdb)x 0xbffff543 //查看内存单元内变量 0xbffff543: 0x12345678 (gdb) x /4xb 0xbffff543 //单字节查看4个内存单元变量的值 0xbffff543: 0x78 0x56 0x34 0x12 多线程调试 (gdb) info threads：查看GDB当前调试的程序的各个线程的相关信息 (gdb) thread threadno：切换当前线程到由threadno指定的线程 break

点击上方蓝色“ 后端面试那些事儿 ”，选择“设为星标” 学最好的别人，做最好的我们 来源：draveness.me/redis-io-multiplexing 几种 I/O 模型 Blocking I/O I/O 多路复用 Reactor 设计模式 I/O 多路复用模块 封装 select 函数 封装 epoll 函数 子模块的选择 总结 最近在看 UNIX 网络编程并研究了一下 Redis 的实现，感觉 Redis 的源代码十分适合阅读和分析，其中 I/O 多路复用（mutiplexing）部分的实现非常干净和优雅，在这里想对这部分的内容进行简单的整理。 几种 I/O 模型 为什么 Redis 中要使用 I/O 多路复用这种技术呢？ 首先，Redis 是跑在单线程中的，所有的操作都是按照顺序线性执行的，但是由于读写操作等待用户输入或输出都是阻塞的，所以 I/O 操作在一般情况下往往不能直接返回，这会导致某一文件的 I/O 阻塞导致整个进程无法对其它客户提供服务，而 I/O 多路复用 就是为了解决这个问题而出现的。 Blocking I/O 先来看一下传统的阻塞 I/O 模型到底是如何工作的：当使用 read 或者 write 对某一个**文件描述符（File Descriptor 以下简称 FD)**进行读写时，如果当前 FD 不可读或不可写，整个 Redis

一面（普通技术面） 过程：递交简历 -> 手撕代码 -> 开始面试 -> 结束 耗时：about 1 hour 手撕代码： 一颗二叉搜索树，找出树中的第k大节点 拿到题目之后没有任何思考，想用中序遍历然后把遍历结果放到一个容量为k的队列中（基本操作）。但是为什么顺手就写下vector？？？面试官看见我这么快下笔之后看了看我写的东西，然后提醒说不能转存。思考了不到30秒，有点慌，然后迅速冷静下来。第二个思路：利用递归中序遍历把二叉搜索树转成一个双向链表，然后遍历链表k步找到第k大节点或者返回NULL表示k无效。中途写的时候，面试官看了看我写的代码，然后问我思路，然后给他介绍了一遍。快写完的时候，他说其实我只是想考考你中序遍历，我说不能转存但是还是可以用栈的...（那我用队列有错吗...） 开始面试： 1. fork过程 Q：介绍一下fork的流程 A：从源码来看，fork就是简单的把父进程的几乎所有东西都拷贝一份，比如会复制父进程的地址空间、已打开文件描述符、命名空间啊这些之类的…然后修改一些标志让自己与父进程变得不一样 Q：栈和堆会拷贝吗 A：emmm…会 Q：在复制之前会做些什么呢 A：emmm…（思考半天，没做什么呀…） Q：表示进程的那个结构体呢，会复制吗 A：task_struct吗？对对对，在这之前会先从slab中分配一个PCB… 2. FIXME：copy-on

Nginx Nginx (engine x) 是一个高性能的HTTP和反向代理web服务器，同时也提供了IMAP/POP3/SMTP服务。 Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协议下发行。 其特点是占有内存少，并发能力强。在高连接并发的情况下，Nginx是Apache服务器不错的替代品。 安装 Nginx 使用 Unix 下常用的 './configure && make && make install' 过程来编译安装。 在不同版本间，选项可能会有些许变化，请总是使用 ./configure --help 命令来检查一下当前的选项列表。 1.安装编译工具及库文件 因nginx是由C编写的，所以要经过gcc编译之前要安装一些相应的库。 安装gcc环境 # yum install -y gcc-c++ nginx的http模块使用pcre来解析正则表达式，所以要安装pcre库。 # yum install -y pcre pcre-devel nginx使用zlib对http包的内容进行gzip，所以要安装zlib库。 # yum install -y zlib zlib-devel OpenSSL 是一个强大的安全套接字层密码库，囊括主要的密码算法、常用的密钥和证书封装管理功能及SSL协议

Linux系统IO模型总结Nginx编译安装与基础配置 一、Linux系统IO模型 1、IO的概念 Linux世界里一切皆文件，socket、管道、终端等都是文件。Linux系统中的文件也可以理解成一串二进制流。在信息交换的过程中，收发这些二进制流的操作就是I/O操作(input and output)，其中最为常见的就是磁盘IO和网络IO。 2、内核空间与用户空间 Linux系统将内存空间分为内核空间与用户空间两部分。内核空间中存放的是内核代码和数据，可以执行特权指令，对外提供服务接口，例如访问硬件。用户空间中存放的是用户程序的代码和数据，只能执行非特权指令。 所有的系统资源管理都在内核空间中完成，比如读写磁盘文件，从网络接口读写数据等等。用户的应用程序是无法直接进行这样的操作的，只能通过内核提供的接口来完成这样的任务。 4、系统IO模型 以用户程序读取数据为例理解系统IO模型。由于用户没有权限直接访问磁盘设备，只能通过内核来实现。当内核从磁盘读取到用户所需的数据后，受内核空间与用户空间严格隔离的限制，需要将内核空间中的内存数据copy到用户空间的进程内存当中。所以简单来说，一次I/O就是内核从磁盘中将数据读取到内核空间，然后再将内核空间中的内存数据复制到用户空间中进程的内存当中的整个过程。系统IO有四种模型：同步、异步、阻塞、非阻塞。 同步/异步 关注的是事件处理的消息通信机制

前言 在java的网络编程世界里，Netty的地位可谓是举足轻重，说到基于NIO的网络编程，Netty几乎成为企业的首选，本文不会过多介绍Netty的基本使用等知识，本文着重介绍在Netty中如何实现同一个端口，既能接收TCP请求，也能接收Http请求。 由于一些特殊的原因，我要实现一款消息中间件，暂时称为“企业消息总线”吧。简单描述一下场景，对如果有相同或者类似场景的小伙伴可能有帮助。在企业内部，特别是制造业企业，往往会存在生产管理系统和生产控制系统。管理类系统我们都很熟悉了，但是控制类系统更多的是控制，比如控制机器的运行，接收机器的传感器传递上来的数据，然而管理系统如果要收集生产现场的数据，一般都是通过控制系统上传到管理系统，如果管理系统想要控制机器，则需要下发一些数据到控制系统，因此就存在一个管理系统到控制系统之间的通讯需求。一般的控制系统和管理系统之间都是使用TCP进行通讯，当然现在也有支持使用HTTP直接通信的，具体可以参考如下简图 今天只讨论使用TCP进行通讯的模式 需求提出 上面简单介绍了管理系统和控制系统之间的通讯模式，我们都知道，在网络编程里面，比较关注的两点就是 通讯协议 和 序列化协议 。通讯协议一般就是指传输层协议TCP/UDP或者应用层协议HTTP等协议。而序列化的就多了，常见的有protocol buffer，json或者自定义的某协议。

一周至少一篇到今天已经持续 30 周了，希望每一篇多多少少能给大家带来点干货。同样的，今天分享的基本上一面试就会被问的网络IO。文中涉及的代码部分不太重要，重要的是对这概念的理解。在看文章之前大家也可通过下面的思维导图看看自己是否能回答出来。 大纲 1 阻塞与非阻塞--开胃菜 阻塞 我们知道在调用某个函数的时候无非就是两种情况，要么 马上返回 ，然后根据返回值进行接下来的业务处理。当在使用 阻塞IO 的时候，应用程序会被无情的 挂起 ，等待内核完成操作，因为此时的内核可能将CPU时间切换到了其他需要的进程中，在我们的应用程序看来感觉被卡主(阻塞)了。 阻塞IO 传统阻塞IO模型 传统阻塞IO模型 特点： 通过阻塞式IO获取输入的数据 其中每个连接都采用独立的线程完成数据输入，业务处理以及数据返回的操作 这种方案有什么问题？ 首先当并发较大的时候，需要创建大量的线程来处理连接，需要占用大量的系统资源。 连接建立完成以后，如果当前线程没有数据可读，将会阻塞在read操作上造成线程资源的浪费 鉴于上面的两个问题，通常是解决方案是啥呢？ 第一种是 采用IO复用的模型 ，所谓IO复用模型即多个连接共享一个阻塞对象，应用程序只会在一个阻塞对象上等待。当某个连接有新的数据处理，操作系统直接 通知 应用程序，线程从阻塞状态返回并开始业务处理 第二种方案即采用 线程池复用的方式

匠心零度 转载请注明原创出处，谢谢！ 疑惑 我们都知道bio nio 以及nio2(也就是aio)，如果不是特别熟悉可以看看我之前写的 网络 I/O模型 ，那么netty为什么还经常看到类似下面的这段代码呢？ EventLoopGroup ……= new NioEventLoopGroup(); …… …… b.group(……).channel(NioSocketChannel.class)…… …… …… ChannelFuture f = b.bind(PORT).sync(); 不选择bio模型我们知道，那么为什么不选择aio模式呢？而还是选择nio模式呢？这是一个值得思考的问题，我就一直很好奇，因为在 网络 I/O模型 里面介绍的，明显AIO要比NIO模型还要好。 那么为什么Netty还是选择的NIO模型呢？ Netty一些组件简单介绍 Netty中这样定义EventLoop的，本篇重点不在这里，后续继续介绍EventLoop。 Will handle all the I/O operations for a [ Channel ] once registered. One [ EventLoop ] instance will usually handle more than one [ Channel ] but this may depend on

今天分享的基本上一面试就会被问的网络IO，文中涉及的代码部分不太重要，重要的是对这概念的理解。在看文章之前大家也可通过下面的思维导图看看自己是否能回答出来。 大纲 1 阻塞与非阻塞--开胃菜 阻塞 我们知道在调用某个函数的时候无非就是两种情况，要么 马上返回 ，然后根据返回值进行接下来的业务处理。当在使用 阻塞IO 的时候，应用程序会被无情的 挂起 ，等待内核完成操作，因为此时的内核可能将CPU时间切换到了其他需要的进程中，在我们的应用程序看来感觉被卡主(阻塞)了。 阻塞IO 传统阻塞IO模型 传统阻塞IO模型 特点： 通过阻塞式IO获取输入的数据 其中每个连接都采用独立的线程完成数据输入，业务处理以及数据返回的操作 这种方案有什么问题？ 首先当并发较大的时候，需要创建大量的线程来处理连接，需要占用大量的系统资源。 连接建立完成以后，如果当前线程没有数据可读，将会阻塞在read操作上造成线程资源的浪费 鉴于上面的两个问题，通常是解决方案是啥呢？ 第一种是 采用IO复用的模型 ，所谓IO复用模型即多个连接共享一个阻塞对象，应用程序只会在一个阻塞对象上等待。当某个连接有新的数据处理，操作系统直接 通知 应用程序，线程从阻塞状态返回并开始业务处理 第二种方案即采用 线程池复用的方式 。将连接完成后的业务处理任务分配给线程，一个线程处理多个连接的业务