Netty In Action 读书笔记 - 第一章 Netty和Java NIO API

Netty In Action读书笔记，多半是翻译……，会尽量加上自己的理解，如有不对请指出。

本章包括：

1、Netty架构

2、为什么我们需要非阻塞IO（NIO）

3、阻塞与非阻塞IO对比

4、已知的JDK NIO实现问题和Netty的解决方案

为什么选择Netty

Netty提供给开发者一整套的工具：

设计：

为不同的传输类型提供统一的API，阻塞或非阻塞Socket；

灵活使用；

简单但是强大的线程模型；

真正的无连接数据包套接字支持；

逻辑链使得重用更加容易；

易用：

编排良好的JavaDoc，及大量的使用实例；

不依赖除JDK1.6（及以上）以外的任何库，有些特性仅在Java1.7环境下支持，另外一些特性可能有其他依赖，但它们是可选的；

性能：

比Java核心APIs有着更好的吞吐量，和更低的延迟；

通过池化和重用，降低资源消耗；

最小化不必要的内存拷贝；

健壮性：

不会再因过快、过慢，或过载的连接，产生OutOfMemory异常；

不再有NIO应用在高速网络处理环境下经常出现的读/写率不公平的情况；

安全：

完整支持SSL/TLS和StartTLS；

可运行在Applet或OSGI这样受限的环境下；

社区：

发布快速，迭代迅速；

活跃度高；

异步设计

整个Netty API都是异步的。异步设计思想已经存在一段时间了，由于IO经常是瓶颈，在等待IO时，异步处理鼓励我们以更加有效的方式使用系统资源：开始一个任务并且在任务结束时得到通知，而不是等待它直到完成。在任务执行时，我们可以做其他的事情。

下面介绍两种异步处理设计API并比较技术上的异同：

1、Callbacks

常被用在异步处理中，一个Callback被传递给方法，并在方法完成之后执行。

2、Futures

Future是一种抽象，代表了在某个时间变得可用的值。一个Future对象要么持有运算的结果，要么持有引起运算失败的异常；

JVM中的阻塞与非阻塞IO对比

使用Java完成网络编程任务，通常有两种方式：

-使用IO，也称作阻塞IO；

-使用NIO，也称作非阻塞IO；

阻塞IO使用单一线程处理一个连接，连接和线程数是1：1的，因此受限于JVM所能创建的线程数。

非阻塞IO使用Selector来处理多个连接。

非阻塞IO基础概念

ByteBuffer

可在堆上分配，也可直接分配（使用堆外内存）。通常在将buffer传输至channel时，直接分配的方式会快一些，但是内存分配/回收的代价比较高；Slicing创建一个新的ByteBuffer与原有的ByteBuffer共享数据，但是仅暴露数据的一部分子集，此方法可减少内存拷贝；

Selectors

Channnel代表了到一个可以执行IO操作的实体的连接，如文件或套接字；

Selector是一个NIO组件，用来决策一个或多个channels是否已经准备好读/写，因此，一个selector可以被用来处理多个连接。

NIO存在的问题及Netty的解决办法

跨平台及兼容性问题 - IO依赖底层操作系统，NIO很可能会存在问题（大段/小段等）；

继承ByteBuffer - 无法继承（private构造函数），操作不易；

Scattering和Gathering可能导致内存泄漏；

EpollBug - 在Linux内核的操作系统上，selector使用epoll作为IO事件提醒机制。这是一种操作系统与网络栈异步协作的高性能技术。不幸的是，epoll可能导致selector状态异常，和cpu100占用。此时selector不再阻塞而是直接返回，这违反了JavaDoc中的约定。