【Java 难点攻克】「NIO 和内存映射性能提升系列」彻底透析 NIO 底层的内存映射机制原理与 Direct Memory 的关系

NIO 与内存映射文件

Java 类库中的 NIO 包相对于 IO 包来说有一个新功能就是 【内存映射文件】，在业务层面的日常开发过程中并不是经常会使用，但是一旦在处理大文件时是比较理想的提高效率的手段，之前已经在基于 API 和开发实战角度介绍了相关的大文件读取以及 NIO 操作的实现，而本文主要想结合操作系统(OS)底层中相关方面的内容进行分析原理，夯实大家对 IO 模型及操作系统相关的底层知识体系。

下图就是 Java 应用程序以及操作系统 OS 内核的调用关系图：

我们会针对于操作系统与应用程序之间建立的关系去分析 IO 处理底层机制。

传统的 IO 技术

在传统的文件 IO 操作中， 我们都是调用操作系统提供的底层标准 IO 系统调用函数 read()、write() ， 此时调用此函数的进程（Java 进程） 由当前的用户态切换到内核态， 然后 OS 的内核代码负责将相应的文件数据读取到内核的 IO 缓冲区，然后再把数据从内核 IO 缓冲区拷贝到进程的私有地址空间中去，这样便完成了一次 IO 操作，如下图所示。

程序的局部性原理

为什么需要内核 IO 缓冲区

至于为什么要多此一举搞一个内核 IO 缓冲区把原本只需一次拷贝数据的事情搞成需要 2 次数据拷贝呢?

IO 拷贝的预先局部拷贝

为了减少磁盘的 IO 操作，为了提高性能而考虑的，因为我们的程序访问一般都带有局部性，也就是所谓的局部性原理，在这里主要是指的空间局部性，即我们访问了文件的某一段数据，那么接下去很可能还会访问接下去的一段数据，由于磁盘 IO 操作的速度比直接访问内存慢了好几个数量级，所以 OS 根据局部性原理会在一次 read(系统调用过程中预读更多的文件数据缓存在内核 IO 缓冲区中， 当继续访问的文件数据在缓冲区中时便直接拷贝数据到进程私有空间， 避免了再次的低效率磁盘 IO 操作。

应用程序 IO 操作实例

在 Java 中当我们采用 IO 包下的文件操作流，如：

FileInputStream in=new FileInputStream("/usr/text") ；in.read();

JAVA 虚拟机内部便会调用 OS 底层的 read()系统调用完成操作， 在第二次调用 read()的时候很可能就是从内核缓冲区直接返回数据了，此外还有可能需要经过 native 堆做一次中转，因为这些函数都被声明为 native， 即本地方法， 所以可能在 C 语言中有做一次中转， 如 win32/win64 中就是通过 C 语言从 OS 读取数据， 然后再传给 JVM 内存 。

系统调用与应用程序

既然如此， Java-IO 包中为啥还要提供一个 BufferedInputStream 类来作为缓冲区呢，关键在于四个字， "系统调用"，当读取 OS 内核缓冲区数据的时候， 便发起了一次系统调用操作(通过 native 的 C 函数调用)，而系统调用的代价相对来说是比较高的，涉及到进程用户态和内核态的上下文切换等一系列操作，所以我们经常采用如下的包装：

File ln put Stream in=new FileInputStream("/user/txt") ；BufferedInputStream buf in=new BufferedInputStream(in) ；buf in.read()；

通过 Buffer 减少系统调用次数（经常被理解错误）

• 有了 Buffer 缓存，我们每一次 in.read() 时候， BufferedInputStream 会根据情况自动为我们预读更多的字节数据到它自己维护的一个内部字节数组缓冲区中，这样我们便可以减少系统调用次数， 从而达到其缓冲区的目的。

• 所以要明确的一点是 BufferedInputStream 的作用不是减少磁盘 IO 操作次数，因为操作系统 OS 已经帮我们完成了，而是通过减少系统调用次数来提高性能的。

• 同理 BufferedOuputStream， BufferedReader/Writer 也是一样的。在 C 语言的函数库中也有类似的实现， 如，fread()是 C 语言中的缓冲 IO， 与 BufferedInputStream()相同.

BufferedInputStream 分析

从上面的源码我们可以看到，BufferedInputStream 内部维护着一个字节数组 byte[] buf 来实现缓冲区的功能，调用的 buf 的 in.read()方法在返回数据之前有做一个 if 判断， 如果 buf 数组的当前索引不在有效的索引范围之内， 即 if 条件成立， buf 字段维护的缓冲区已经不够了， 这时候会调用内部的 fill()方法进行填充， 而 fill()会预读更多的数据到 buf 数组缓冲区中去， 然后再返回当前字节数据， 如果 if 条件不成立便直接从 buf 缓冲区数组返回数据了。

BufferedInputStream 的 buff 的可见性

对于 read 方法中的 getBufIfOpen()返回的就是 buf 字段的引用，源码中的 buf 字段声明为protected volatile byte buf；主要是为了通过 volatile 关键字保证 buf 数组在多线程并发环境中的内存可见性.

内存映射文件的实现

内存映射文件和之前说的标准 IO 操作最大的不同之处就在于它虽然最终也是要从磁盘读取数据，但是它并不需要将数据读取到 OS 内核缓冲区，而是直接将进程的用户私有地址空间中的一部分区域与文件对象建立起映射关系，就好像直接从内存中读、写文件一样，速度当然快了，如下图所示。

Linux 中的进程虚拟存储器， 即进程的虚拟地址空间， 如果你的机子是 32 位，那么就有 2^32=4G 的虚拟地址空间，我们可以看到图中有一块区域：

“Memory mapped region for shared libraries”

这段区域就是在内存映射文件的时候将某一段的虚拟地址和文件对象的某一部分建立起映射关系，此时并没有拷贝数据到内存中去，而是当进程代码第一次引用这段代码内的虚拟地址时，触发了缺页异常，这时候 OS 根据映射关系直接将文件的相关部分数据拷贝到进程的用户私有空间中去，当有操作第 N 页数据的时候重复这样的 OS 页面调度程序操作。

内存映射文件的优点

内存映射文件的效率比标准 IO 高的重要原因就是因为少了把数据拷贝到 OS 内核缓冲区这一步(可能还少了 native 堆中转这一步) 。

Java 中提供了 3 种内存映射模式：只读(readonly) 、读写(read_write) 、专用(private) 。

只读(readonly) 模式

对于只读模式来说，如果程序试图进行写操作，则会抛出 Readonly Buffer Exception 异常。

read_write 模式

NIO 的 read_write 模式

read_write 读写模式表明了通过内存映射文件的方式写或修改文件内容的话是会立刻反映到磁盘文件中去的，别的进程如果共享了同一个映射文件，那么也会立即看到变化！

标准 IO 的 read_write 模式

标准 IO 那样每个进程有各自的内核缓冲区， 比如 Java 代码中， 没有执行 IO 输出流的 flush()或者 close()操作， 那么对文件的修改不会更新到磁盘去， 除非进程运行结束。

专用模式

专用模式采用的是 OS 的“写时拷贝”原则，即在没有发生写操作的情况下，多个进程之间都是共享文件的同一块物理内存(进程各自的虚拟地址指向同一片物理地址)，一旦某个进程进行写操作，那么将会把受影响的文件数据单独拷贝一份到进程的私有缓冲区中，不会反映到物理文件中去。

File file=new File("/usr/txt") ；FileInputStream in=new FileInputStream(file) ；File Channel channel=in.getChannel()；MappedByteBuffer buff=channel.map(File Channel.Map Mode.READ_ONLY， 0， channel.size 0) ；

这里创建了一个只读模式的内存映射文件区域， 接下来我就来测试下与普通 NIO 中的通道操作相比性能上的优势，先看如下代码：

输出为 63，即通过内存映射文件的方式读取 86M 多的文件只需要 78 毫秒，我现在改为普通 NIO 的通道操作看下：

File file=new File("/usr/txt") ；FileInputStream in=new FileInputStream(file) ；File Channel channel=in.getChannel()；ByteBuffer buff=ByteBuffer.allocate(1024) ；long begin=System.currentTimeMillis()；while(channel.read(buff) !=-1) {  buff.flip 0；  buff.clear 0；  long end=System.currentTimeMillis()；  System.out.print In("time is："+(end-begin) ) ；

输出为 468 毫秒，几乎是 6 倍的差距，文件越大，差距便越大。

内存映射的使用场景

内存映射特别适合于对大文件的操作， JAVA 中的限制是最大不得超过 Integer.MAXVALUE， 即 2G 左右， 不过我们可以通过分次映射文件(channel.map) 的不同部分来达到操作整个文件的目的。

内存映射的优势特点

内存映射属于 JVM 中的直接缓冲区， 还可以通过 ByteBuffer.allocateDirect， 即 Direct Memory 的方式来创建直接缓冲区。

相比基础的 IO 操作来说就是少了中间缓冲区的数据拷贝开销，同时他们属于 JVM 堆外内存， 不受 JVM 堆内存大小的限制。

其中 Direct Memory 默认的大小是等同于 JVM 最大堆， 理论上说受限于进程的虚拟地址空间大小， 比如 32 位的 windows 上， 每个进程有 4G 的虚拟空间除去 2G 为 OS 内核保留外， 再减去 JVM 堆的最大值， 剩余的才是 Direct Memory 大小。

通过设置 JVM 参数-Xmx64M， 即 JVM 最大堆为 64M， 然后执行以下程序可以证明 Direct Memory 不受 JVM 堆大小控制：

public static void main(String args) {  ByteBuffer.allocateDirect(1024*1024*100) ； //100MB}

输出结果如下：

[GC1371K->1328K(61312K) ， 0.0070033secs][Full GC1328K->1297K(61312K)，0.0329592secs][GC3029K->2481K(61312K) ， 0.0037401secs][Full GC2481K->2435K(61312K) ， 0.0102255secs]

看到这里执行 GC 的次数较少， 但是触发了两次 Full GC， 原因在于直接内存不受 GC(新生代的 Minor GC) 影响， 只有当执行老年代的 Full GC 时候才会顺便回收直接内存！而直接内存是通过存储在 JVM 堆中的 Direct ByteBuffer 对象来引用的， 所以当众多的 Direct ByteBuffer 对象从新生代被送入老年代后才触发了 full gc。再看直接在 JVM 堆上分配内存区域的情况：

public static void main(String~args) {  for(inti=0； i<10000； i++) {    ByteBuffer.allocate(1024*100) ； //100K  }}

ByteBuffer.allocate 意味着直接在 JVM 堆上分配内存， 所以受新生代的 Minor GC 影响， 输出如下：

[GC16023K->224K(61312K) ， 0.0012432secs][GC16211K->192K(77376K) ， 0.0006917secs][GC32242K->176K(77376K) ， 0.0010613secs][GC32225K->224K(109504K) ， 0.0005539secs][GC64423K->192K(109504K) ， 0.0006151secs][GC64376K->192K(171392K， 0.0004968secs][GC128646K->204K(171392K) ， 0.0007423secs][GC128646K->204K(299968K) ， 0.0002067secs][GC257190K->204K(299968K) ， 0.0003862secs][GC257193K->204K(287680K) ， 0.0001718secs][GC245103K->204K(276480K) ， 0.0001994secs][GC233662K->204K(265344K) ， 0.0001828secs][GC222782K->172K(255232K) ， 0.0001998secs][GC212374K->172K(245120K) ， 0.0002217secs]

可以看到， 由于直接在 JVM 堆上分配内存， 所以触发了多次 GC， 且不会触及 Full GC， 因为对象根本没机会进入老年代。

Direct Memory 和内存映射

NIO 中的 Direct Memory 和内存文件映射同属于直接缓冲区， 但是前者和-Xmx 和-XX:MaxDirectMemorySize 有关， 而后者完全没有 JVM 参数可以影响和控制，这让我不禁怀疑两者的直接缓冲区是否相同。

Direct Memory

Direct Memory 指的是 JAVA 进程中的 native 堆， 即涉及底层平台如 win 32 的 dII 部分， 因为 C 语言中的 malloc) 分配的内存就属于 native 堆， 不属于 JVM 堆，这也是 Direct Memory 能在一些场景中显著提高性能的原因， 因为它避免了在 native 堆和 jvm 堆之间数据的来回复制；

内存映射

内存映射则是没有经过 native 堆， 是由 JAVA 进程直接建立起某一段虚拟地址空间和文件对象的关联映射关系， 参见 Linux 虚拟存储器图中的“Memory mapped region for shared libraries”区域， 所以内存映射文件的区域并不在 JVM GC 的回收范围内， 因为它本身就不属于堆区， 卸载这部分区域只能通过系统调用 unmap()来实现(Linux)中， 而 JAVA API 只提供了 FileChannel.map 的形式创建内存映射区域， 却没有提供对应的 unmap()， 让人十分费解， 导致要卸载这部分区域比较麻烦。

Direct Memory 和内存映射结合所实现的案例

通过 Direct Memory 来操作前面内存映射和基本通道操作的例子， 来看看直接内存操作的话，程序的性能如何：

File file=new File("/usr/txt") ；FileInputStream in=new FilelnputStream(file) ；FileChannel channel=in.getChannel 0；ByteBuffer buff=ByteBuffer.allocateDirect(1024) ；long begin=System.currentTimeMillis(；while(channel.read(buff) !=-1) {  buff.flip()；  buff.clear()；  long end=System.currentTimeMillis();  System.out.printIn("time is："+(end-begin) )；}

程序输出为 312 毫秒， 看来比普通的 NIO 通道操作(468 毫秒) 来的快， 但是比 mmap 内存映射的 63 秒差距太多了， 通过修改； ByteBuffer buff=ByteBuffer.allocateDirect(1024) ；

ByteBuffer buff=ByteBuffer.allocateDirect((in) file.length 0) ， 即一次性分配整个文件长度大小的堆外内存，最终输出为 78 毫秒，由此可以得出堆外内存的分配耗时比较大，还是比 mmap 内存映射来得慢。

Direct Memory 的内存回收（非常重要总结）

最后一点为 Direct Memory 的内存只有在 JVM 执行 full gc 的时候才会被回收， 那么如果在其上分配过大的内存空间， 那么也将出现 OOM， 即便 JVM 堆中的很多内存处于空闲状态。

JVM 堆内存的限制范围

关于 JVM 堆大小的设置是不受限于物理内存， 而是受限于虚拟内存空间大小，理论上来说是进程的虚拟地址空间大小，但是实际上我们的虚拟内存空间是有限制的， 一般 windows 上默认在 C 盘， 大小为物理内存的 2 倍左右。