博客备案了一个月，中途也有各种工作的事情，现在继续更新。 前面从比较远的角度介绍了JVM的一些小常识, 如果没看懂也没关系，毕竟学习的过程就是 先感性认识，后才能升华到理性认识。所谓书读百遍其义自见也是类似的道理。

这次谈谈Java的平台无关性的基石: Class文件。

开个新系列，本系列会对JVM的知识点拾遗, 也是对自己JVM学习的一个梳理。 关于JVM的方方面面都会讲到，应该会是理论为主，辅代码和图(不会是纯理论的)。

以前看过林林总总的JVM书籍，比如周志明大佬的<<深入理解Java虚拟机>>和张秀宏大佬的<<自己动手写Java虚拟机>>, 也跟着造了个小JVM,所以也尝试将知识整理下 本系列会比较长，但是会把知识点细分，前后贯通串起来。 如果没有特殊指出，JVM使用的是Hotspot VM,JDK使用的是OpenJDK8

迟来的总结，NIO系列写了11篇了，本篇做个总结吧 写这个系列的起因是各个框架比如netty, tomcat, jetty这些高性能框架的 基石就是NIO, 一直想讲讲它们高性能的原因。

前面已经讲了Selector,SocketChannel和DirectBuffer, 这些是NIO网络编程中最核心的组件 接下来我们会再讲几点非核心的优化(不代表不重要, 只是API不占NIO设计的大头):

• 文件传输(File Transfer): 文件内容直接发送到网卡, 或者从网卡直接读到文件里
• 内存映射文件(Memory-mapped Files): 将文件的一块映射到内存

这两项本质上都基于零拷贝(zero copy)技术。

前面我们详细讲了Java-NIO分析-8-Selector详解和Java-NIO分析-9-从BSD-socket到SocketChannel, 分别是NIO的事件分发器和非阻塞处理器.

为了支持Channel的双向读写和Scatter/Gather操作，我们还需要Buffer,将I/O数据存储备用。普通的Buffer都是JVM堆内的Buffer, 比较好理解.

接下来我们聊聊JVM使用堆外内存的沧桑历史以及为什么要设计出DirectBuffer。

前面我们讲了高并发核心Selector的源码分析，看到其对操作系统I/O多路复用的简单封装。 有了I/O多路复用之后，我们还需要非阻塞的socket读写操作.

因为内核告诉你A连接有数据可读，你想要读1K, 事实上只读到了0.5K, 如果使用传统的 socket API, 那么进程或者线程会在这里阻塞，浪费了CPU的时钟周期和珍贵的线程资源。 使用非阻塞就能在没有读满之前立刻返回，数据先放内存里，然后继续读下一个B连接的数据。

SocketChannel就是NIO对于非阻塞socket操作的支持的组件，其在socket上封装了一层, 所以我们先从Socket API说起。

上节Java-NIO分析-7-NIO核心分析之Channel-Buffer和Selector介绍了Channel，Buffer和Selector的基本用法 有了感性认识之后，来看看Selector的底层是如何实现的。

1. Selector设计

笔者下载得是openjdk8的源码, 画出类图

比较清晰得看到，openjdk中Selector的实现是SelectorImpl, 然后SelectorImpl又将职责委托给了具体的平台，比如图中框出的linux2.6以后才有的EpollSelectorImpl, Windows平台则是WindowsSelectorImpl, MacOSX平台是KQueueSelectorImpl.

从名字也可以猜到，openjdk肯定在底层还是用epoll,kqueue，iocp这些技术来实现的I/O多路复用。前面 Java-NIO分析-3-I-O多路复用之select系统调用 ,Java-NIO分析-4-I-O多路复用之poll系统调用 , Java-NIO分析-5-I-O多路复用之epoll系统调用写了3篇来说明其用法，感兴趣的读者可以回头看看。

上次Java-NIO分析-6-Java-NIO中的概念讲到了NIO的设计思想, 即Doug Lea大佬受AWT启发得到的事件驱动机制, 关键点在于

• 非阻塞处理器
• 事件分发组件

在NIO的API中，Channel就是实现非阻塞的组件，而事件分发(Dispatcher)使用的是Selector组件， 在传统的I/O流(Stream)是有方向的，而NIO支持双向读写，这样就需要将流中的数据读取到某个缓冲组件里， 即Buffer组件.

Buffer组件还有个特殊的实现DirectByteBuffer, 可以申请堆外内存，关于为什么要申请堆外内存后续会谈。

前面介绍了Unix的I/O模型以及多路复用的c实现，为什么要介绍这些呢？ 因为JVM是用c++写的，JDK的native方法也都是用c写的，最后它们调用 的还是操作系统底层的api,所以了解一些关键的底层原理还是有必要的。

1. epoll概念

poll系统调用相比于select主要解决了文件描述符的数量限制，但是在高并发场景下没有解决根本问题:

1. fd数组整体在内核空间和用户空间之间拷贝
2. 遍历整个fd数组找事件浪费资源

这俩性能问题在Banga在1999年写了篇论文A Scalable and Explicit Event Delivery Mechanism for UNIX,提出select和poll都是无状态的，需要用户空间的进程自行遍历查找事件, 一种改进方案是内核内部自己维护事件集合.通过一个类似declare_interest的系统调用，内核能够增量得更新进程感兴趣的事件集合列表, 应用进程通过使用get_next_event调用能派发新事件给内核。

根据论文的研究成果，LINUX和FreeBSD各自给出的解决方案：epoll和kqueue.我们主要讨论epoll, 毕竟日常服务端环境都是LINUX.

在LINUX内核2.6以上，epoll才受到支持。