RocketMQ 高性能存储

Rocketmq 是一款高性能的消息中间件。其中，存储文件的方式使用了 内存映射的方式。为什么不直接使用 堆外内存呢？因为 堆外内粗是和 OS 打交道的。而且，通过磁盘控制器读取到的数据先到 内存缓冲区中，然后 JVM 进行才能拿到这些数据。如果使用了 内存映射的方式，可以和硬件直接通信，这个效率不是一般的高啊！！！ 

转载：http://blog.csdn.net/fcbayernmunchen/article/details/8635427

Java类库中的NIO包相对于IO 包来说有一个新功能是内存映射文件，日常编程中并不是经常用到，但是在处理大文件时是比较理想的提高效率的手段。本文我主要想结合操作系统中（OS）相关方面的知识介绍一下原理。

在传统的文件IO操作中，我们都是调用操作系统提供的底层标准IO系统调用函数 read()、write() ，此时调用此函数的进程（在JAVA中即java进程）由当前的用户态切换到内核态，然后OS的内核代码负责将相应的文件数据读取到内核的IO缓冲区，然后再把数据从内核IO缓冲区拷贝到进程的私有地址空间中去，这样便完成了一次IO操作。至于为什么要多此一举搞一个内核IO缓冲区把原本只需一次拷贝数据的事情搞成需要2次数据拷贝呢？ 我想学过操作系统或者计算机系统结构的人都知道，这么做是为了减少磁盘的IO操作，为了提高性能而考虑的，因为我们的程序访问一般都带有局部性，也就是所谓的局部性原理，在这里主要是指的空间局部性，即我们访问了文件的某一段数据，那么接下去很可能还会访问接下去的一段数据，由于磁盘IO操作的速度比直接访问内存慢了好几个数量级，所以OS根据局部性原理会在一次 read()系统调用过程中预读更多的文件数据缓存在内核IO缓冲区中，当继续访问的文件数据在缓冲区中时便直接拷贝数据到进程私有空间，避免了再次的低效率磁盘IO操作。在JAVA中当我们采用IO包下的文件操作流，如：

[java] view plain copy

01.FileInputStream in = new FileInputStream(“D:\java.txt”);

[java] view plain copy

01.in.read();

JAVA虚拟机内部便会调用OS底层的 read()系统调用完成操作，如上所述，在第二次调用 in.read()的时候可能就是从内核缓冲区直接返回数据了（可能还有经过 native堆做一次中转，因为这些函数都被声明为 native，即本地平台相关，所以可能在C代码中有做一次中转，如 win32中是通过 C代码从OS读取数据，然后再传给JVM内存）。既然如此，JAVA的IO包中为啥还要提供一个 BufferedInputStream 类来作为缓冲区呢。关键在于四个字，”系统调用”！当读取OS内核缓冲区数据的时候，便发起了一次系统调用操作（通过native的C函数调用），而系统调用的代价相对来说是比较高的，涉及到进程用户态和内核态的上下文切换等一系列操作，所以我们经常采用如下的包装：

[java] view plain copy

01.FileInputStream in = new FileInputStream(“D:\java.txt”);

[java] view plain copy

01.BufferedInputStream buf_in = new BufferedInputStream(in);

[java] view plain copy

01.buf_in.read();

这样一来，我们每一次 buf_in.read() 时候，BufferedInputStream 会根据情况自动为我们预读更多的字节数据到它自己维护的一个内部字节数组缓冲区中，这样我们便可以减少系统调用次数，从而达到其缓冲区的目的。所以要明确的一点是 BufferedInputStream 的作用不是减少 磁盘IO操作次数（这个OS已经帮我们做了），而是通过减少系统调用次数来提高性能的。同理 BufferedOuputStream , BufferedReader/Writer 也是一样的。在 C语言的函数库中也有类似的实现，如 fread()，这个函数就是 C语言中的缓冲IO，作用与BufferedInputStream()相同.

这里简单的引用下JDK6 中 BufferedInputStream 的源码验证下：

[java] view plain copy

01.public
02.class BufferedInputStream extends FilterInputStream {
03.
04. private static int defaultBufferSize = 8192;
05.
06. /**
07. * The internal buffer array where the data is stored. When necessary,
08. * it may be replaced by another array of
09. * a different size.
10. */
11. protected volatile byte buf[];