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

（这与（或者更确切地说是“相反的”）

TL；博士：

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

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

…还是有必要使用这样的循环：

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

?

---

由于一个问题，我想问一下，通过调用将

缓冲区

写入

文件通道

的行为是否有任何保证

---

仅供参考：文件上说

从给定缓冲区将字节序列写入此通道

字节从该通道的当前文件位置开始写入，除非该通道处于附加模式，在这种情况下，该位置首先前进到文件的末尾。如有必要，将增长文件以容纳写入的字节，然后使用实际写入的字节数更新文件位置。否则，此方法的行为与WritableByteChannel接口指定的行为完全相同

以及重写方法的文档，如

从给定缓冲区将字节序列写入此通道

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

---

假设写入了长度为n的字节序列，其中0No，不能保证write（）会耗尽整个缓冲区。文档确实试图建立一种期望，即实现应该一次性写入所有字节，但它注意不做出任何承诺：

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

FileChannel.write（）同样为不完整的写入留出了空间：

从给定缓冲区将字节序列写入此通道

字节从该通道的当前文件位置开始写入，除非该通道处于附加模式，在这种情况下，该位置首先前进到文件的末尾。如有必要，将增长文件以容纳写入的字节，然后使用实际写入的字节数更新文件位置。否则，此方法的行为与WritableByteChannel接口指定的行为完全相同

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

正如您所指出的，这在方法上与read（）有所不同。我认为这是因为，在整合文档时，所有已知的和预期的实现都遵循执行完整写入的一般情况

---

---

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

谢谢，但这基本上是我在问题中已经引用的内容。我认为关键的一点是，它说“除非另有规定，否则写入操作将仅在写入所有r请求的字节后返回。”在一般情况下，对于

FileChannel

情况，它没有明确说明它可能在写入所有请求的字节之前返回。（是的，我看到返回值被称为“实际写入的字节数”，但它并没有说这可能小于请求的数字）。毫无疑问，人们可能不得不假设它不会写所有的东西bytes@Marco13我们都引用了文件，答案就在那里。：）我强调了一些部分，这些部分至少指出了写作不完整的可能性。正如你所说，你不能确定，所以你必须考虑到这种可能性。