文章目录一. 反应堆1. 堵塞模型2. Java NIO的工作原理二. Netty与NIO一. 反应堆1. 堵塞模型阻塞I/O在调用InputStream.read()方法时是阻塞的它会一直等到数据到来或超时时才会返回同样在调用ServerSocket.accept()方法时也会一直阻塞到有客户端连接才会返回每个客户端连接成功后服务端都会启动一个线程去处理该客户端的请求。阻塞I/O的通信模型示意如下图所示。阻塞I/O通信模型的两个缺点。当客户端多时会创建大量的处理线程。且每个线程都要占用栈空间和一些CPU时间。有些请求没有数据就会导致这些栈空间和cpu就会被一直占用ing阻塞可能带来频繁的上下文切换且大部分上下文切换可能是无意义的。上下文切换CPU利用时间片轮询来为每个任务都服务一定的时间然后把当前任务的状态保存下来继续服务下一个任务。任务的状态保存及再加载叫做线程的上下文切换。2. Java NIO的工作原理由一个专门的线程来处理所有的I/O事件并负责分发。事件驱动机制不断地轮询判断事件是否到达事件到的时候触发而不是同步地去监视事件。线程通信因为请求而建立的线程之间通过wait、notify等方式通信how。保证每次上下文切换都是有意义的减少无谓的时间片进行线程切换。注每个线程的处理流程大概都是读取数据、解码、计算处理、编码和发送响应。二. Netty与NIONetty是一个异步的、事件驱动的、用来做高性能高可靠性的网络应用的框架。下面是其主要的优点。1框架设计优雅底层模型随意切换适应不同的网络协议要求。2提供了很多标准的协议、安全、编解码的支持。3解决了很多NIO不易用的问题。4社区更为活跃在很多开源框架中使用如Dubbo、RocketMQ、Spark等。Netty支持的功能与特性如下图所示。底层核心有Zero-Copy-Capable Buffer非常易用的零拷贝Buffer这个内容很有意思稍后专门来讲、统一的API、标准可扩展的事件模型。传输方面的支持有管道通信HTTP隧道TCP与UDP。协议方面的支持有基于原始文本和二进制的协议解压缩大文件传输流媒体传输ProtoBuf编解码安全认证HTTP和WebSocket。Netty采用NIO而非AIO的理由Netty不看重Windows上的使用在Linux系统上AIO的底层实现仍使用epoll没有很好地实现AIO因此在性能上没有明显的优势而且被JDK封装了一层不容易深度优化。Netty整体架构采用Reactor模型而AIO采用Proactor模型混在一起会非常混乱把AIO也改造成Reactor模型看起来是把Epoll绕个弯又绕回来。AIO还有个缺点是接收数据需要预先你需要预估缓存分配缓存而NIO是需要接收时才分配缓存所以对连接数量非常大但流量小的情况AIO浪费很多内存。Linux上AIO不够成熟处理回调结果的速度跟不上处理需求比如外卖员太少顾客太多供不应求造成处理速度有瓶颈。参考《Netty4核心原理与手写RPC框架》
文章目录一. 反应堆1. 堵塞模型2. Java NIO的工作原理二. Netty与NIO一. 反应堆1. 堵塞模型阻塞I/O在调用InputStream.read()方法时是阻塞的它会一直等到数据到来或超时时才会返回同样在调用ServerSocket.accept()方法时也会一直阻塞到有客户端连接才会返回每个客户端连接成功后服务端都会启动一个线程去处理该客户端的请求。阻塞I/O的通信模型示意如下图所示。阻塞I/O通信模型的两个缺点。当客户端多时会创建大量的处理线程。且每个线程都要占用栈空间和一些CPU时间。有些请求没有数据就会导致这些栈空间和cpu就会被一直占用ing阻塞可能带来频繁的上下文切换且大部分上下文切换可能是无意义的。上下文切换CPU利用时间片轮询来为每个任务都服务一定的时间然后把当前任务的状态保存下来继续服务下一个任务。任务的状态保存及再加载叫做线程的上下文切换。2. Java NIO的工作原理由一个专门的线程来处理所有的I/O事件并负责分发。事件驱动机制不断地轮询判断事件是否到达事件到的时候触发而不是同步地去监视事件。线程通信因为请求而建立的线程之间通过wait、notify等方式通信how。保证每次上下文切换都是有意义的减少无谓的时间片进行线程切换。注每个线程的处理流程大概都是读取数据、解码、计算处理、编码和发送响应。二. Netty与NIONetty是一个异步的、事件驱动的、用来做高性能高可靠性的网络应用的框架。下面是其主要的优点。1框架设计优雅底层模型随意切换适应不同的网络协议要求。2提供了很多标准的协议、安全、编解码的支持。3解决了很多NIO不易用的问题。4社区更为活跃在很多开源框架中使用如Dubbo、RocketMQ、Spark等。Netty支持的功能与特性如下图所示。底层核心有Zero-Copy-Capable Buffer非常易用的零拷贝Buffer这个内容很有意思稍后专门来讲、统一的API、标准可扩展的事件模型。传输方面的支持有管道通信HTTP隧道TCP与UDP。协议方面的支持有基于原始文本和二进制的协议解压缩大文件传输流媒体传输ProtoBuf编解码安全认证HTTP和WebSocket。Netty采用NIO而非AIO的理由Netty不看重Windows上的使用在Linux系统上AIO的底层实现仍使用epoll没有很好地实现AIO因此在性能上没有明显的优势而且被JDK封装了一层不容易深度优化。Netty整体架构采用Reactor模型而AIO采用Proactor模型混在一起会非常混乱把AIO也改造成Reactor模型看起来是把Epoll绕个弯又绕回来。AIO还有个缺点是接收数据需要预先你需要预估缓存分配缓存而NIO是需要接收时才分配缓存所以对连接数量非常大但流量小的情况AIO浪费很多内存。Linux上AIO不够成熟处理回调结果的速度跟不上处理需求比如外卖员太少顾客太多供不应求造成处理速度有瓶颈。参考《Netty4核心原理与手写RPC框架》
