NIO学习笔记——操作系统与I/O交互简介

为什么使用NIO

　　在前一段时间我在看dubbo和kafka的源码时发现他们底层很多都是借助于NIO实现的，这些优秀的开源框架为什么使用NIO，相信NIO是一种高效的程序处理方式，从今天我们开始踏入NIO学习的殿堂。作为程序员我们要知道我们代码中的I/O操作相比其他代码要耗时的多的，我们在做I/O操作时要特别注意I/O的优化。现在 JVM 运行字节码的速率已经接近本地编译代码，借助动态运行时优化。这就意味着，多数 Java 应用程序已不再受 CPU 的束缚（把大量时间用在执行代码上），而更多时候是受 I/O 的束缚（等待数据传输）。然而，在大多数情况下， Java 应用程序并非真的受着 I/O 的束缚。操作系统并非不能快速传送数据，而是JVM自身在I/O方面效率欠佳。操作系统并非不能快速传送操作系统与 Java 基于流的 I/O模型有些不匹配，操作系统要移动的是大块数据（缓冲区），这往往是在硬件直接存储器存取（ DMA）的协助下完成的。而 JVM 的 I/O 类喜欢操作小块数据——单个字节、几行文本。结果操作系统送来整缓冲区的数据， java.io 的流数据类再花大量时间把它们拆成小块，往往拷贝一个小块就要往返于几层对象。操作系统喜欢整卡车地运来数据， java.io 类则喜欢一铲子一铲子地加工数据。有了 NIO，就可以轻松地把一卡车数据备份到您能直接使用的地方（ ByteBuffer 对象）。
JVM是一把双刃剑，虽然他实现了Java平台无关性，但是隐藏了操作系统的技术细节意味着某些个性鲜明和功能强大的特性被拒之门外。为了解决这一问题在jdk1.4以后java.nio软件包提供了新的抽象，也就是channel和selector类。

NIO和传统IO的区别

　　传统的socket IO中，需要为每个连接创建一个线程，当并发的连接数量非常巨大时，线程所占用的栈内存和CPU线程切换的开销将非常巨大。使用NIO，不再需要为每个线程创建单独的线程，可以用一个含有限数量线程的线程池，甚至一个线程来为任意数量的连接服务。由于线程数量小于连接数量，所以每个线程进行IO操作时就不能阻塞，如果阻塞的话，有些连接就得不到处理，NIO提供了这种非阻塞的能力。
小量的线程如何同时为大量连接服务呢，答案就是就绪选择。这就好比到餐厅吃饭，每来一桌客人，都有一个服务员专门为你服务，从你到餐厅到结帐走人，这样方式的好处是服务质量好，一对一的服务，VIP啊，可是缺点也很明显，成本高，如果餐厅生意好，同时来100桌客人，就需要100个服务员，那老板发工资的时候得心痛死了，这就是传统的一个连接一个线程的方式。
　　老板是什么人啊，精着呢。这老板就得捉摸怎么能用10个服务员同时为100桌客人服务呢，老板就发现，服务员在为客人服务的过程中并不是一直都忙着，客人点完菜，上完菜，吃着的这段时间，服务员就闲下来了，可是这个服务员还是被这桌客人占用着，不能为别的客人服务，用华为领导的话说，就是工作不饱满。那怎么把这段闲着的时间利用起来呢。这餐厅老板就想了一个办法，让一个服务员（前台）专门负责收集客人的需求，登记下来，比如有客人进来了、客人点菜了，客人要结帐了，都先记录下来按顺序排好。每个服务员到这里领一个需求，比如点菜，就拿着菜单帮客人点菜去了。点好菜以后，服务员马上回来，领取下一个需求，继续为别人客人服务去了。这种方式服务质量就不如一对一的服务了，当客人数据很多的时候可能需要等待。但好处也很明显，由于在客人正吃饭着的时候服务员不用闲着了，服务员这个时间内可以为其他客人服务了，原来10个服务员最多同时为10桌客人服务，现在可能为50桌，60客人服务了。
这种服务方式跟传统的区别有两个：
1、增加了一个角色，要有一个专门负责收集客人需求的人。NIO里对应的就是Selector。
2、由阻塞服务方式改为非阻塞服务了，客人吃着的时候服务员不用一直侯在客人旁边了。传统的IO操作，比如read()，当没有数据可读的时候，线程一直阻塞被占用，直到数据到来。NIO中没有数据可读时，read()会立即返回0，线程不会阻塞。
NIO中，客户端创建一个连接后，先要将连接注册到Selector，相当于客人进入餐厅后，告诉前台你要用餐，前台会告诉你你的桌号是几号，然后你就可能到那张桌子坐下了，SelectionKey就是桌号。当某一桌需要服务时，前台就记录哪一桌需要什么服务，比如1号桌要点菜，2号桌要结帐，服务员从前台取一条记录，根据记录提供服务，完了再来取下一条。这样服务的时间就被最有效的利用起来了。
摘自http://blog.csdn.net/zhouhl_cn/article/details/6568119

缓冲区操作

　　进程执行 I/O操作，归结起来，也就是向操作系统发出请求，让它要么把缓冲区里的数据排干（写），要么用数据把缓冲区填满（读）。进程使用这一机制处理所有数据进出操作。操作系统内部处理这一任务的机制，其复杂程度可能超乎想像。
下面我看下I/O缓冲区简易示意图

　　上图简单的描述了数据从外部磁盘向运行中的进程的内存区域移动的过程。进程使用 read( )系统调用，要求其缓冲区被填满。内核随即向磁盘控制硬件发出命令，要求其从磁盘读取数据。磁盘控制器把数据直接写入内核内存缓冲区，这一步通过 DMA 完成，无需主 CPU 协助。一旦磁盘控制器把缓冲区装满，内核即把数据从内核空间的临时缓冲区拷贝到进程执行 read( )调用时指定的缓冲区。
用户空间：常规进程所在区域。 JVM 就是常规进程，驻守于用户空间。用户空间是非特权区域：比如，在该区域执行的代码就不能直接访问硬件设备。
内核空间：操作系统所在区域。内核代码有特别的权力：它能与设备控制器通讯，控制着用户区域进程的运行状态
为什么不直接把数据从硬盘传输到用户空间的缓冲区？
1、硬件不能直接访问用户空间
2、硬盘基于块存储操作的是固定大小的数据块，而用户进程请求是任意大小或非对齐的数据块，内核负责了数据分解、再组合角色

发散汇聚

　　许多操作系统能把组装／分解过程进行得更加高效。根据发散／汇聚的概念，进程只需一个系统调用，就能把一连串缓冲区地址传递给操作系统。然后，内核就可以顺序填充或排干多个缓冲区，读的时候就把数据发散到多个用户空间缓冲区，写的时候再从多个缓冲区把数据汇聚起来，如下图所示：
　　
　　 这样用户进程就不必多次执行系统调用（那样做可能代价不菲），内核也可以优化数据的处理过程，因为它已掌握待传输数据的全部信息。如果系统配有多个 CPU，甚至可以同时填充或排干多个缓冲区

虚拟内存

　　虚拟内存意为使用虚假（或虚拟）地址取代物理（硬件RAM）内存地址
好处：
1. 一个以上的虚拟地址可指向同一个物理内存地址。
2. 虚拟内存空间可大于实际可用的硬件内存
我们知道设备控制器不能直接通过DMA存储到用户空间，但是利用虚拟地址可以指向同一个物理内存地址，把内核空间地址和用户空间的虚拟地址映射到同一个物理地址，这样DMA硬件可以填充对内核和用户空间进程同时可见的缓存区，如下图所示内存空间多重映射

　　这样省去内核与用户空间的往来拷贝，但前提条件是，内核与用户缓冲区必须使用相同的页对齐，缓冲区的大小还必须是磁盘控制器块大小（通常为 512 字节磁盘扇区）的倍数。操作系统把内存地址空间划分为页，即固定大小的字节组。内存页的大小总是磁盘块大小的倍数，通常为 2次幂（这样可简化寻址操作）。典型的内存页为 1,024、 2,048 和 4,096 字节。虚拟和物理内存页的大小总是相同的。

内存页面调度

　　为了支持虚拟内存的第二个特性（寻址空间大于物理内存），就必须进行虚拟内存分页（经常称为交换，虽然真正的交换是在进程层面完成，而非页层面）。依照该方案，虚拟内存空间的页面能够继续存在于外部磁盘存储，这样就为物理内存中的其他虚拟页面腾出了空间。从本质上说，物理内存充当了分页区的高速缓存；而所谓分页区，即从物理内存置换出来，转而存储于磁盘上的内存页面。
把内存页大小设定为磁盘块大小的倍数，这样内核就可直接向磁盘控制硬件发布命令，把内存页写入磁盘，在需要时再重新装入。结果是，所有磁盘 I/O 都在页层面完成。对于采用分页技术的现代操作系统而言，这也是数据在磁盘与物理内存之间往来的唯一方式。现代 CPU 包含一个称为内存管理单元（ MMU）的子系统，逻辑上位于 CPU 与物理内存之间。该设备包含虚拟地址向物理内存地址转换时所需映射信息。当 CPU 引用某内存地址时， MMU
　　负责确定该地址所在页（往往通过对地址值进行移位或屏蔽位操作实现），并将虚拟页号转换为物理页号（这一步由硬件完成，速度极快）。如果当前不存在与该虚拟页形成有效映射的物理内存页， MMU 会向 CPU 提交一个页错误。页错误随即产生一个陷阱（类似于系统调用），把控制权移交给内核，附带导致错误的虚拟地址信息，然后内核采取步骤验证页的有效性。内核会安排页面调入操作，把缺失的页内容读回物理内存。这往往导致别的页被移出物理内存，好给新来的页让地方。在这种情况下，如果待移出的已经被碰过了（自创建或上次页面调入以来，内容已发生改变），还必须首先执行页面调出，把页内容拷贝到磁盘上的分页区。如果所要求的地址不是有效的虚拟内存地址（不属于正在执行的进程的任何一个内存段），则该页不能通过验证，段错误随即产生。于是，控制权转交给内核的另一部分，通常导致的结果就是进程被强令关闭。一旦出错的页通过了验证， MMU 随即更新，建立新的虚拟到物理的映射（如有必要，中断被移出页的映射），用户进程得以继续。造成页错误的用户进程对此不会有丝毫察觉，一切都在不知不觉中进行

文件I/O

　　磁盘把数据存在扇区上，通常每个扇区512个字节，磁盘属于硬件对文件一无所知，他只提供了一系列数据存取窗口，文件是安排、解释磁盘数据的一种方式。文件系统定义了文件名、路径、文件、文件属性等抽象概念。
　　所有的I/O都是通过请求页面调度完成，页面调度仅发生在磁盘扇区与内存页之间的直接传输，而文件I/O可以任意大小、任意定位。
　　文件系统把一连串大小一致的数据块组织到一起。有些块存储元信息，如空闲块、目录、索引等的映射，有些包含文件数据。单个文件的元信息描述了哪些块包含文件数据、数据在哪里结束、最后一次更新是什么时候，等等。当用户进程请求读取文件数据时，文件系统需要确定数据具体在磁盘什么位置，然后着手把相关磁盘扇区读进内存。老式的操作系统往往直接向磁盘驱动器发布命令，要求其读取所需磁盘扇区。而采用分页技术的现代操作系统则利用请求页面调度取得所需数据。
采用分页技术的操作系统执行的I/O的全过程可总结为以下几步
1、确定请求的数据分布在文件系统的哪些页（磁盘扇区组）。磁盘上的文件内容和元数据可能跨越多个文件系统页，而且这些页可能也不连续。
2、在内核空间分配足够数量的内存页，以容纳得到确定的文件系统页。
3、在内存页与磁盘上的文件系统页之间建立映射。
4、为每一个内存页产生页错误。
5、虚拟内存系统俘获页错误，安排页面调入，从磁盘上读取页内容，使页有效。
6、一旦页面调入操作完成，文件系统即对原始数据进行解析，取得所需文件内容或属性信息
如果内存争用情况不严重，这些文件系统页可能在相当长的时间内继续有效。这样的话，当稍后该文件又被相同或不同的进程再次打开，可能根本无需访问磁盘

内存映射文件

　　传统的文件 I/O 是通过用户进程发布 read( )和 write( )系统调用来传输数据的。为了在内核空间的文件系统页与用户空间的内存区之间移动数据，一次以上的拷贝操作几乎总是免不了的。这是因为，在文件系统页与用户缓冲区之间往往没有一一对应关系。但是，还有一种大多数操作系统都支持的特殊类型的 I/O 操作，允许用户进程最大限度地利用面向页的系统 I/O 特性，并完全摒弃缓冲区拷贝。这就是内存映射 。内存映射 I/O 使用文件系统建立从用户空间直到可用文件系统页的虚拟内存映射的好处如下：
1、用户进程把文件数据当作内存，所以无需发布 read( )或 write( )系统调用。
2、当用户进程碰触到映射内存空间，页错误会自动产生，从而将文件数据从磁盘读进内存。如果用户修改了映射内存空间，相关页会自动标记为脏，随后刷新到磁盘，文件
得到更新。
3、操作系统的虚拟内存子系统会对页进行智能高速缓存，自动根据系统负载进行内存管理。
4、数据总是按页对齐的，无需执行缓冲区拷贝。
5、大型文件使用映射，无需耗费大量内存，即可进行数据拷贝。
虚拟内存和磁盘 I/O 是紧密关联的，从很多方面看来，它们只是同一件事物的两面。在处理大量数据时，尤其要记得这一点。如果数据缓冲区是按页对齐的，且大小是内建页大小的倍数，那么，对大多数操作系统而言，其处理效率会大幅提升

文件系统锁定

　　文件锁定机制允许一个进程阻止其他进程存取某文件，或限制其存取方式。通常的用途是控制共享信息的更新方式，或用于事务隔离。在控制多个实体并行访问共同资源方面，文件锁定是必不可少的。数据库等复杂应用严重信赖于文件锁定。
　　“文件锁定”从字面上看有锁定整个文件的意思（通常的确是那样），但锁定往往可以发生在更为细微的层面，锁定区域往往可以细致到单个字节。锁定与特定文件相关，开始于文件的某个特定字节地址，包含特定数量的连续字节。这对于协调多个进程互不影响地访问文件不同区域，是至关重要的。
文件锁定有两种方式：共享的和独占的。多个共享锁可同时对同一文件区域发生作用；独占锁则不同，它要求相关区域不能有其他锁定在起作用。共享锁和独占锁的经典应用，是控制最初用于读取的共享文件的更新。某个进程要读取文件，会先取得该文件或该文件部分区域的共享锁。第二个希望读取相同文件区域的进程也会请求共享锁。两个进程可以并行读取，互不影响。但是，假如有第三个进程要更新该文件，它会请求独占锁。该进程会处于阻滞状态，直到既有锁定（共享的、独占的）全部解除。一旦给予独占锁，其他共享锁的读取进程会处于阻滞状态，直到独占锁解除。这样，更新进程可以更改文件，而其他读取进程不会因为文件的更改得到前后不一致的结果。
参考资料：《Java NIO》