java nio bytebuffer文件读写问题

JDK1.4以后就提供java.nio的包，nio主要提供字节与字符的映射、内存映射文件和文件加锁机制

其中内存映射文件在键陪读取大文件时可能会用上，因为内存映射不是直接把文件加载到JVM内存空间

而是借用 *** 作系统对文件的读取，这经历了由当前Java态进入到 *** 作咐亮枝系统内核态，再由 *** 作系统读取文件，

并返回数据到当前Java态的过程。由Java态进入 *** 作系统内核态离不开nio包中两个重要的类

FileChannel 和 ByteBuffer。FileChannel表示文件通道，可以从FileInputStream、FileOutputStream

以及RandomAccessFile对象获取文件通道，你可以从文件通道直接读取文件，衡敏也可以使用“内存映射”

即使用通道，将文件内存映射到ByteBuffer，可以映射一部分内容，也可以映射全部内容，使用内存映射

能大幅提高我们 *** 作大文件的速度

FileChannel 和 ByteBuffer文件读取

[java] view plain copy

package nio

import java.io.BufferedInputStream

import java.io.File

import java.io.FileInputStream

import java.io.IOException

import java.io.RandomAccessFile

import java.nio.ByteBuffer

import java.nio.MappedByteBuffer

import java.nio.channels.FileChannel

import java.nio.channels.FileChannel.MapMode

/**

*

* Channel类似与流,数据可以从Channel读取到Buffer,也可以从Buffer写入到Channel

* 但通道和流还是有区别,比如流只能是单向读或写,而通道可以异步读写

*

* @author yli

*/

public class FileChannelTest {

可参考： MappedByteBuffer以及ByteBufer的底层原理

Bytebuffer分为两种：间接地和直接的，所谓直接就是指MappedByteBuffer，直接使用内存映射（java的话就意味着在JVM之外分配虚拟地址空间）；而间接的ByteBuffer是在JVM的堆上面的。间接缓冲区就是我们通常说的堆缓冲区。

直接缓冲区 java内部是使用 DirectByteBuffer 来实现的。

堆缓冲区java内部是使用 HeapByteBuffer 来实现的。

映射的字节缓冲区(MappedByteBuffer ) 不提供关闭或销毁方法。也就是说，创建完直接缓冲区，就一直有效，直到缓冲区本身被垃圾收集。

映射字节缓冲区的内容可以在任何时间改变，例如，如果映射的文件的对应区域的内容由该程序或其他程序改变。无论这种变化是否发生，当它们发生时，都是依赖于 *** 作系统的，因此不明确。

映射的字节缓冲区的全部或部分可能在任何时间变得不可访问，例如映射的文件被截断。试图访问映射字节缓冲区的不可访问区域不会改变缓冲区的内容，并且会导致在访问时或稍后某个时间抛出一个未指定桥行饥的异常。因此，强烈建议采取适当的预防措施，以避免由该程序或由同时运行的程序 *** 纵映射文件，除了读取或写入文件的内容。

MappedByteBuffer 继承了 ByteBuffer 。

load( )方法会整个文件加载到内存中。

此方法尽最大努力确保当它返回时，该缓冲区的内容驻留在物理内存中。调用此方法可能会导致一些页面错误和I/O *** 作发生。

*** 作系统会采用虚拟内存映射，把缓冲区和文件建立虚拟内存映射。此映射使得 *** 作系统的底层虚拟内存子系统可以根据需要将文件中相应区块的数据读进内存。带猛已经在内存中或通过验证的页会占用实际内存空间，并且在它们被读进 RAM 时会挤出最近较少使用的其他内存页。（swap in，swap out）

在一个映射缓冲区上调用 load( )方法会是一个代价高的 *** 作，因为它会导致大量的页调入（page-in），具体数量取决于文件中被映射区域的实际大小。然而，load( )方法返回并不能保证文件就会完全加载到内存，这是由于请求页面调入是动态的。具体结果会因某些因素而有所差异，这些因素包括： *** 作系统、文件系统，可用 Java 虚拟机内存，最大 Java 虚拟机内存，垃圾收集器实现过程等等。

请小心使用 load( )方法，它可能会导致您不希望出现的结果。该方法的主要作用是为提前加载文件埋单，以便后续的访问速度可以尽可能的快。

对于那些要求近乎实时访问的程序，解决方案就是预加载。但是请记住，不能保证全部页都加载到内存，不管怎样，之后可能还会有页调入发生（ *** 作系统自己维护，依赖 *** 作系统的实现）。内存页什么时候swap in 和 swap out 受多个因素影响，这些因素中的许多都是不受 Java 虚拟机控制的。

JDK 1.4 的 NIO 并没有提供一个可以把页面固定到物理内存上的API，尽管一些 *** 作系统是支持这样做的。对于大多数程序，特别是交互性的或其他事件驱动（event-driven）的程序而言，为提前加载文件消耗资源是不划算的。在实际访问时分摊页调入开销才是更好的选择。让 *** 作系统根据需要来调入页意味着不访问的页永远不需要被加载。同预加载整个被映射的文件相比，这很容易减少 I/O 活动总次数。 *** 作系统已经有一个复杂的内存管理系统了，就让它来替您完成此工作吧！

我们可以通过调用 isLoaded( )方法来判断一个被映射的文件是否完全加载内存了。

如果该方法返回ture，意味着该缓冲区中的所有数据很可能完全加载到物理内存中了，因此可以在不产生任何虚拟内存页错误或I/O *** 作的情况下访问。

不过，该方法返回false，并不一定意味着缓冲区的内容没有加载到物理内存中。

返回值是一个提示，而不是一个保证，因为底层 *** 作系统在调用该方法返回的时候可能已经分出了一些缓冲区的数据。

该敏返方法会强制将此缓冲区上的任何更改写入映射到永久磁盘存储器上。

如果映射到该缓冲区的文件驻留在本地存储设备上，那么当该方法返回时，它保证对创建的缓冲区进行的所有更改，或者自上次调用该方法后，将被写入该设备。

如果文件不驻留在本地设备上，则不提供这样的保证。

当用 MappedByteBuffer 对象来更新一个文件，您应该总是使用 MappedByteBuffer.force( )而非 FileChannel.force( )，因为通道对象可能

不清楚通过映射缓冲区做出的文件的全部更改。MappedByteBuffer 没有不更新文件元数据的选项——元数据总是会同时被更新的。

如果映射是以 MapMode.READ_ONLY 或 MAP_MODE.PRIVATE 模式建立的，那么调用 force( )

方法将不起任何作用，因为永远不会有更改需要应用到磁盘上（但是这样做也是没有害处的）。

喜欢本文的朋友们，欢迎长按下图关注订阅号 java404 ，收听更多精彩的内容

---