`

JAVA NIO之内存映射文件与DirectMemory原理分析

java nio 
阅读更多

 

       参考原文：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();
 

 

       每一次read() 时候，BufferedInputStream 会根据情况自动为我们预读更多的字节数据到它自己维护的一个内部字节数组缓冲区中，这样我们便可以减少系统调用次数，从而达到其缓冲区的目的。所以要明确 的一点是 BufferedInputStream 的作用不是减少 磁盘IO操作次数（这个OS已经帮我们做了），而是通过减少系统调用次数来提高性能的。同理 BufferedOuputStream , BufferedReader/Writer 也是一样的。这里简单的引用下JDK8中 BufferedInputStream 的源码验证下：
 /**
     * See
     * the general contract of the <code>read</code>
     * method of <code>InputStream</code>.
     *
     * @return     the next byte of data, or <code>-1</code> if the end of the
     *             stream is reached.
     * @exception  IOException  if this input stream has been closed by
     *                          invoking its {@link #close()} method,
     *                          or an I/O error occurs.
     * @see        java.io.FilterInputStream#in
     */
    public synchronized int read() throws IOException {
        if (pos >= count) {
            fill();
            if (pos >= count)
                return -1;
        }
        return getBufIfOpen()[pos++] & 0xff;
    }
 
       我们可以看到，BufferedInputStream 内部维护着一个 字节数组 byte[] buf 来实现缓冲区的功能，我们调用的read() 方法在返回数据之前有做一个 if 判断，如果 buf 数组的当前索引不在有效的索引范围之内，即 if 条件成立， buf 字段维护的缓冲区已经不够了，这时候会调用 内部的 fill() 方法进行填充，而fill()会预读更多的数据到 buf 数组缓冲区中去，然后再返回当前字节数据，如果 if 条件不成立便直接从 buf缓冲区数组返回数据了。其中getBufIfOpen()返回的就是 buf字段的引用。顺便说下，源码中的 buf 字段声明为  protected volatile byte buf[];  主要是为了通过 volatile 关键字保证 buf数组在多线程并发环境中的内存可见性。

       内存映射文件和之前说的标准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中的通道操作相比性能上的优势，先看如下代码：

  1. 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:
  2. 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();
        }
    }
}
  1.  
    1. 运行结果：

      copyFileByMappedByteBuffer cost 1825ms

      copyFileByDirectByteBuffer cost 34188ms

    2. 通过设置 JVM参数 -Xmx64M -Xmn10M，即JVM最大堆为64M，然后执行以下程序可以证明DirectMemory不受JVM堆大小控制：
    3. 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

  2. ByteBuffer.allocateDirect(1024 * 1024 * 200);
ByteBuffer.allocateDirect(1024 * 1024 * 1);
  4. 输出结果如下：
  5. [GC (System.gc())  1803K->880K(64512K), 0.0014972 secs]
  6. [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堆上分配内存区域的情况：

 

[java] view plaincopyprint?
  1. public static void main(String[] args) {         
  2. r(int i=0;i<10000;i++) {  
  3.           ByteBuffer.allocate(1024*100);  //100K  
  4.   
  5. }  


  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来操作前面 内存映射和基本通道操作的例子，来看看直接内存操作的话，程序的性能如何：

   

[java] view plaincopyprint?
  1.              File file = new File("F:\\liq.pdf");  
  2. FileInputStream in = new FileInputStream(file);  
  3. FileChannel channel = in.getChannel();  
  4. ByteBuffer buff = ByteBuffer.allocateDirect(1024);   
  5.   
  6. long begin = System.currentTimeMillis();  
  7. while (channel.read(buff) != -1) {  
  8.     buff.flip();  
  9.     buff.clear();  
  10. }  
  11. long end = System.currentTimeMillis();  
  12. 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会根据电脑虚拟内存的设置来控制。

 

分享到：
java中对象的equals()方法和hashCode()方法
评论
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

    Java NIO 应用使用内存映射文件实现进程间通信

    在Java NIO中，内存映射文件（MappedByteBuffer）是一个重要的特性，它允许将文件直接映射到内存中，以便于快速访问和修改文件内容。这一特性不仅提高了读写效率，而且还能用于进程间通信（IPC）。 内存映射文件的...

    java nio 包读取超大数据文件

    在Java NIO中，处理超大数据文件的关键在于合理利用内存映射文件（Memory-Mapped Files）来提高读取效率。内存映射文件是一种将文件内容直接映射到内存中的技术，使得对文件的操作如同操作内存一样简单高效。下面...

    java nio 写文件

    通过`FileChannel.map()`方法，可以直接将文件映射到内存中，这样读写文件就像操作内存一样快速。但需要注意的是，内存映射文件可能会消耗大量内存，因此对于大文件操作要谨慎使用。 5. **选择器（Selectors）** ...

    java NIO.zip

    6. **内存映射文件（Memory-Mapped Files）**： NIO允许将文件直接映射到内存，使得读写文件就像操作普通缓冲区一样快速。通过MappedByteBuffer类，可以直接在内存中对文件进行操作，提高大文件处理的性能。 7. **...

    java NIO实例

    4. **FileChannel**：用于文件的读写，可以实现大文件的高效传输，支持内存映射（Mmap）技术，能直接将文件映射到内存中。 5. **SocketChannel**：用于网络通信，可以建立TCP连接，进行非阻塞的读写。在`NIOServer....

    Java NIO原理分析及代码实例

    Java NIO提供了FileChannel用于文件操作，支持随机访问，可以进行文件的读写、映射到内存、文件大小的改变等操作。与标准IO相比，NIO的文件操作更高效且功能更强大。 5. **管道（Pipe）** 管道是两个线程间通信的...

    Large-File-Processing-master_javanio_java大文件处理_

    3. **内存映射文件（Memory-Mapped Files）**：Java NIO提供了一个特殊的功能，即内存映射文件，它可以将文件直接映射到内存中，使得文件操作如同访问内存一样快速。对于大文件处理，内存映射文件是一种高效的策略，...

    java nio 读文件

    Java NIO（New IO）是Java 1.4版本引入的一个新模块，它提供了一种不同于标准Java IO API的处理I/O操作的方式。NIO的主要特点是面向缓冲区，非阻塞I/O，以及选择器，这些特性使得NIO在处理大量并发连接时表现出更高...

    java NIO技巧及原理

    Java NIO（New Input/Output）是Java标准库提供的一种I/O模型，它与传统的 Blocking I/O（IO）相比，提供了更加高效的数据传输方式。在Java NIO中，"新"主要体现在非阻塞和多路复用这两个特性上，这使得NIO更适合于...

    java NIO和java并发编程的书籍

    java NIO和java并发编程的书籍java NIO和java并发编程的书籍java NIO和java并发编程的书籍java NIO和java并发编程的书籍java NIO和java并发编程的书籍java NIO和java并发编程的书籍java NIO和java并发编程的书籍java...

    NIO与零拷贝_javanio_nio和零拷贝_

    在Java NIO中，零拷贝主要体现在通过DMA（Direct Memory Access，直接内存访问）和操作系统内核层面的优化来实现。 1. **NIO基础** - **通道（Channels）**：通道类似于流，但它是双向的，可以读也可以写。常见的...

    Java NIO英文高清原版

    4. **文件通道（File Channel）**：文件通道是直接与文件系统交互的通道，支持映射文件到内存（Memory-Mapped File）进行高速读写。 5. **网络通道（Network Channels）**：如SocketChannel和ServerSocketChannel，...

    java NIO 写文件

    4. **内存映射文件**：`MappedByteBuffer`允许将文件直接映射到内存，提供了极高的读写速度。 然而，尽管Java NIO提供了很多优势，但在实际使用中，开发者还需要注意一些潜在的问题，如内存管理（缓冲区过大可能...

    JavaNIO chm帮助文档

    Java NIO系列教程（一） Java NIO 概述 Java NIO系列教程（二） Channel Java NIO系列教程（三） Buffer Java NIO系列教程（四） Scatter/Gather Java NIO系列教程（五） 通道...Java NIO系列教程（十二） Java NIO与IO

    JAVA NIO 简单PFT 文件服务

    PFT（可能指的是文件传输或处理服务）在本场景中可能是通过JAVA NIO实现的一个功能模块，用于提供文件的上传、下载和列表展示服务。 文件服务是任何应用程序中不可或缺的部分，尤其是在Web环境中。在JAVA NIO中，...

    java 深入理解内存映射文件原理

    通过FileChannel的map()方法，可以将文件映射到内存，从而提高大文件处理的性能。例如，以下代码展示了如何使用内存映射文件读取10MB的数据： ```java FileChannel fc = FileChannel.open(Paths.get("./largeFile....

    Java NIO测试示例

    使用MappedByteBuffer，NIO可以将文件映射到内存，使得文件操作如同操作内存一样快速，特别适合大数据处理。 在实际应用中，Java NIO通常用于高性能的服务器编程，例如在开发聊天服务器、Web服务器或游戏服务器时...

    java NIO原理和使用

    ### Java NIO 原理与使用详解 #### 一、Java NIO 概述 在深入了解 Java NIO 的工作原理及其使用之前，我们首先来了解一下什么是 Java NIO（New I/O）。Java NIO 是 Java SE 1.4 版本引入的一个全新的 I/O API，...

    Java NIO原理 图文分析及代码实现

    ### Java NIO原理 图文分析及代码实现 #### 前言 在深入探讨Java NIO之前，我们先简要回顾一下NIO的概念及其引入的原因。随着互联网的发展，越来越多的应用程序需要处理高并发的网络连接请求。传统的阻塞I/O模型在...

Magicbox
Global site tag (gtag.js) - Google Analytics