问在C中，标准输出缓冲区的大小是多少？

EN

当为默认管道尺寸64K创建管道时，将使用Linux。在/proc/sys/fs/管道-max- size中，存在最大管道大小。对于默认值1048576是典型的。

对于glibc的默认文件缓冲区；65536字节似乎是合理的。但是，grep从glibc源代码树中确定: libio/libio.h:#define _IO_BUFSIZ _G_BUFSIZ sysdeps/generic/_G_config.h:#define _G_BUFSIZ 8192 sysdeps/unix/sysv/linux/_G_config.h:#define _G_BUFSIZ 8192

因此，最初的问题可能会得到回答，也可能不会得到回答。对于一分钟的工作，最好的猜测是8KB。

对于简单的行缓冲，8K就足够了。但是，与64K相比，对于多行缓冲输出，8K的效率并不高。因为对于缺省管道大小，使用64K，并且如果不期望更大的管道大小，并且如果没有明确地设置更大的管道大小，那么对于stdio缓冲器，建议使用64K。

如果需要性能，那么微不足道的8K缓冲区是不够的。通过fcntl(pipefd，F_SETPIPE_SZ,1048576)可以增加管道的大小。通过setvbuf (stdout，buffer，_IOFBF,1048576)可以替换stdio提供的文件缓冲区。如果不使用管道，则管道大小无关紧要。但是，如果在两个进程之间通过管道传输数据，则通过增加管道大小可以提高性能。否则，通过最小的缓冲区或最小的管道，就会产生瓶颈。

如果还在读取，那么由stdio使用更大的缓冲区，可能需要更少的读取函数调用。通过“可能”这个词，提出了一个重要的考虑因素。如由单个写函数调用提供的，由单个读函数调用提供的一样多的数据可以被读取。通过读取函数调用，可以预期返回的字节数少于请求的字节数。通过附加的读取函数调用，可以获得附加的字节。

用于写入数据线；提供了stdio overkill。但是，通过stdio线路缓冲输出是可能的。在某些情况下，行缓冲输出是必不可少的。如果写入proc虚拟文件系统提供的文件，或者如果写入sys虚拟文件系统提供的文件，则应在单个写入缓冲区中包含换行字节。如果使用第二次写入，则可能出现意想不到的结果。

如果read、write和stdio混合在一起，则存在警告。在写函数调用之前，需要一个fflush函数调用。因为stderr没有缓冲；对于stderr，不需要调用fflush函数。通过读取，可能会提供少于预期的字节数。通过stdio，先前的字节可能已经被缓冲。

不要混合unistd和stdio I/O是一个很好的建议，但通常会被忽略。混合缓冲输入是不合理的。混合无缓冲输入是可能的。混合缓冲输出是可行的。

stdio提供了缓冲IO的便利性。如果没有stdio，缓冲IO是可能的。但是，对于代码，需要额外的字节。当利用足够大小的缓冲器时；与stdio提供的输出函数相比，写入函数调用不一定较慢。

然而，当不涉及管道时，则可以通过功能mmap提供更好的IO。在mmap的管道上，不会返回错误。然而，在地址空间中不提供数据。在lseek的管道上，提供了一个错误。

最后，通过man3setvbuf提供了一个很好的例子。如果在堆栈上分配了缓冲区，则在返回之前不能省略fclose函数调用。

实际的问题是“在C语言中，标准输出缓冲区的大小是多少？”到8192年，可能会有这么多答案。

遇到这个问题的人可能会对缓冲区的输入/输出效率感到好奇。通过一些询问，这个目标是隐含地接近的。由于更倾向于简洁的回复，管道大小的重要性和缓冲区大小的重要性以及mmap没有被明确说明。这份回复解释了。

对于类似的问题，here提供了一些非常有趣的答案。

在linux系统上，您可以从不同的函数查看缓冲区大小，包括ulimit。此外，头文件limits.h和pipe.h也应该包含这种信息。

您可以将其设置为无缓冲，或者直接刷新它。

当C运行时通常为您刷新它时，这似乎有一些像样的信息和一些示例。看看this吧。