共享内存与消息传递如何处理大型数据结构？

邴英毅

2023-03-14

问题内容：

在查看Go和Erlang的并发方法时，我注意到它们都依赖于消息传递。

由于没有共享状态，因此这种方法显然可以减轻对复杂锁的需求。

但是，请考虑许多客户想要并行只读访问内存中单个大数据结构（例如后缀数组）的情况。

我的问题：

问题答案：

是的，在这种情况下，共享状态可能会更快。但是，只有在您可以放弃锁的情况下，这才是绝对可行的。如果它是“主要是只读的”，那么您需要一个锁（除非您设法编写无锁结构，并被警告它们比锁还要棘手），然后您很难使它执行为作为一个好的消息传递体系结构，速度很快。
是的，您可以编写一个“服务器进程”来共享它。有了真正的轻量级流程，它只需要编写一个小的API即可访问数据。像“拥有”数据的对象（在OOP意义上）那样思考。在较大的情况下（或如果数据存储缓慢），将数据拆分为多个块以增强并行性（在DB圈子中称为“分片”）。
即使NUMA成为主流，每个NUMA单元仍具有越来越多的内核。最大的区别在于，一条消息只能在两个内核之间传递，而必须从所有内核上的缓存中清除锁，从而将其限制为小区间总线延迟（甚至比RAM访问慢）。如果有的话，共享状态/锁变得越来越不可行。

简而言之。。。。习惯了消息传递和服务器进程。

编辑：重新访问此答案，我想添加一个关于Go文档中的短语：

通过通信共享内存，不要通过共享内存进行通信。

这个想法是：当线程之间共享内存块时，避免并发访问的典型方法是使用锁进行仲裁。Go风格是传递带有引用的消息，线程仅在收到消息时访问内存。它依赖于某种程度的程序员纪律。但是代码看起来很简洁，可以轻松校对，因此调试起来相对容易。

优点是您不必在每条消息上复制大量数据，也不必像某些锁实现那样有效地刷新缓存。现在说这种风格是否导致更高性能的设计还为时过早。（特别是因为当前的Go运行时在线程调度上有些天真）