关于google::protobuf::io::GzipOutputStream关闭文件句柄后无内容写入的技术问询

为什么调用close(ofd)后文件为空？ #

这里的核心问题出在缓冲区生命周期管理与文件描述符的重复操作冲突：

1. GzipOutputStream的缓冲特性：
   GzipOutputStream为了提升压缩效率，会把数据暂时存在内部缓冲区里，只有当缓冲区填满或者调用Close()时，才会把压缩完成的数据写入底层的FileOutputStream。你调用fout.Close()后，虽然压缩数据已经传递给了FileOutputStream，但FileOutputStream自身也有用户态缓冲区，并不会立刻把所有数据刷入磁盘。

2. 手动关闭fd的时机错误：
   你的代码里FileOutputStream是栈上对象，它的析构函数会在函数退出时自动执行——这个析构函数会负责把内部缓冲区的数据刷到磁盘，然后关闭文件描述符ofd。但如果你提前手动调用了close(ofd)，当FileOutputStream析构时，它会尝试对一个已经关闭的fd执行flush和关闭操作，这会触发系统错误，甚至导致之前写入的数据被丢弃，最终得到空文件。

为什么不使用Gzip包装器时没问题？ #

直接用FileOutputStream时，SerializeDelimitedToZeroCopyStream写入的数据会直接进入FileOutputStream的缓冲区，而且这个序列化方法完成后可能会触发隐式flush，或者数据大小刚好适配缓冲区。此时手动调用close(ofd)时，数据已经被刷入磁盘，所以不会出现丢失。这是两种流的缓冲策略差异导致的，并非FileOutputStream本身行为改变。

这属于bug吗？ #

这不属于protobuf的bug，而是不符合推荐的使用规范：

• protobuf的FileOutputStream默认设计为管理传入的文件描述符生命周期（除非构造时指定dont_close参数为true）。手动关闭fd会破坏它的内部状态管理逻辑。
• 正确的做法要么让FileOutputStream的析构函数自动关闭fd，要么显式设置dont_close = true，此时可以手动关闭fd，但必须确保所有流的flush和Close操作都已完成。

修复后的正确代码示例 #

如果确实需要手动管理fd，可以这样修改：

int ofd = open(filename.c_str(), O_WRONLY | O_CREAT | O_TRUNC, 0777); 
google::protobuf::io::FileOutputStream::Options options;
options.dont_close = true; // 告知FileOutputStream不要自动关闭fd
google::protobuf::io::FileOutputStream outp(ofd, options); 
google::protobuf::io::GzipOutputStream fout(&outp); 
MyMessage msg; 
ConstructMessage(&msg); 
CHECK(google::protobuf::util::SerializeDelimitedToZeroCopyStream(msg, &fout)); 
fout.Close(); 
outp.Flush(); // 显式刷新FileOutputStream的缓冲区
close(ofd); // 此时手动关闭fd是安全的

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