Java MappedByteBuffer load 和 isLoaded 有什么区别

平时用Java NIO处理大文件做内存映射时，很多开发者会搞混MappedByteBuffer的load()和isLoaded()两个方法的作用，分不清什么时候该调用哪个，很容易写出不符合预期的代码。

load() 是主动执行加载动作的方法，作用是把当前映射的文件区域对应的所有页都尝试加载进物理内存；isLoaded() 是状态查询方法，只会返回一个布尔值，告诉你这块映射区域的所有页是不是已经都在物理内存中了，一个是执行操作，一个是查询状态，二者不存在互相替代的关系。

Java 的 MappedByteBuffer.load() 和 isLoaded() 都与内存驻留有关，但职责完全不同：load() 是一次“尽力预取”的请求，可能触发缺页和 I/O；isLoaded() 只是询问“当前看起来是否已经驻留”的提示。它们都不能保证后续访问永远不再发生缺页。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/nio/MappedByteBuffer.html

需要主动预热时调用 load()，需要观察状态时读取 isLoaded()；不要用 isLoaded() 决定业务正确性，也不要把 load() 当成永久锁定物理内存的开关。

load 和 isLoaded 分别改变或返回什么

load() 的目标是让映射缓冲区的内容在方法返回时尽量驻留在物理内存中。Javadoc 明确说明，这个过程可能产生若干缺页和 I/O，因此它更像预热提示，而不是一次普通的字节读取。它返回当前缓冲区本身，便于继续链式调用。

isLoaded() 不会发出预取请求，只返回一个布尔提示。返回 true 表示内容很可能驻留，返回 false 也不表示内容一定不在物理内存中；方法返回后，操作系统仍可能把页面换出，所以这个结果不是强一致状态。

最小映射代码里应该怎样放置两个方法

下面的示例只展示调用职责，不把输出当成固定运行结果。文件映射由 FileChannel.map 创建，load() 放在确实希望提前触达页面的位置，isLoaded() 只用于记录或诊断。

import java.io.IOException;
import java.nio.MappedByteBuffer;
import java.nio.channels.FileChannel;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

public class MappedStateDemo {
    static byte readFirstByte(Path path) throws IOException {
        // READ_ONLY 只用于读取，映射长度由文件大小决定。
        try (FileChannel channel = FileChannel.open(path, StandardOpenOption.READ)) {
            MappedByteBuffer mapped = channel.map(
                    FileChannel.MapMode.READ_ONLY, 0, channel.size());

            // load 是尽力预热请求，不能把它当成永久驻留保证。
            mapped.load();

            // isLoaded 只做状态提示，不能决定业务是否正确。
            boolean likelyResident = mapped.isLoaded();

            // 真正读取仍然通过 ByteBuffer API，状态提示不替代 get。
            System.out.println("likelyResident=" + likelyResident);
            return mapped.get(0);
        }
    }
}

这里的 get(0) 才是读取映射内容的动作。即使此前调用过 load()，也应按正常映射读取处理潜在的缺页；即使 isLoaded() 返回 true，也不要把它当成业务数据已经“准备完成”的信号。

按工作负载选择：预热、观测，还是直接读取

如果应用即将连续访问一个较大的映射区域，可以把 load() 作为降低首次访问抖动的预热意图，但要把它放在可接受 I/O 成本的阶段。它可能带来额外页错误和磁盘读取，内存压力较大时也不应假定所有页面会一直留下。

如果只是排查“这段映射是否可能已经驻留”，可以读取 isLoaded() 并记录到诊断日志。它适合解释某次观察，不适合做“返回 false 就走另一条业务路径”这样的强分支，更不适合用少量调用结果推导所有机器上的性能结论。

如果访问量小、数据冷、或应用不需要控制首次访问时机，通常直接按正常的 MappedByteBuffer 读取即可。不要为了让接口看起来更完整而在每次映射后无条件 load()，因为预热本身也可能产生 I/O 和内存压力。

别把驻留提示当成稳定性能保证

内存映射受操作系统虚拟内存管理影响。官方文档指出，映射内容可能因本进程或其他进程改变，何时发生变化取决于操作系统；如果映射文件被截断，部分区域还可能变得不可访问。也就是说，load() 和 isLoaded() 都不能替代文件生命周期和并发修改约束。

实际落地时可以记住四点：

• load() 用于表达“希望尽力预取”，不是锁页接口。
• isLoaded() 用于观测提示，不是可靠的业务条件。
• 页面状态会随操作系统调度变化，性能结论要结合完整负载和指标。
• 不要在映射仍被使用时随意截断底层文件，也不要让其他进程无约束地改写映射区域。

相关问题

isLoaded() 返回 false 就一定发生缺页吗？

不一定。官方定义明确说明，false 不代表内容一定不驻留；它只是当前判断不够乐观。即使返回 true，方法返回后页面也可能被换出。

调用 load() 后还需要正常读取吗？

需要。load() 是预取请求，真正的数据仍应通过 get、相对读取或其他 ByteBuffer API 访问，并正确处理文件被截断等异常边界。