管理语言和运行时的未来保护

Question

将来，托管运行时是否会提供额外的保护，以防止微妙的数据损坏问题？

托管运行时(如Java和Java)减少或消除了许多在本地语言(如.NET )中常见的内存损坏bug的可能性。然而，令人惊讶的是，他们并不能幸免于所有的内存损坏问题。一个直觉地期望验证其输入的方法没有错误，并且健壮地处理异常总是将其对象从一种有效状态转换为另一种状态，但事实并非如此。(更准确的说法是，使用流行的编程约定的情况并非如此-对象实现者需要不顾一切地避免我描述的问题。)

考虑以下情况：

1. 线程。调用方可以与其他线程共享对象，并对其进行并发调用。如果对象不实现锁定，则字段可能已损坏。(也许--除非通知对象是线程安全的-运行时应该对每个方法调用使用一个互锁来抛出异常，如果在另一个线程上并发执行同一对象上的任何方法。这将是一个保护功能，就像管理运行时的其他公认的安全特性一样，它也有一些成本。)
2. 重新进入。该方法对任意函数(例如事件处理程序)进行标注，该函数最终调用对象上的方法，而这些方法在该对象上不被设计为在此点上被调用。这甚至比线程安全更棘手，而且许多类库没有做到这一点。(更糟糕的是，类库很难记录允许重新进入的内容。)

对于所有这些情况，可以认为彻底的文档是一种解决方案。但是，文档还可以规定如何在非托管语言中分配和释放内存。我们从经验(例如，内存分配)中了解到，文档和语言/运行时强制执行之间的区别是日夜的。

在未来的语言和运行时，我们能期望什么来保护我们免受这些问题和其他类似的微妙问题的影响呢？

Answer 1

我认为语言和运行时将继续向前发展，不断从开发人员那里抽象出问题，并继续使我们的生活更轻松、更有效率。

以你的例子-线程。在.NET世界中有一些伟大的新特性可以简化我们日常使用的线程模型。例如，STM.NET最终可能使共享状态的处理更加安全。与现有技术相比，并行扩展在.NET 4中使线程处理变得非常容易。

Answer 2

我认为事务性内存对于解决其中一些问题是有希望的。我不确定这是否在某种程度上回答了你的问题，但无论如何，这是一个有趣的话题：

内存

大概一年前，软件工程电台有一集关于这个话题的节目。

Answer 3

首先，“管理”是一个错误的名称:像OCaml、Haskell和SML这样的语言在完全编译时实现了这样的保护和安全。所有相关的“管理”发生在编译时通过静态分析，这有助于优化和速度。

无论如何，要回答您的问题:如果您查看像Erlang和Haskell这样的语言，默认情况下状态是孤立的和不可变的。在某种系统中，线程和重入在默认情况下是安全的，而且由于您必须尽自己的努力打破这些规则，因此很明显可以看到哪里会出现不安全的代码。

从安全的缺省值开始，但为高级不安全的使用留出空间，您就可以充分利用这两个世界。根据您的定义，安全的未来系统可能也会遵循这些实践，这似乎是合理的。