在标准输出线程上并发写入是安全的吗？

从现在开始，努力学习吧！本文《在标准输出线程上并发写入是安全的吗？》主要讲解了golang等等相关知识点，我会在golang学习网中持续更新相关的系列文章，欢迎大家关注并积极留言建议。下面就先一起来看一下本篇正文内容吧，希望能帮到你！

问题内容

下面的代码不会引发数据竞争

package main

import (
    "fmt"
    "os"
    "strings"
)

func main() {
    x := strings.Repeat(" ", 1024)
    go func() {
        for {
            fmt.Fprintf(os.Stdout, x+"aa\n")
        }
    }()

    go func() {
        for {
            fmt.Fprintf(os.Stdout, x+"bb\n")
        }
    }()

    go func() {
        for {
            fmt.Fprintf(os.Stdout, x+"cc\n")
        }
    }()

    go func() {
        for {
            fmt.Fprintf(os.Stdout, x+"dd\n")
        }
    }()

    
我尝试了多个长度的数据，变体https://play.golang.org/p/29Cnwqj5K30
[这篇文章](https://stackoverflow.com/questions/14694088/is-it-safe-for-more-than-
one-goroutine-to-print-to-stdout)说它不是TS。
[这封邮件](https://groups.google.com/g/golang-nuts/c/tUaAOg-
vOt4/m/D1avN9CEw7YJ)并没有真正回答这个问题，或者我不明白。
os和fmt的包文档对此没有提及太多。我承认我没有挖掘这两个包的源代码来寻找进一步的解释，它们对我来说似乎太复杂了。
有哪些建议和 参考 ？

    正确答案

我不确定它是否有资格作为一个明确的答案，但我会尝试提供一些见解。
包的F*-functionsfmt仅声明它们采用实现io.Writer接口的类型的值并调用Write它。函数本身对于并发使用是安全的——从某种意义上说，可以同时调用任意数量的fmt.Fwhaveter并发：包本身已经为此做好了准备，但是
Go 中对接口的支持并没有说明任何关于真正的并发类型。
换句话说，可能允许或不允许并发的真正点被推迟到写入函数的“作者”
fmt。（还应该记住，这些fmt.*Print*函数可以Write多次调用其目的地 - 而不是那些由 s​​tock 包提供的log。）
所以，我们基本上有两种情况：

• 的自定义实现io.Writer。
• 它的库存实现，例如*os.File由 package.json 函数产生的套接字或围绕套接字的net包装器。

第一种情况很简单：无论实现者做了什么。

第二种情况更难：据我了解，Go 标准库对此的立场（尽管文档中没有明确说明）在于它围绕操作系统提供的“事物”提供的包装器——例如文件描述符和套接字—— re 合理地“瘦”，因此无论它们实现什么语义，都由运行在特定系统上的 stdlib 代码传递实现。

例如，POSIX要求write(2) 在对常规文件或符号链接进行操作时， 调用彼此之间是原子的。这意味着，由于Write对包装文件描述符或套接字的事物的任何调用实际上都会导致 tagret 系统的单个“写入”系统调用，因此您可以查阅目标操作系统的文档并了解会发生什么。

请注意，POSIX 只告诉文件系统对象，如果os.Stdout打开到终端（或伪终端）或管道或任何其他支持write(2)系统调用的东西，结果将取决于相关子系统和/或驱动程序实施——或实例，来自多个并发调用的数据可能散布在其中，或者调用之一或两者都可能只是被操作系统失败——很可能，但仍然如此。

回到 Go，根据我的收集，以下事实适用于包装文件描述符和套接字的 Go stdlib 类型：

• 它们本身可以安全地并发使用（我的意思是，在 Go 级别上）。
• 它们“映射”Write并Read一对一地调用底层对象——也就是说，一个Write调用永远不会分成两个或多个底层系统调用，一个Read调用永远不会从多个底层系统调用的结果中返回“粘合”的数据。（顺便说一句，人们偶尔会被这种朴实无华的行为绊倒——例如，把这个或这个作为例子。）

因此，基本上，当我们考虑这一点时，每次fmt.*Print*调用都可以自由调用Write任意次数，您使用os.Stdout, 的示例将：

• 永远不要导致数据竞争——除非你已经为变量分配了os.Stdout一些自定义的实现，——但是
• 实际写入底层 FD 的数据将以不可预知的顺序混合，这可能取决于许多因素，包括 OS 内核版本和设置、用于构建程序的 Go 版本、硬件和系统负载。

TL;博士

• 多个并发调用fmt.Fprint*写入相同的“writer”值将它们的并发性推迟到“writer”的实现（类型）。
• 在您在问题中提出的设置中，不可能与 Go stdlib 提供的“类文件”对象进行数据竞争。
• 真正的问题不在于 Go 程序级别的数据竞争，而是在 OS 级别发生的对单个资源的并发访问。在那里，我们（通常）不谈论数据竞争，因为 Go 支持的商品操作系统将人们可能“写入”的东西暴露为抽象，其中真正的数据竞争可能表明内核或驱动程序中存在错误（以及Go 的竞争检测器无论如何都无法检测到它，因为该内存不会由为进程提供动力的 Go 运行时拥有）。

基本上，在您的情况下，如果您需要确保任何特定调用生成的数据fmt.Fprint*作为操作系统提供的实际数据接收器的单个连续片段出现，您需要序列化这些调用，因为fmt包不提供关于Write为其导出的函数调用提供的“编写器”的次数。
序列化可以是外部的（显式的，即“获取锁，调用fmt.Fprint*，释放锁”）或内部的（通过将管理锁包装os.Stdout在自定义类型中并使用它）。当我们在做的时候，log包就是这样做的，并且可以立即用作它提供的“记录器”，包括默认的记录器，允许禁止输出“日志头”（例如时间戳和文件名）。

终于介绍完啦！小伙伴们，这篇关于《在标准输出线程上并发写入是安全的吗？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！