参考原文：http://www.360doc.com/content/13/0502/23/7669533_282552666.shtml
JAVA类库中的NIO包相对于IO 包来说有一个新功能是内存映射文件，日常编程中并不是经常用到，但是在处理大文件时是比较理想的提高效率的手段。 在传统的文件IO操作中，我们都是调用操作系统提供的底层标准IO系统调用函数 read()、write() ，此时调用此函数的进程（在JAVA中即java进程）由当前的用户态切换到内核态，然后OS的内核代码负责将相应的文件数据读取到内核的IO缓冲区，然后再把数据从内核IO缓冲区拷贝到进程的私有地址空间中去，这样便完成了一次IO操作。为什么要多此一举搞一个内核IO缓冲区把原本只需一次拷贝数据的事情搞成需要2次数据拷贝呢？ 我想学过操作系统或者计算机系统结构的人都知道，这么做是为了减少磁盘的IO操作，为了提高性能而考虑的，因为我们的程序访问一般都带有局部性，也就是所谓的局部性原理，在这里主要是指的空间局部性，即我们访问了文件的某一段数据，那么接下去很可能还会访问接下去的一段数据，由于磁盘IO操作的速度比直接访问内存慢了好几个数量级，所以OS根据局部性原理会在一次 read()系统调用过程中预读更多的文件数据缓存在内核IO缓冲区中，当继续访问的文件数据在缓冲区中时便直接拷贝数据到进程私有空间，避免了再次的低效率磁盘IO操作。在JAVA中当我们采用IO包下的文件操作流，例如：
FileInputStream fileInputStream = new FileInputStream("D:\\Warcraft III.zip");
int read = fileInputStream.read();
FileInputStream fileInputStream = new FileInputStream("D:\\Warcraft III.zip");
BufferedInputStream bufferedInputStream = new BufferedInputStream(fileInputStream);
int read = bufferedInputStream.read();
内存映射文件和之前说的标准IO操作最大的不同之处就在于它虽然最终也是要从磁盘读取数据，但是它并不需要将数据读取到OS内核缓冲区，而是直接将进程的用户私有地址空间中的一 部分区域与文件对象建立起映射关系，就好像直接从内存中读、写文件一样，速度当然快了。为了说清楚这个，我们以 Linux操作系统为例子，看下图：
此图为 Linux 2.X 中的进程虚拟存储器，即进程的虚拟地址空间，如果你的机子是 32 位，那么就有 2^32 = 4G的虚拟地址空间，我们可以看到图中有一块区域： “Memory mapped region for shared libraries” ，这段区域就是在内存映射文件的时候将某一段的虚拟地址和文件对象的某一部分建立起映射关系，此时并没有拷贝数据到内存中去，而是当进程代码第一次引用这 段代码内的虚拟地址时，触发了缺页异常，这时候OS根据映射关系直接将文件的相关部分数据拷贝到进程的用户私有空间中去，当有操作第N页数据的时候重复这 样的OS页面调度程序操作。注意啦，原来内存映射文件的效率比标准IO高的重要原因就是因为少了把数据拷贝到OS内核缓冲区这一步（可能还少了 native堆中转这一步）。
java中提供了3种内存映射模式，即：只读(readonly)、读写(read_write)、专用(private) ，对于 只读模式来说，如果程序试图进行写操作，则会抛出ReadOnlyBufferException异 常；第二种的读写模式表明了通过内存映射文件的方式写或修改文件内容的话是会立刻反映到磁盘文件中去的，别的进程如果共享了同一个映射文件，那么也会立即 看到变化！而不是像标准IO那样每个进程有各自的内核缓冲区，比如JAVA代码中，没有执行 IO输出流的 flush() 或者 close() 操作，那么对文件的修改不会更新到磁盘去，除非进程运行结束；最后一种专用模式采用的是OS的“写时拷贝”原则，即在没有发生写操作的情况下，多个进程之 间都是共享文件的同一块物理内存（进程各自的虚拟地址指向同一片物理地址），一旦某个进程进行写操作，那么将会把受影响的文件数据单独拷贝一份到进程的私 有缓冲区中，不会反映到物理文件中去。
/**
* Mode for a read-only mapping.
*/
public static final MapMode READ_ONLY
= new MapMode("READ_ONLY");
/**
* Mode for a read/write mapping.
*/
public static final MapMode READ_WRITE
= new MapMode("READ_WRITE");
/**
* Mode for a private (copy-on-write) mapping.
*/
public static final MapMode PRIVATE
= new MapMode("PRIVATE");
在JAVA NIO中可以很容易的创建一块内存映射区域，代码如下：
File file = new File("E:\\download\\office2007pro.chs.ISO");
FileInputStream in = new FileInputStream(file);
FileChannel channel = in.getChannel();
MappedByteBuffer buff = channel.map(FileChannel.MapMode.READ_ONLY, 0,channel.size());
这里创建了一个只读模式的内存映射文件区域，接下来我就来测试下与普通NIO中的通道操作相比性能上的优势，先看如下代码：
-
输出为 618毫秒，即通过内存映射文件的方式读取1.86GB大小的文件只需要618毫秒，而改为普通NIO的通道操作看下输出为 5683毫秒，几乎是 9 倍的差距。文件越大，差距便越大。所以内存映射文件特别适合于对大文件的操作，JAVA中的限制是最大不得超过 Integer.MAX_VALUE，即2G左右，不过我们可以通过分次映射文件(channel.map)的不同部分来达到操作整个文件的目的。 按照jdk文档的官方说法，内存映射文件属于JVM中的直接缓冲区，还可以通过 ByteBuffer.allocateDirect() ，即DirectMemory的方式来创建直接缓冲区。他们相比基础的 IO操作来说就是少了中间缓冲区的数据拷贝开销。同时他们属于JVM堆外内存，不受JVM堆内存大小的限制。 其中 DirectMemory 默认的大小是等同于JVM最大堆减去一个SURVIVOR区域的值，理论上说受限于进程的虚拟地址空间大小，比如 32位的windows上，每个进程有4G的虚拟空间除去 2G为OS内核保留外，再减去 JVM堆的最大值，剩余的才是DirectMemory大小。再看一个实例用内存映射文件和directBuffer进行文件copy:package org.apache.commons.csv; import java.io.File; import java.io.FileInputStream; import java.io.IOException; import java.nio.ByteBuffer; import java.nio.MappedByteBuffer; import java.nio.channels.FileChannel; public class IOTest { static final int BUFFER_SIZE = 1024; public static void main(String[] args) throws Exception { String pathname = "D:\\Warcraft III.zip"; readByMappedByteBuffer(pathname); readByByteBuffer(pathname); } private static void readByMappedByteBuffer(String pathname) throws IOException { long begin = System.currentTimeMillis(); File file = new File(pathname); FileInputStream in = new FileInputStream(file); FileChannel channel = in.getChannel(); System.out.println(channel.size()); MappedByteBuffer buff = channel.map(FileChannel.MapMode.READ_ONLY, 0, channel.size()); byte[] b = new byte[1024]; int len = (int) file.length(); for (int offset = 0; offset < len; offset += 1024) { if (len - offset > BUFFER_SIZE) { buff.get(b); } else { buff.get(new byte[len - offset]); } } long end = System.currentTimeMillis(); System.out.println("time is:" + (end - begin)); } private static void readByByteBuffer(String pathname) throws IOException { long begin = System.currentTimeMillis(); File file = new File(pathname); FileInputStream in = new FileInputStream(file); FileChannel channel = in.getChannel(); ByteBuffer buff = ByteBuffer.allocate(1024); while (channel.read(buff) != -1) { buff.flip(); buff.clear(); } long end = System.currentTimeMillis(); System.out.println("time is:" + (end - begin)); } } -
import sun.nio.ch.DirectBuffer; import java.io.IOException; import java.io.RandomAccessFile; import java.nio.ByteBuffer; import java.nio.MappedByteBuffer; import java.nio.channels.FileChannel; /** * Created by Administrator on 2015/4/15. */ public class Test { public static final long COPY_FILE_ZIE = 1024 * 1024 * 1000; public static void main(String[] args) throws IOException { long start = System.currentTimeMillis(); copyFileByMappedByteBuffer("D:\\Warcraft III.zip", "E:\\copy_of_Warcraft III.zip"); System.out.println("copyFileByMappedByteBuffer cost " + (System.currentTimeMillis() - start) + "ms"); start = System.currentTimeMillis(); copyFileByByteBuffer("D:\\Warcraft III.zip", "E:\\copy_of_Warcraft III.zip", ByteBuffer.allocateDirect(1024 * 1024 * 100), true); System.out.println("copyFileByDirectByteBuffer cost " + (System.currentTimeMillis() - start) + "ms"); } private static void copyFileByMappedByteBuffer(String srcFileName, String destFileName) throws IOException { FileChannel inFileChannel = null; FileChannel outFileChannel = null; MappedByteBuffer mappedByteBuffer = null; try { inFileChannel = new RandomAccessFile(srcFileName, "r").getChannel(); outFileChannel = new RandomAccessFile(destFileName, "rw").getChannel(); long fileSize = inFileChannel.size(); long position = 0; while (position < fileSize) { long copyFileSize = Math.min(fileSize - position, COPY_FILE_ZIE); mappedByteBuffer = outFileChannel.map(FileChannel.MapMode.READ_WRITE, position, copyFileSize); inFileChannel.read(mappedByteBuffer); position += mappedByteBuffer.position(); } } finally { closeStream(inFileChannel, outFileChannel); if (mappedByteBuffer != null) { ((DirectBuffer) mappedByteBuffer).cleaner().clean(); } } } private static void copyFileByByteBuffer(String srcFileName, String destFileName, ByteBuffer byteBuffer, boolean cleanDirectBuffer) throws IOException { FileChannel inFileChannel = null; FileChannel outFileChannel = null; try { inFileChannel = new RandomAccessFile(srcFileName, "r").getChannel(); outFileChannel = new RandomAccessFile(destFileName, "rw").getChannel(); int size = inFileChannel.read(byteBuffer); while (size > 0) { byteBuffer.flip(); outFileChannel.write(byteBuffer); byteBuffer.clear(); size = inFileChannel.read(byteBuffer); } } finally { closeStream(inFileChannel, outFileChannel); if (byteBuffer.isDirect() && cleanDirectBuffer) { ((DirectBuffer) byteBuffer).cleaner().clean(); } } } private static void closeStream(FileChannel inFileChannel, FileChannel outFileChannel) throws IOException { if (inFileChannel != null) { inFileChannel.close(); } if (outFileChannel != null) { outFileChannel.close(); } } }
-
- 运行结果：
copyFileByMappedByteBuffer cost 1825ms
copyFileByDirectByteBuffer cost 34188ms
- 通过设置 JVM参数 -Xmx64M -Xmn10M，即JVM最大堆为64M，然后执行以下程序可以证明DirectMemory不受JVM堆大小控制：
-
ByteBuffer.allocateDirect(1024 * 1024 * 64); // 64MB
我们设置了JVM堆 最大值为64M限制，其中年轻带大小为10M，然后在 直接内存上分配了64MB空间，程序执行后直接报错：Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory。然后修改为分配63M（由于年轻代为10M,一个SURVIVOR占用1M）的空间成功。然后我修改配置： -Xmx64M -XX:MaxDirectMemorySize=200M，分配一个200M空间成功。因此得出结论： 直接内存DirectMemory的大小默认为 -Xmx 的JVM堆的最大值减去一个survivor区域值，但是并不受其限制，而是由JVM参数 MaxDirectMemorySize单独控制。接下来我们来证明直接内存不是分配在JVM堆中。我们先执行以下程序，并设置 JVM参数 -Xmx64M -Xmn10M -XX:MaxDirectMemorySize=200M -XX:+PrintGCDetails
- 运行结果：
-
ByteBuffer.allocateDirect(1024 * 1024 * 200); ByteBuffer.allocateDirect(1024 * 1024 * 1); - 输出结果如下：
- [GC (System.gc()) 1803K->880K(64512K), 0.0014972 secs]
- [Full GC (System.gc()) 880K->765K(64512K), 0.0070394 secs]
此时看到JVM发生了一次FULL GC。后面跟着System.gc()，说明这次FULL GC是由System.gc()发起的。查看DirectBuffer源码在其构造函数中间接调用了java.nio.Bits类的reserveMemory方法。
// These methods should be called whenever direct memory is allocated or
// freed. They allow the user to control the amount of direct memory
// which a process may access. All sizes are specified in bytes.
static void reserveMemory(long size, int cap) {
synchronized (Bits.class) {
if (!memoryLimitSet && VM.isBooted()) {
maxMemory = VM.maxDirectMemory();
memoryLimitSet = true;
}
// -XX:MaxDirectMemorySize limits the total capacity rather than the
// actual memory usage, which will differ when buffers are page
// aligned.
if (cap <= maxMemory - totalCapacity) {
reservedMemory += size;
totalCapacity += cap;
count++;
return;
}
}
System.gc();
try {
Thread.sleep(100);
} catch (InterruptedException x) {
// Restore interrupt status
Thread.currentThread().interrupt();
}
synchronized (Bits.class) {
if (totalCapacity + cap > maxMemory)
throw new OutOfMemoryError("Direct buffer memory");
reservedMemory += size;
totalCapacity += cap;
count++;
}
}