本篇内容介绍了“文件IO操作的方法是什么”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

创新互联专注于保康企业网站建设,响应式网站开发,商城网站定制开发。保康网站建设公司,为保康等地区提供建站服务。全流程按需定制网站，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务

已经过去的中间件性能挑战赛，和正在进行中的 第一届 PolarDB 数据性能大赛 都涉及到了文件操作，合理地设计架构以及正确地压榨机器的读写性能成了比赛中获取较好成绩的关键。正在参赛的我收到了几位公众号读者朋友的反馈，他们大多表达出了这样的烦恼：“对比赛很感兴趣，但不知道怎么入门”，“能跑出成绩，但相比前排的选手，成绩相差10倍有余”…为了能让更多的读者参与到之后相类似的比赛中来，我简单整理一些文件IO操作的最佳实践，而不涉及整体系统的架构设计，希望通过这篇文章的介绍，让你能够欢快地参与到之后类似的性能挑战赛之中来。

本文主要关注的 Java 相关的文件操作，理解它们需要一些前置条件，比如 PageCache，Mmap(内存映射)，DirectByteBuffer(堆外缓存)，顺序读写，随机读写...不一定需要完全理解，但至少知道它们是个啥，因为本文将会主要围绕这些知识点来展开描述。

首先，文件IO类型的比赛最重要的一点，就是选择好读写文件的方式，那 JAVA 中文件IO有多少种呢？原生的读写方式大概可以被分为三种：普通IO，FileChannel(文件通道)，MMAP(内存映射)。区分他们也很简单，例如 FileWriter,FileReader 存在于 java.io 包中，他们属于普通IO；FileChannel 存在于 java.nio 包中，属于 NIO 的一种，但是注意 NIO 并不一定意味着非阻塞，这里的 FileChannel 就是阻塞的；较为特殊的是后者 MMAP，它是由 FileChannel 调用 map 方法衍生出来的一种特殊读写文件的方式，被称之为内存映射。

使用 FIleChannel 的方式：

FileChannel fileChannel = new RandomAccessFile(new File("db.data"), "rw").getChannel();

获取 MMAP 的方式：

MappedByteBuffer mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, filechannel.size();

MappedByteBuffer 便是 JAVA 中 MMAP 的操作类。

面向于字节传输的传统 IO 方式遭到了我们的唾弃，我们重点探讨 FileChannel 和 MMAP 这两种读写方式的区别。

// 写byte[] data = new byte[4096];long position = 1024L;//指定 position 写入 4kb 的数据fileChannel.write(ByteBuffer.wrap(data), position);//从当前文件指针的位置写入 4kb 的数据fileChannel.write(ByteBuffer.wrap(data));// 读ByteBuffer buffer = ByteBuffer.allocate(4096);long position = 1024L;//指定 position 读取 4kb 的数据fileChannel.read(buffer,position)；//从当前文件指针的位置读取 4kb 的数据fileChannel.read(buffer);

FileChannel 大多数时候是和 ByteBuffer 这个类打交道，你可以将它理解为一个 byte[] 的封装类，提供了丰富的 API 去操作字节，不了解的同学可以去熟悉下它的 API。值得一提的是，write 和 read 方法均是线程安全的，FileChannel 内部通过一把 privatefinalObjectpositionLock=newObject(); 锁来控制并发。

FileChannel 为什么比普通 IO 要快呢？这么说可能不严谨，因为你要用对它，FileChannel 只有在一次写入 4kb 的整数倍时，才能发挥出实际的性能，这得益于 FileChannel 采用了 ByteBuffer 这样的内存缓冲区，让我们可以非常精准的控制写盘的大小，这是普通 IO 无法实现的。4kb 一定快吗？也不严谨，这主要取决你机器的磁盘结构，并且受到操作系统，文件系统，CPU 的影响，例如中间件性能挑战赛时的那块盘，一次至少写入 64kb 才能发挥出最高的 IOPS。

然而 PolarDB 这块盘就完全不一样了，可谓是异常彪悍，具体是如何的表现由于比赛仍在进行中，不予深究，但凭借着 benchmark everyting 的技巧，我们完全可以测出来。

另外一点，成就了 FileChannel 的高效，介绍这点之前，我想做一个提问：FileChannel 是直接把 ByteBuffer 中的数据写入到磁盘吗？思考几秒…答案是：NO。ByteBuffer 中的数据和磁盘中的数据还隔了一层，这一层便是 PageCache，是用户内存和磁盘之间的一层缓存。我们都知道磁盘 IO 和内存 IO 的速度可是相差了好几个数量级。我们可以认为 filechannel.write 写入 PageCache 便是完成了落盘操作，但实际上，操作系统最终帮我们完成了 PageCache 到磁盘的最终写入，理解了这个概念，你就应该能够理解 FileChannel 为什么提供了一个 force() 方法，用于通知操作系统进行及时的刷盘。

同理，当我们使用 FileChannel 进行读操作时，同样经历了：磁盘->PageCache->用户内存这三个阶段，对于日常使用者而言，你可以忽略掉 PageCache，但作为挑战者参赛，PageCache 在调优过程中是万万不能忽视的，关于读操作这里不做过多的介绍，我们在下面的小结中还会再次提及，这里当做是引出 PageCache 的概念。

// 写byte[] data = new byte[4];int position = 8;//从当前 mmap 指针的位置写入 4b 的数据mappedByteBuffer.put(data);//指定 position 写入 4b 的数据MappedByteBuffer subBuffer = mappedByteBuffer.slice();subBuffer.position(position);subBuffer.put(data);// 读byte[] data = new byte[4];int position = 8;//从当前 mmap 指针的位置读取 4b 的数据mappedByteBuffer.get(data)；//指定 position 读取 4b 的数据MappedByteBuffer subBuffer = mappedByteBuffer.slice();subBuffer.position(position);subBuffer.get(data);

FileChannel 已经足够强大了，MappedByteBuffer 还能玩出什么花来呢？请容许我卖个关子先，先介绍一下 MappedByteBuffer 的使用注意点。

当我们执行 fileChannel.map(FileChannel.MapMode.READ_WRITE,0,1.5*1024*1024*1024); 之后，观察一下磁盘上的变化，会立刻获得一个 1.5G 的文件，但此时文件的内容全部是 0（字节 0）。这符合 MMAP 的中文描述：内存映射文件，我们之后对内存中 MappedByteBuffer 做的任何操作，都会被最终映射到文件之中，

mmap 把文件映射到用户空间里的虚拟内存，省去了从内核缓冲区复制到用户空间的过程，文件中的位置在虚拟内存中有了对应的地址，可以像操作内存一样操作这个文件，相当于已经把整个文件放入内存，但在真正使用到这些数据前却不会消耗物理内存，也不会有读写磁盘的操作，只有真正使用这些数据时，也就是图像准备渲染在屏幕上时，虚拟内存管理系统 VMS 才根据缺页加载的机制从磁盘加载对应的数据块到物理内存进行渲染。这样的文件读写文件方式少了数据从内核缓存到用户空间的拷贝，效率很高

看了稍微官方一点的描述，你可能对 MMAP 有了些许的好奇，有这么厉害的黑科技存在的话，还有 FileChannel 存在的意义吗！并且网上很多文章都在说，MMAP 操作大文件性能比 FileChannel 搞出一个数量级！然而，通过我比赛的认识，MMAP 并非是文件 IO 的银弹，它只有在一次写入很小量数据的场景下才能表现出比 FileChannel 稍微优异的性能。紧接着我还要告诉你一些令你沮丧的事，至少在 JAVA 中使用 MappedByteBuffer 是一件非常麻烦并且痛苦的事，主要表现为三点：

1. MMAP 使用时必须实现指定好内存映射的大小，并且一次 map 的大小限制在 1.5G 左右，重复 map 又会带来虚拟内存的回收、重新分配的问题，对于文件不确定大小的情形实在是太不友好了。

2. MMAP 使用的是虚拟内存，和 PageCache 一样是由操作系统来控制刷盘的，虽然可以通过 force() 来手动控制，但这个时间把握不好，在小内存场景下会很令人头疼。

3. MMAP 的回收问题，当 MappedByteBuffer 不再需要时，可以手动释放占用的虚拟内存，但…方式非常的诡异。

public static void clean(MappedByteBuffer mappedByteBuffer) {    ByteBuffer buffer = mappedByteBuffer;    if (buffer == null || !buffer.isDirect() || buffer.capacity() == 0)        return;    invoke(invoke(viewed(buffer), "cleaner"), "clean");}private static Object invoke(final Object target, final String methodName, final Class... args) {    return AccessController.doPrivileged(new PrivilegedAction