如果运行时不抛出（“并发映射写入”）而是恐慌（“并发映射写入”）会发生什么答案

【问题标题】：what would happen if runtime does not throw("concurrent map writes") but panic("concurrent map writes")如果运行时不抛出（“并发映射写入”）而是恐慌（“并发映射写入”）会发生什么
【发布时间】：2021-06-21 11:42:22
【问题描述】：

How to recover from concurrent map writes?

正如icza所说：

如果您让您的应用保持这种状态并且它不会崩溃，您可以在运行时体验神秘的、未定义的行为。

如果一个 goroutine 在“并发映射写入”的情况下无法写入映射，那么只使用 panic("concurrent map writes") 而不是 throw("concurrent map writes") 怎么样。

【问题讨论】：

你说的这个“投掷”是什么？
会有什么不同？它仍然是一场数据竞赛，因此是未定义的行为。使用适当的同步来避免并发映射写入，因此您不必担心恐慌或应用程序崩溃。
唯一让map 与众不同的是map 是一个更复杂的内置数据结构——它拥有自己的逻辑和数据之间的不变性；数据竞速写入会导致未定义的行为并可能导致数据损坏，这可能会使地图进入无效状态（破坏不变性），从而导致以下对地图的读取和写入未定义行为。虽然 panic 而不是 throw 会使其可恢复，但这没有什么意义：数据竞争不是应该或可以在运行时修复的东西。
@jub0bs: throw 用于运行时产生“致命错误”。它不是语言规范的一部分。
@JimB 谢谢。我学到了一些东西。对于未来的读者：golang.org/src/runtime/panic.go#L1107

标签： go

【解决方案1】：

运行时无法检测竞争，但它可以检测map 的内部状态何时被数据竞争破坏，这就是throw("concurrent map writes") 和throw("concurrent map read and map write") 的用途（throw 被广泛使用在运行时中，当没有安全的方法继续时中止程序）。 在这里使用panic 表示您可以从这种情况中恢复，但没有办法恢复，因为已经知道程序状态已损坏。

【讨论】：