FileChannel#write是否总是写入整个缓冲区？

Question

（这与（或者相反）如果有足够的数据，FileChannel.read读取的字节会比指定的少吗？）

TL；博士：

这会一直写入整个缓冲区吗。。。

ByteBuffer bytes = ...;
fileOutputStream.getChannel().write(bytes);

...或者有必要使用这样的循环：

ByteBuffer bytes = ...;
while (bytes.remaining() > 0)
{
    fileOutputStream.getChannel().write(bytes);
}

?

由于另一个答案中的评论，我想问一下，通过调用FileChannel#write（ByteBuffer）向FileChannel写入缓冲区的行为是否有任何保证。

仅供参考：文件上说

从给定缓冲区向该通道写入字节序列。

除非通道处于追加模式，否则从该通道的当前文件位置开始写入字节，在这种情况下，该位置首先前进到文件的末尾。如有必要，文件将被扩展以容纳写入的字节，然后文件位置将根据实际写入的字节数进行更新。否则，此方法将完全按照WritableByteChannel接口指定的方式运行。

和重写方法的留档，WritableByteChannel#写（ByteBuffer）说

从给定缓冲区向该通道写入字节序列。

尝试向通道写入最多r个字节，其中r是调用此方法时缓冲区中剩余的字节数，即src.remaining（）。

假设写入了长度为n的字节序列，其中0

除非另有规定，否则写入操作仅在写入所有r请求的字节后返回。某些类型的通道，根据其状态，可能只写入部分字节，也可能根本不写入。例如，非阻塞模式下的套接字通道写入的字节数不能超过套接字输出缓冲区中的可用字节数。

可以随时调用此方法。但是，如果另一个线程已经在这个通道上启动了写操作，那么这个方法的调用将被阻止，直到第一个操作完成。

参数：src-从中检索字节的缓冲区

返回：写入的字节数，可能为零

在上面提到的关于从FileChannel读取的问题中，在评论中已经讨论了这个留档的确切措辞和解释。我认为留档的关键区别在于，对于读取方法，留档说

读操作可能不会填满缓冲区，事实上，它可能根本不会读取任何字节。

与此相反，write方法的文档显示

除非另有规定，否则写入操作仅在写入所有r请求的字节后返回。某些类型的通道，根据其状态，可能只写入部分字节，也可能根本不写入。

对我来说，这意味着FileChannel上的写入操作只会在写入所有字节后返回，因为文档中没有另外指定它（除了返回值可能为0的语句，但这显然是重写方法的产物）

根据我的测试，文件大小高达80MB（！），写入操作总是一次写入整个缓冲区。但当然，这只是一个测试，不足以做出深刻的陈述。我试图跟踪相关OpenJDK类中的调用，但这些调用很快就会分化为不同的本机实现——毕竟，这应该不是必需的。。。




Answer 1

不，不能保证write（）会耗尽整个缓冲区。文档确实试图建立一种期望，即实现应该一次性写入所有字节，但它注意不做出任何promise：

除非另有规定，否则写入操作仅在写入所有r请求的字节后返回。某些类型的通道，取决于它们的状态^[1]，可能只写入部分字节，也可能根本不写入。

文件频道。write（）同样为不完整的写入留出了空间：

从给定缓冲区向该通道写入字节序列。

除非通道处于追加模式，否则从该通道的当前文件位置开始写入字节，在这种情况下，该位置首先前进到文件的末尾。如有必要，文件将被扩展以容纳写入的字节，然后文件位置将根据实际写入的字节数进行更新。否则，此方法将完全按照WritableByteChannel接口指定的方式运行。

因此，虽然文本暗示完整写入是一般情况，不完整写入是例外情况，但它为可能（无法）遵循这种一般情况的替代/未来实现打开了大门。

正如您指出的，这是与read（）方法不同的地方。我想这是因为，在合并留档时，所有已知和预期的实现都坚持执行完全写入的一般情况。

[1] 这可能是指非阻塞通道。