参考原文: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();JAVA虚拟机内部便会调用OS底层的 read()系统调用完成操作,如上所述,在第二次调用 in.read()的时候可能就是从内核缓冲区直接返回数据了(可能还有经过 native堆做一次中转,因为这些函数都被声明为 native,即本地平台相关,所以可能在C代码中有做一次中转,如 win32中是通过 C代码从OS读取数据,然后再传给JVM内存)。既然如此,JAVA的IO包中为啥还要提供一个 BufferedInputStream 类来作为缓冲区呢。关键在于四个字,"系统调用"!当读取OS内核缓冲区数据的时候,便发起了一次系统调用操作(通过native的C函数调用),而系统 调用的代价相对来说是比较高的,涉及到进程用户态和内核态的上下文切换等一系列操作,所以我们经常采用如下的包装:
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中的通道操作相比性能上的优势,先看如下代码:
-
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)); } }
输出为 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: -
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++; } }发现在cap <= maxMemory - totalCapacity时,也就是分配的直接内存大小朝富哦最大直接内存的时候,会进行一次System.gc()调用。
若将上述测试代码中两次申请的内存不超过MaxDirectMemorySize设置的大小,就不会导致最大直接内存不够用,或许此时结论是不会发生FULL GC。需要注意的是调用System.gc()时未必立即去做GC,也未必会去做。
使用-XX:+DisableExplicitGC参数,那么系统就不会在System.gc()时做FULL G操作。(即使空间不足也不会去做),此时执行上例中代码
会报错:
Exception in thread "main" java.lang.OutOfMemoryError: Direct buffer memory
at java.nio.Bits.reserveMemory(Bits.java:658)
因此。
再看直接在JVM堆上分配内存区域的情况:
- public static void main(String[] args) {
- r(int i=0;i<10000;i++) {
- ByteBuffer.allocate(1024*100); //100K
- }
ByteBuffer.allocate 意味着直接在 JVM堆上分配内存,所以受 新生代的 Minor GC影响,输出如下:
[GC 16023K->224K(61312K), 0.0012432 secs]
[GC 16211K->192K(77376K), 0.0006917 secs]
[GC 32242K->176K(77376K), 0.0010613 secs]
[GC 32225K->224K(109504K), 0.0005539 secs]
[GC 64423K->192K(109504K), 0.0006151 secs]
[GC 64376K->192K(171392K), 0.0004968 secs]
[GC 128646K->204K(171392K), 0.0007423 secs]
[GC 128646K->204K(299968K), 0.0002067 secs]
[GC 257190K->204K(299968K), 0.0003862 secs]
[GC 257193K->204K(287680K), 0.0001718 secs]
[GC 245103K->204K(276480K), 0.0001994 secs]
[GC 233662K->204K(265344K), 0.0001828 secs]
[GC 222782K->172K(255232K), 0.0001998 secs]
[GC 212374K->172K(245120K), 0.0002217 secs]
可以看到,由于直接在 JVM堆上分配内存,所以触发了多次GC,且不会触及 Full GC,因为对象根本没机会进入老年代。
我想提个疑问,NIO中的DirectMemory和内存文件映射同属于直接缓冲区,但是前者和 -Xmx和-XX:MaxDirectMemorySize有关,而后者完全没有JVM参数可以影响和控制,这让我不禁怀疑两者的直接缓冲区是否相同,前 者指的是 JAVA进程中的 native堆,即涉及底层平台如 win32的dll 部分,因为 C语言中的 malloc()分配的内存就属于 native堆,不属于 JVM堆,这也是DirectMemory能在一些场景中显著提高性能的原因,因为它避免了在 native堆和jvm堆之间数据的来回复制;而后者则是没有经过 native堆,是由 JAVA进程直接建立起 某一段虚拟地址空间和文件对象的关联映射关系,参见 Linux虚拟存储器图中的 “Memory mapped region for shared libraries” 区域,所以内存映射文件的区域并不在JVM GC的回收范围内,因为它本身就不属于堆区,卸载这部分区域只能通过系统调用 unmap()来实现 (Linux)中,而 JAVA API 只提供了 FileChannel.map 的形式创建内存映射区域,却没有提供对应的 unmap(),让人十分费解,导致要卸载这部分区域比较麻烦。
最后再试试通过 DirectMemory来操作前面 内存映射和基本通道操作的例子,来看看直接内存操作的话,程序的性能如何:
- File file = new File("F:\\liq.pdf");
- FileInputStream in = new FileInputStream(file);
- FileChannel channel = in.getChannel();
- ByteBuffer buff = ByteBuffer.allocateDirect(1024);
- long begin = System.currentTimeMillis();
- while (channel.read(buff) != -1) {
- buff.flip();
- buff.clear();
- }
- long end = System.currentTimeMillis();
- System.out.println("time is:" + (end - begin));
程序输出为 312毫秒,看来比普通的NIO通道操作(468毫秒)来的快,但是比 mmap 内存映射的 63秒差距太多了,我想应该不至于吧,通过修改;ByteBuffer buff = ByteBuffer.allocateDirect(1024); 为 ByteBuffer buff = ByteBuffer.allocateDirect((int)file.length()),即一次性分配整个文件长度大小的堆外内存,最终输出为 78毫秒,由此可以得出两个结论:1.堆外内存的分配耗时比较大. 2.还是比mmap内存映射来得慢,都不要说通过mmap读取数据的时候还涉及缺页异常、页面调度的系统调用了,看来内存映射文件确实NB啊,这还只是 86M的文件,如果上 G 的大小呢?
最后一点为 DirectMemory的内存只有在 JVM执行 full gc 的时候才会被回收,那么如果在其上分配过大的内存空间,那么也将出现 OutofMemoryError,即便 JVM 堆中的很多内存处于空闲状态。
本来只想写点内存映射部分,但是写着写着涉及进来的知识多了点,边界不好把控啊。。。
尼玛,都是3月8号凌晨快2点了,不过想想总比以前玩 拳皇游戏 熬夜来的好吧,写完收工,赶紧睡觉去。。。
我想补充下额外的一个知识点,关于 JVM堆大小的设置是不受限于物理内存,而是受限于虚拟内存空间大小,理论上来说是进程的虚拟地址空间大小,但是实际上我们的虚拟内存空间是有限制的,一 般windows上默认在C盘,大小为物理内存的2倍左右。我做了个实验:我机子是 64位的win7,那么理论上说进程虚拟空间是几乎无限大,物理内存为4G,而我设置 -Xms5000M, 即在启动JAVA程序的时候一次性申请到超过物理内存大小的5000M内存,程序正常启动,而当我加到 -Xms8000M的时候就报OOM错误了,然后我修改增加 win7的虚拟内存,程序又正常启动了,说明 -Xms 受限于虚拟内存的大小。我设置-Xms5000M,即超过了4G物理内存,并在一个死循环中不断创建对象,并保证不会被GC回收。程序运行一会后整个电脑 几乎死机状态,即卡住了,反映很慢很慢,推测是发生了系统颠簸,即频繁的页面调度置换导致,说明 -Xms -Xmx不是局限于物理内存的大小,而是综合虚拟内存了,JVM会根据电脑虚拟内存的设置来控制。