将来，托管运行时是否会针对微妙的数据损坏问题提供额外的保护？
托管运行时(例如 Java 和 .NET CLR)减少或消除了 C# 等 native 语言中常见的许多内存损坏错误的可能性。尽管如此，令人惊讶的是，它们并没有免受所有内存损坏问题的影响。人们直观地期望验证其输入、没有错误并且稳健地处理异常的方法将始终将其对象从一种有效状态转换为另一种有效状态，但事实并非如此。 (更准确地说，使用流行的编程约定并非如此——对象实现者需要竭尽全力避免我描述的问题。)
考虑以下场景:
线程。调用者可能与其他线程共享该对象并对其进行并发调用。如果对象未实现锁定，则字段可能会损坏。 (也许——除非通知该对象是线程安全的——运行时应该在每个方法调用上使用互锁，以便在同一对象上的任何方法在另一个线程上同时执行时引发异常。这将是一种保护功能，并且，与托管运行时的其他广为接受的安全功能一样，它也有一定的成本。)
可重入。该方法对任意函数(例如事件处理程序)进行调出，该函数最终调用对象上未设计为在此时调用的方法。这比线程安全更棘手，许多类库都没有做到这一点。 (更糟糕的是，众所周知，类库没有很好地记录允许重入的内容。)
对于所有这些情况，可以说完整的文档是一种解决方案。但是，文档还可以规定如何在非托管语言中分配和释放内存。我们从经验(例如，内存分配)中知道，文档和语言/运行时执行之间的差异是天壤之别。
future 我们可以从语言和运行时中得到什么来保护我们免受这些问题和其他类似问题的影响？
最佳答案
我认为语言和运行时将不断向前发展，不断从开发人员手中抽象出问题，并不断让我们的生活变得更轻松、更高效。
举个例子——线程。 .NET 世界即将出现一些很棒的新功能，可以简化我们日常使用的线程模型。 STM.NET例如，最终可能会使共享状态的处理变得更加安全。 parallel extensions与当前技术相比，.NET 4 中的线程处理变得非常容易。
关于multithreading - 托管语言和运行时的 future 保护，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1580815/