Java中RandomAccessFile调用seek后写入速度极慢的原因是什么？

先看你的问题和测试代码：

使用Java的RandomAccessFile调用seek方法后执行写入操作速度非常慢，请问这是什么原因？测试代码如下：

long fileSize = 1024 * 1024 * 512L; 
byte[] bts = new byte[8]; 
RandomAccessFile randomAccessFile = new RandomAccessFile("f:/test.data", "rw"); 
randomAccessFile.setLength(fileSize); 
randomAccessFile.seek(0); 
long time = System.nanoTime(); 
randomAccessFile.write(bts); 
System.out.println("write1 use:" + (System.nanoTime() - time)); 
randomAccessFile.seek(1024 * 1024 * 256L); 
time = System.nanoTime(); 
randomAccessFile.write(bts); 
System.out.println("write2 use:" + (System.nanoTime() - time));

为什么seek后写入会变慢？ #

其实核心原因和磁盘IO的特性、文件的存储机制有关，分几点说：

1. 磁盘天生不擅长随机小写入 #

不管是机械硬盘（HDD）还是固态硬盘（SSD），随机读写的性能都远不如连续读写：

• 对于HDD来说，seek到文件中间位置需要磁头移动到对应的扇区，这个寻道过程耗时通常是毫秒级，而写入8字节的时间微乎其微，大部分时间都花在磁头定位上了。
• 即使是SSD，虽然没有磁头，但随机小IO的性能也比连续IO差不少，因为闪存的写入单元是按块来的，小写入需要先擦除再写入，额外开销大。

2. 文件空洞的分配开销 #

你用setLength(fileSize)直接把文件扩展到512MB，这时候文件里大部分区域是文件空洞——也就是操作系统只是记录了文件的大小，但并没有实际分配磁盘块。当你seek到空洞位置写入时，操作系统必须先为这个位置分配对应的磁盘块，这个分配过程会额外消耗时间，而开头的写入因为是从文件起始位置开始，可能已经预分配了部分块，所以速度更快。

3. 缓存机制的影响 #

操作系统和JVM都有IO缓存，第一次写入文件开头时，数据可能直接命中缓存，或者缓存的分配更高效；而seek到中间位置写入时，缓存无法命中，需要直接和磁盘硬件交互，这就进一步放大了两次写入的耗时差异。

可以怎么优化？ #

根据你的业务场景，给几个实用的优化方向：

• 尽量合并小IO，做连续写入：如果业务允许，把零散的小写入操作合并成大的连续写入，减少seek的次数，这是提升IO性能最有效的方式。
• 改用内存映射文件：用MappedByteBuffer（通过FileChannel.map获取）代替RandomAccessFile，它基于操作系统的内存映射机制，能大幅提升随机访问的性能，尤其是频繁小量随机写入的场景。
• 预填充文件：如果必须在大文件的随机位置写入，可以先提前用0填充整个文件，这样操作系统会提前分配好所有磁盘块，后续的随机写入就不会有额外的块分配开销了（不过预填充本身会耗时，适合写入操作非常频繁的场景）。
• 换用SSD：如果预算允许，把机械硬盘换成SSD，能显著提升随机IO的性能，从硬件层面解决问题。

内容的提问来源于stack exchange，提问作者liwei2633