epoll

在深入理解select、poll和epoll之间的区别之前，首先要了解什么是IO多路复用模型。 IO多路复用 简单来说，IO多路复用是指内核一旦发现进程指定的一个或者多个IO条件准备就绪，它就通知该进程去进行IO操作。 详细的描述可以参考 IO模型 。select、poll和epoll都是提供I/O多路复用的解决方案。 select 函数 int select(int maxfdp, fd_set *readset, fd_set *writeset, fd_set *exceptset, struct timeval *timeout); 基本原理 ：select 函数监视的文件描述符分3类，分别是 writefds 、 readfds 、和 exceptfds 。调用select时会被阻塞，直到有fd就绪（读、写、或者异常），或者超时（ timeout 指定等待时间，如果立即返回设为 null 即可）函数返回一个大于 0 的值，然后通过遍历文件描述符集合 fd_set ，来找到就绪的描述符 说明 ： maxfdp 是一个整数值，是指集合中所有文件描述符的范围，即所有文件描述符的最大值加1。 fd_set 是以位图的形式来存储这些文件描述符。 maxfdp 也就是定义了位图中有效地位的个数 时间复杂度 ： O(n) ， n 为文件描述符集合 fd_set 的大小

简介： 本文主要讲述Netty框架的一些特性以及重要组件，希望看完之后能对Netty框架有一个比较直观的感受，希望能帮助读者快速入门Netty，减少一些弯路。 思维导图 前言 本文主要讲述Netty框架的一些特性以及重要组件，希望看完之后能对Netty框架有一个比较直观的感受，希望能帮助读者快速入门Netty，减少一些弯路。 一、Netty概述 官方的介绍： Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. Netty 是 一个 异步事件驱动 的网络应用程序框架，用于 快速开发可维护的高性能协议服务器和客户端 。 二、为什么使用Netty 从官网上介绍，Netty是一个网络应用程序框架，开发服务器和客户端。也就是用于网络编程的一个框架。既然是网络编程，Socket就不谈了，为什么不用NIO呢？ 2.1 NIO的缺点 对于这个问题，之前我写了一篇文章 《NIO入门》 对NIO有比较详细的介绍，NIO的主要问题是： NIO的类库和API繁杂，学习成本高，你需要熟练掌握Selector、ServerSocketChannel

jconsole远程连接须配置JMX /data/noob/jdk1.8.0_151/bin/java -Djava.rmi.server.hostname=127.0.0.1 #远程服务器ip，即本机ip - Dcom.sun.management.jmxremote #允许JMX远程调用 -Dcom.sun.management.jmxremote.port=7018 #自定义jmx 端口号 -Dcom.sun.management.jmxremote.rmi.port=7019 # JMX在远程连接时，会随机开启一个RMI端口作为连接的数据端口，很有可能这个端口会被防火墙给阻止，以至于连接超时失败​​​​​​。可以将这个端口和jmx.port的端口设置成一个端口，这样防火墙策略就只需要同行一个端口就可以了 -Dcom.sun.management.jmxremote.authenticate=false #是否需要秘钥 -Dcom.sun.management.jmxremote.ssl=false # 是否需要ssl 安全连接方式 -jar ./bussiness-0.0.1-SNAPSHOT.jar -Xms2048m -Xmx2048m -Xmn1024g -Xss2m -XX:NewRatio=4 -XX:SurvivorRatio=4 -XX

【翻译】.NET 5中的性能改进 在.NET Core之前的版本中，其实已经在博客中介绍了在该版本中发现的重大性能改进。 从.NET Core 2.0到.NET Core 2.1到.NET Core 3.0的每一篇文章，发现 谈论越来越多的东西。 然而有趣的是，每次都想知道下一次是否有足够的意义的改进以保证再发表一篇文章。 .NET 5已经实现了许多性能改进，尽管直到今年秋天才计划发布最终版本，并且到那时很有可能会有更多的改进，但是还要强调一下，现在已提供的改进。 在这篇文章中，重点介绍约250个PR，这些请求为整个.NET 5的性能提升做出了巨大贡献。 安装 Benchmark.NET现在是衡量.NET代码性能的规范工具，可轻松分析代码段的吞吐量和分配。 因此，本文中大部分示例都是使用使用该工具编写的微基准来衡量的。首先创建了一个目录，然后使用dotnet工具对其进行了扩展： mkdir Benchmarks cd Benchmarks dotnet new console 生成的Benchmarks.csproj的内容扩展为如下所示： <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <AllowUnsafeBlocks>true</AllowUnsafeBlocks>

之前曾经使用 epoll 构建过一个轻量级的 tcp 服务框架： 一个工业级、跨平台、轻量级的 tcp 网络服务框架：gevent 在调试的过程中，发现一些 epoll 之前没怎么注意到的特性。 a) iocp 是完全线程安全的，即同时可以有多个线程等待在 iocp 的完成队列上； 　　而 epoll 不行，同时只能有一个线程执行 epoll_wait 操作，因此这里需要做一点处理， 　　网上有人使用 condition_variable + mutex 实现 leader-follower 线程模型，但我只用了一个 mutex 就实现了， 　　当有事件发生了，leader 线程在执行事件处理器之前 unlock 这个 mutex， 　　就可以允许等待在这个 mutex 上的其它线程中的一个进入 epoll_wait 从而担任新的 leader。 　　（不知道多加一个 cv 有什么用，有明白原理的提示一下哈） b) epoll 在加入、删除句柄时是可以跨线程的，而且这一操作是线程安全的。 　　之前一直以为 epoll 会像 select 一像，添加或删除一个句柄需要先通知 leader 从 epoll_wait 中醒来， 　　在重新 wait 之前通过 epoll_ctl 添加或删除对应的句柄。但是现在看完全可以在另一个线程中执行 epoll_ctl 操作 　　而不用担心多线程问题

本文博客地址： http://blog.csdn.net/qq1084283172/article/details/75200800 一、序言 在前面的博客中，已经分析过了Android Hook框架adbi源码的具体实现，Android Hook框架adbi的实现主要分为两部分，一部分是root权限下的Android跨进程的so注入，一部分是基于Android系统的inline Hook。只要搞清楚了Android系统的跨进程so注入和基于Android系统的inline Hook这两个知识点，理解adbi等Android的Hook框架就不是问题了。Android系统的跨进程so注入和Android的各种Hook非常重要而且它们应用的范围也非常广，Android加固中的反调试对抗、反内存dump对抗，基于ClassLoader的VirtualApp的Hook等等。前面的博客中已经学习了adbi的实现原理，但是仅仅理解原理还不够，实践一下证明adbi的inline Hook是有效的才ok，在接下来的博文将着重记录一下adbi的源码的编译和inlineHook操作实践。 二、Android Hook框架adbi的inline Hook代码的简析 Android Hook框架adbi的inline Hook部分主要代码的简要解析和说明。 带有注释分析的Android

【翻译】.NET 5中的性能改进 在.NET Core之前的版本中，其实已经在博客中介绍了在该版本中发现的重大性能改进。 从.NET Core 2.0到.NET Core 2.1到.NET Core 3.0的每一篇文章，发现 谈论越来越多的东西。 然而有趣的是，每次都想知道下一次是否有足够的意义的改进以保证再发表一篇文章。 .NET 5已经实现了许多性能改进，尽管直到今年秋天才计划发布最终版本，并且到那时很有可能会有更多的改进，但是还要强调一下，现在已提供的改进。 在这篇文章中，重点介绍约250个PR，这些请求为整个.NET 5的性能提升做出了巨大贡献。 安装 Benchmark.NET现在是衡量.NET代码性能的规范工具，可轻松分析代码段的吞吐量和分配。 因此，本文中大部分示例都是使用使用该工具编写的微基准来衡量的。首先创建了一个目录，然后使用dotnet工具对其进行了扩展： mkdir Benchmarks cd Benchmarks dotnet new console 生成的Benchmarks.csproj的内容扩展为如下所示： <Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <AllowUnsafeBlocks>true</AllowUnsafeBlocks>

1、select默认支持的文件描述符太少，只有1024，而epoll没有文件描述符限制。 2、每次调用select都要将文件描述符集合重构用户态拷贝到内核态，开销大；而epoll只在用epoll_ctl()函数进行事件注册时，会将文件描述符复制到内核。保证了每个文件描述符在epoll过程中只拷贝一次。 3、select是主动轮询机制，需要遍历文件描述符集合，并且只能得到某个文件描述符就绪的通知，不知道究竟是那个就绪，所以还需进行轮询查找就绪的文件描述符。epoll是被动触发机制，即给注册的每个文件描述符注册个回调函数，当数据准备好，就会把就绪的文件描述符加入到一个就绪队列中，epoll想要查看有没有就绪文件描述符，只需要看看就绪队列是否为空即可。（ epoll_wait的工作方式实际上就是在这个就绪队列中查看有没有就绪的fd，如果有，就唤醒就绪队列上的等待者，然后调用回调函数。 ） 来源： oschina 链接： https://my.oschina.net/u/3991724/blog/4486435

epoll --> 服务器 --> 监听 --> fd --> 可读 --> epoll返回 --> read --> 小写转大写 --> write --> epoll继续监听 反应堆模型 epoll --> 服务器 --> 监听 --> cfd --> 可读 --> epoll返回 --> read --> cfd从树上摘下 --> 设置监听cfd写时间(滑动窗口), 操作 --> 小写转大写 --> 等待epoll_wait返回 --> 回写客户端 --> cfd从树上摘下 --> 设置监听cfd读事件, 操作 --> epoll继续监听 struct myevent_s { int fd; // 要监听的文件描述符 int events; // 对应的监听事件 void *arg; // 泛型参数 void (*call_back)(int fd, int events, void *arg); // 回调函数 int status; // 是否在监听: 1->在红黑树上(监听), 0->不在(不监听) char buf[BUFLEN]; int len; long last_active; // 记录每次加入红黑树的时间, 长时间无数据交互踢掉 }; int g_efd; // 全局变量, 保存epoll_create返回的文件描述符 struct myevent_s g

想了解nginx的代理可以先看这篇： https://baijiahao.baiducom/s?id=1652608869911988442&wfr=spider&for=pc nginx常用命令 nginx -t ##检查配置文件，一般修改完配置文件都建议一定先执行这条命令检查一下，无误再继续下一步 nginx –s reload ##重新加载配置文件，动态加载使你可以不用重启nginx nginx - s reopen # 重启 Nginx nginx - s stop # 停止 Nginx nginx配置 我们可以打开nginx的配置文件 nginx.conf 先看看 #user nobody; #Nginx用户及组：用户 组。window下不指定 worker_processes 1; #工作进程：数目。根据硬件调整，通常等于CPU数量或者2倍于CPU。 #错误日志：存放路径。 #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application