ECMA CLI规范定义了一个弱内存模型。这样可以对命令执行顺序进行重新排序（这对于提高性能很有用）。但是为这种模型编写底层代码非常困难。
最重要的是-X86 / AMD64处理器体系结构具有更严格的（强）内存模型。结果，Microsoft在其CLR实现中实现了比规范中所描述的更强大的内存模型。
.NET Core中的内存模型是否已更改？：该框架可能可以在内存模型比X86 / AMD64弱的体系结构上运行。
此外，.NET Core合并了Mono等。据我所知，Mono内存模型较弱，对应于ECMA。
在本文Introducing .NET 5中，写为：
通过充分利用.NET Core，.NET Framework，Xamarin和Mono来扩展.NET的功能。
所以我认为，如果不是现在，那么将来这些运行时将合并为一个整体。
在下面的文章中写道：
我们正在相互替代CoreCLR和Mono。我们将使它像构建开关一样简单，可以在不同的运行时选项之间进行选择。
如果我理解正确，将有两个（或更多个）运行时。也许每个人都会有自己的记忆模型。
我们在说什么：Memory Model。
答案 0 :(得分：1)
内存模型特定于运行时，因此您的问题实际上是“ CLR，CoreCLR和MonoRuntime的内存模型是否存在任何差异”。
经过研究后，这个问题确实非常难以回答。您已经提到了the ECMA specification，它为您提供了所有实现都必须提供的最低限度的保证。 Joe Duffy's blog上有一个用于CLR 2.0的非常简洁的描述。然后，对于.NET Framework，有this two part article谈论CLR模型的细节可能比了解的健康得多。甚至还有a paper写在上面。
对于MonoRuntime，我发现this doc讨论了原子，并实际上描述了Mono实现此方法的方式，尽管详细程度很低。
查找CoreCLR的细节更加棘手。 dotnet/coreclr GitHub thread中重点介绍了一些要点，并讨论了易失性读/写in this one。
最简单的回答方法是-是的，根据上述资源，它已经更改。
但是，还有第二种方法来回答您的问题，那就是简单地否认它的前提-似乎假设内存模型发生了某种改变，即有些聪明的人坐下来改写了ECMA CLI规范，进入CoreCLR内存模型规范，这就是新的内存模型。事实并非如此。提到的聪明人坐了下来，经过几个月的努力，将设计改进为可靠，快速，明智地易于实施，并且没有违反规范的最低保证。从链接的乔·达菲的博客中引用：
我们已经通过多年的非正式工作和示例设计（...）构建了我们的模型，该模型易于从一种实现转换为另一种实现。
不幸的是，非正式的ECMA规范已经达到我们目前的正式水平。没有对ECMA规范和CLR实现之间的更改的正式描述，也没有对CLR和CoreCLR之间的更改的正式描述。而且，更重要的是， ECMA CLI与CLR / CoreCLR之间特定于实现的区别仅在于-特定于实现-绝不能依赖。 .NET Core内存模型的实现方式的唯一100％可靠的来源是源代码。显然，每次提交，每个发行版都会发生这种变化，并且不能保证团队不会将整个抖动扔到窗外，而将.NET 5重写为与ECMA规范完全相同（但是，这不太可能）。