randomaccessfile 不能直接保证毫秒级多点定位，但它是 java 中唯一支持直接字节偏移 seek() 的内置类；实际延迟取决于磁盘类型（nvme ssd 常态 0.1–0.8ms，hdd 达 5–20ms）、缓存命中率及 page fault。
RandomAccessFile 能否支撑毫秒级多点定位？
不能直接保证毫秒级，但它是 Java 中唯一能绕过流式缓冲、直接 seek() 到任意字节偏移的内置类。真正决定延迟的是磁盘 I/O 类型（SSD vs HDD）、文件系统缓存命中率、以及是否触发 page fault。实测在 NVMe SSD + 16KB 随机读场景下，单次 seek() + read() 常态耗时 0.1–0.8ms；HDD 上可能飙到 5–20ms。关键不是 RandomAccessFile 多快，而是你能否避免它成为瓶颈。
非对齐读写必须手动处理字节边界
RandomAccessFile 本身不关心“对齐”，它只认字节偏移。所谓“非对齐”问题，本质是业务数据结构（如 int/float/long）跨了内存页或磁盘块边界，而 JVM 的 ByteBuffer 或 DataInputStream 默认要求对齐访问——一旦你用 readInt() 读一个起始位置为 3 的 int，会抛 IOException: Not enough bytes。
正确做法是：用 read(byte[]) 读出原始字节，再用 ByteBuffer.wrap(buf).order(ByteOrder.LITTLE_ENDIAN).getInt(0) 手动解析。例如：
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
byte[] buf = new byte[4]; raf.seek(3); raf.readFully(buf); // 必须 readFully，防止只读到部分字节 int value = ByteBuffer.wrap(buf).order(ByteOrder.LITTLE_ENDIAN).getInt();
- 永远不用
readInt()/readLong()等高级方法做非对齐访问 - 批量读写时，优先用
read(byte[], off, len)+write(byte[], off, len)，避免反复 seek - 若频繁跨边界访问，可预分配一个大缓冲区（如 64KB），用
raf.read(buffer)一次加载，再用ByteBuffer在内存中随机索引
多点定位要避免反复 seek() 导致的 syscall 开销
每次 seek() 都是一次系统调用，Linux 下约 50–100ns，看似 negligible，但 1000 次连续 seek() 就可能吃掉 0.1ms。更严重的是，OS 可能因此打乱预读策略，导致后续 read() 变成真实磁盘寻道。
- 把多个目标偏移排序后顺序访问（如 [1024, 512, 2048] → 排成 [512, 1024, 2048]），减少磁头/闪存块来回跳
- 对密集区域（如偏移差 read() 加载整块，再内存解析，比多次 seek+read 更快
- 如果点位固定且高频，考虑用
MappedByteBuffer替代：它把文件映射进虚拟内存，get()/put()是纯内存操作（但注意force()同步开销和 GC 压力）
超大文件（>2GB）下必须用 long 偏移，且注意平台兼容性
RandomAccessFile.seek(long) 支持 64 位偏移，但老版本 JDK（4GB 单文件，NTFS 才行。
- 始终用
long存储偏移量，别用int—— 即使当前文件小，后期扩容会崩溃 - 用
raf.length()获取长度，返回值是long，别强转成int - 关闭前务必调用
raf.close()，否则底层 file descriptor 泄漏，Linux 下最多打开 1024 个文件就卡死
真正难的不是代码怎么写，是得清楚每一行 seek() 和 read() 落在哪个物理块、是否命中 page cache、有没有被 OS 合并或延迟写入。调试时建议搭配 strace -e trace=llseek,read,write,close java YourApp 看真实系统调用行为。
