ECMA CLI规范定义了一个弱内存模型。这样可以对命令执行顺序进行重新排序（这对于提高性能很有用）。但是，为这种模型编写低级代码非常困难。
最重要的是-X86 / AMD64处理器体系结构具有更严格的（强）内存模型。结果，Microsoft在其CLR实现中实现了比规范中描述的更强大的内存模型。
.NET Core中的内存模型是否已更改？该框架可能可以在内存模型比X86 / AMD64弱的体系结构上运行。
此外，.NET Core合并了Mono等。据我所知，Mono内存模型较弱，对应于ECMA。
在.NET 5简介中撰写：
通过充分利用.NET Core，.NET Framework，Xamarin和Mono来扩展.NET的功能。
因此，我认为，如果不是现在，那么将来这些运行时将合并为一个整体。
在下面的文章中写道：
我们正在相互替代CoreCLR和Mono的过程中。我们将使它像构建开关一样简单，可以在不同的运行时选项之间进行选择。
如果我理解正确，将有两个（或更多）运行时。也许每个人都会有自己的记忆模型。
我们在说什么：内存模型。
内存模型特定于运行时，因此您的问题实际上是“CLR、CoreCLR 和 MonoRuntime 的内存模型是否存在任何差异”。
经过一番研究，我发现这个问题真的很难回答。目前的ECMA规范，您已经提到，它给你的最低限度的保证，所有的实现都必须提供。在Joe Duffy 的CLR 2.0博客上有一个非常好的、简洁的描述。然后，对于 .NET Framework，有两 部分的文章讨论了 CLR 模型，其中的细节可能比了解的要多。甚至还写了一篇论文。
对于 MonoRuntime，我发现这个 doc谈论原子并实际上描述了 Mono 实现它的方式，尽管细节水平相当低。
查找 CoreCLR 的详细信息更加棘手。有在此强调了一些关键点的dotnet / coreclr GitHub的线程和关于性读/写操作的讨论在这一个。
最简单的回答方法是 - 是的，根据上述资源，它已经改变了。
然而，还有第二种方法可以回答你的问题，那就是简单地否认它的前提 - 似乎假设内存模型发生了变化，因为一些聪明人坐下来重写了 ECMA CLI 规范，并将其纳入 CoreCLR内存模型规范，这就是新的内存模型。事实并非如此。提到的聪明人坐下来，在几个月的时间里，改进了设计，使其可靠、快速、易于实施且不违反规范的最低保证。引用来自链接的 Joe Duffy 的博客：
我们通过多年的非正式工作和示例设计（...）构建了我们的模型，这很容易从一个实现更改为下一个实现。
不幸的是，非正式的 ECMA 规范与我们目前所得到的一样正式。ECMA 规范和 CLR 实现之间的变化没有正式的描述，CLR 和 CoreCLR 之间的变化也没有正式的描述。而且，更重要的是，ECMA CLI 和 CLR/CoreCLR 之间的实现特定差异只是 - 特定于实现 - 并且不能依赖。.NET Core 内存模型如何实现的唯一 100% 可靠来源是源代码。这显然会随着每次提交、每次发布而发生变化，并且无法保证团队不会将整个抖动排除在外，并为 .NET 5 重写它以使其与 ECMA 规范完全相同（但是这极不可能） ）。