poll

介绍 在谈及网络IO的时候总避不开阻塞、非阻塞、同步、异步、IO多路复用、select、poll、epoll等这几个词语。在面试的时候也会被经常问到这几个的区别。本文就来讲一下这几个词语的含义、区别以及使用方式。 Unix网络编程一书中作者给出了五种IO模型： 1、BlockingIO - 阻塞IO 2、NoneBlockingIO - 非阻塞IO 3、IO multiplexing - IO多路复用 4、signal driven IO - 信号驱动IO 5、asynchronous IO - 异步IO 这五种IO模型中前四个都是同步的IO，只有最后一个是异步IO。信号驱动IO使用的比较少，重点介绍其他几种IO以及在Java中的应用。 阻塞、非阻塞、同步、异步以及IO多路复用 在进行网络IO的时候会涉及到用户态和内核态，并且在用户态和内核态之间会发生数据交换，从这个角度来说我们可以把IO抽象成两个阶段：1、用户态等待内核态数据准备好，2、将数据从内核态拷贝到用户态。之所以会有同步、异步、阻塞和非阻塞这几种说法就是根据程序在这两个阶段的处理方式不同而产生的。 同步阻塞 当在用户态调用read操作的时候，如果这时候kernel还没有准备好数据，那么用户态会一直阻塞等待，直到有数据返回。当kernel准备好数据之后，用户态继续等待kernel把数据从内核态拷贝到用户态之后才可以使用

概述 Healthd是android4.4之后提出来的一种中介模型，该模型向下监听来自底层的电池事件，向上传递电池数据信息给Framework层的BatteryService用以计算电池电量相关状态信息，BatteryServcie通过传递来的数据来计算电池电量显示，剩余电量，电量级别等信息，如果收到过温报警或者严重低电报警等信息，系统会直接关机，保护硬件。 主模块处理流程 Healthd模块代码是在system/core/healthd/，其模块入口在healthd的main函数，函数代码如下： int main(int argc, char **argv) { int ch; int ret; klog_set_level(KLOG_LEVEL); healthd_mode_ops = &android_ops; if (!strcmp(basename(argv[0]), "charger")) { healthd_mode_ops = &charger_ops; } else { while ((ch = getopt(argc, argv, "cr")) != -1) { switch (ch) { case 'c': healthd_mode_ops = &charger_ops; break; case 'r': healthd_mode_ops =

本篇文章在上一篇的基础上，使用 epoll 实现了一个事件监听和回调处理的模块。如何编写一个使用该模块的例子呢？ 监测什么类型的fd，监测什么类型的事件，监测到事件以后需要做什么？后来可以看看如何将该模块与socket ， 回调函数， 线程池联系起来。 #include<sys/epoll.h> // epoll_create, epoll_ctl, epoll_wait #include <mutex> // std::mutex #include <functional> // std::function #include <iostream> #include <memory> // std::unique_ptr #include <unistd.h> // close class Epoll{ public: class ActiveEvents { public: ActiveEvents( int num, const struct epoll_event* events): num_( num ), events_( events ) { } int num() const { return num_; } const struct epoll_event* events() const { return events_; } private: int num_;

背景 在文章 《unix网络编程》（12）五种I/O模型 中提到了五种I/O模型，其中前四种：阻塞模型、非阻塞模型、信号驱动模型、I/O复用模型都是同步模型；还有一种是异步模型。 想写一个系列的文章，介绍从I/O多路复用到异步编程和RPC框架，整个演进过程，这一系列可能包括： I/O多路复用模型 epoll介绍与使用 Reactor和Proactor模型 为什么需要异步编程 enable_shared_from_this用法分析 网络通信库和RPC 为什么有多路复用？ 多路复用技术要解决的是“通信”问题，解决核心在于“同步事件分离器”（de-multiplexer），linux系统带有的分离器select、poll、epoll网上介绍的比较多，大家可以看看这篇介绍的不错的文章： 我读过的最好的epoll讲解 。通信的一方想要知道另一方的状态(以决定自己做什么)，有两种方法: 一是轮询，二是消息通知。 轮询 轮询的一种典型的实现可能是这样的：当然这里的epoll_wait()也可以使用poll()或者select()替换。 while （true） { active_stream[] = epoll_wait(epollfd) for i in active_stream[] { read or write till } } 轮询方式主要存在以下不足： 增加系统开销

原文链接: https://www.cnblogs.com/zingp/p/6863170.html https://www.cnblogs.com/guxuanqing/p/10482066.html 　　网络编程里常听到阻塞IO、非阻塞IO、同步IO、异步IO等概念，总听别人装13不如自己下来钻研一下。不过，搞清楚这些概念之前，还得先回顾一些基础的概念。 回到顶部 1 基础知识回顾 注意： 咱们下面说的都是 Linux环境 下，跟Windows不一样哈~~~ 1.1 用户空间和内核空间 　　现在操作系统都采用虚拟寻址， 处理器先产生一个虚拟地址 ，通过 地址翻译成物理地址（内存的地址） ，再通过总线的传递，最后处理器拿到某个物理地址返回的字节。 　　对32位操作系统而言，它的寻址空间（虚拟存储空间）为4G（2的32次方）。操作系统的核心是内核，独立于普通的应用程序，可以访问受保护的内存空间，也有访问底层硬件设备的所有权限。为了保证用户进程不能直接操作内核（kernel），保证内核的安全，操心系统将虚拟空间划分为两部分，一部分为内核空间，一部分为用户空间。针对linux操作系统而言，将最高的1G字节（从虚拟地址0xC0000000到0xFFFFFFFF），供内核使用，称为内核空间，而将较低的3G字节（从虚拟地址0x00000000到0xBFFFFFFF），供各个进程使用

Kafka消费者端 可靠性保证 作为消费端，消费数据需要考虑的是： 1、不重复消费消息 2、不缺失消费消息 分区分配策略 一个 consumer group 中有多个 consumer，一个 topic 有多个 partition，所以必然会涉及到 partition 的分配问题，即确定那个 partition 由哪个 consumer 来消费。 Kafka 有两种分配策略，一是 RoundRobin（轮询调度算法(Round-Robin Scheduling)），一是 Range。 https://blog.csdn.net/u013256816/article/details/81123600 朱小厮的博客（《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》作者） offset 消费者端的可靠性需要依靠offect来进行保证，这里的offset不是broker的offect，而是consumer的消费位移偏移量，它在broker中被维护。由于 consumer 在消费过程中可能会出现断电宕机等故障， consumer 恢复后，需要从故 障前的位置的继续消费，所以 consumer 需要实时记录自己消费到了哪个 offset，以便故障恢复后继续消费。 Kafka 0.9 版本之前， consumer 默认将 offset 保存在 Zookeeper 中，从

大家应该都知道，Android 的消息机制是基于 Handler 实现的。还记得一年前的自己就看了几篇博客，知道了 Handler、Looper、MessageQueue 就自以为了解了 Handler 的原理。但其实看源码的过程中慢慢就会发现，Handler 的内容可不止这点， 像同步屏障、 Handler 的 native 层的阻塞唤醒机制等等这些知识以前就没有理解清楚。因此写下这篇文章，从头开始重塑对 Handler 的印象。 觉得文章太长的可以找我拿了完整的PDF自行研究 参考： (更多完整项目下载。未完待续。源码。图文知识后续上传github。) 可以点击 关于我 联系我获取完整PDF ( VX：mm14525201314 ) Handler 采用的是一种生产者-消费者模型，Handler 就是生产者，通过它可以生产需要执行的任务。而 Looper 则是消费者，不断从 MessageQueue 中取出 Message 对这些消息进行消费，下面我们看一下其具体的实现。 发送消息 post & sendMessage 首先我们都知道，Handler 对外主要有两种方式来实现在其所在 Looper 所在线程执行指定 Runnable ——post 及 sendMessage ，它们都有对应的 delay 方法 。而不论是 post 还是 sendMessage ，都会调用到

poll 机制的作用：使阻塞型函数超时返回，避免一直阻塞。 实例： driver.c 1 #include <linux/module.h> 2 #include <linux/kernel.h> 3 #include <linux/fs.h> 4 #include <linux/init.h> 5 #include <linux/delay.h> 6 #include <linux/irq.h> 7 #include <asm/uaccess.h> 8 #include <asm/irq.h> 9 #include <asm/io.h> 10 #include <asm/arch/regs-gpio.h> 11 #include <asm/hardware.h> 12 #include <linux/poll.h> 13 14 15 static int major; 16 17 static struct class * myKey_class ; 18 static struct class_device * myKey_class_dev; 19 20 volatile unsigned long * gpfcon; 21 volatile unsigned long * gpfdat; 22 23 volatile unsigned long * gpgcon; 24

编者注：Netty是Java领域有名的开源网络库，特点是高性能和高扩展性，因此很多流行的框架都是基于它来构建的，比如我们熟知的Dubbo、Rocketmq、Hadoop等。本文就netty线程模型展开分析讨论下 : ) IO模型 BIO：同步阻塞IO模型； NIO：基于IO多路复用技术的“非阻塞同步”IO模型。简单来说，内核将可读可写事件通知应用，由应用主动发起读写操作； AIO：非阻塞异步IO模型。简单来说，内核将读完成事件通知应用，读操作由内核完成，应用只需操作数据即可；应用做异步写操作时立即返回，内核会进行写操作排队并执行写操作。 NIO和AIO不同之处在于应用是否进行真正的读写操作。 reactor和proactor模型 reactor：基于NIO技术，可读可写时通知应用； proactor：基于AIO技术，读完成时通知应用，写操作应用通知内核。 netty线程模型 netty的线程模型是基于Reactor模型的。 netty单线程模型 Reactor 单线程模型，是指所有的 I/O 操作都在同一个 NIO 线程上面完成的，此时NIO线程职责包括：接收新建连接请求、读写操作等。 在一些小容量应用场景下，可以使用单线程模型（ 注意，Redis的请求处理也是单线程模型，为什么Redis的性能会如此之高呢？因为Redis的读写操作基本都是内存操作，并且Redis协议比较简洁

1 nginx配置优化提高并发量 worker_processes 2; 这个按照CPU的核数来决定 2 worker_connections 65535; 这个一般设置65535即可 每个进程允许的最多连接数， 理论上每台nginx 服务器的最大连接数为worker_processes*worker_connections。 3 keepalive_timeout 60; keepalive 设置超时时间 一般设置60 4. use epoll; 使用epoll 的I/O 模型 来源： https://www.cnblogs.com/newmiracle/p/11871487.html