我有一个想法，我正在和一些同事一起思考。我们谁也不知道它目前是否存在。
基本前提是有一个系统可以100％正常运行，但可以动态变得更高效。
自检系统
下面是这种情况：
*于是，我们迅速敲定一个系统到 指定的一组接口，它具有 零优化，但我们 信心，它是100％稳定 虽然（半信半疑，但对于 起见，这种情况下，请一起演奏 ）
*我们再简介 原来的班，并开始 程序替换为 瓶颈。
*原件和替换件同时启动，并且 同步。
*原稿可以运行到完成：如果替换品没有完成 ，系统将以否决 作为 原件的替代品。
* A替换必须总是返回相同的值作为原始，对于次 指定数量，和为值 特定范围内，之前，它是通过作为 原始替换 。
*如果在采用替换后发生异常，则系统 会自动尝试执行相同的操作 ，并将其替换为 it。
你见过在实践中，类似的概念？批判请...
下面是关于最初的问题后写入 发布的评论：
*系统演示了达尔文的方法来系统演化。
*原始文件和替换文件不会并列运行。
*竞争条件是多线程应用程序固有的问题，我承认他们。
我认为这个想法是一个有趣的理论争论，但不是很实用，原因如下：
这听起来有用，实际上“必须”的唯一“环境”是一个“遗传”系统，它本身生成新版本的代码，但这是一个完全不同的故事，并且不是真正广泛适用的。
在运行时运行性能基准测试的系统将比不运行性能基准测试系统慢。如果目标是优化速度，那么为什么您不能独立进行基准测试，并且一旦证明速度更快，就会导入最快的程序？
而您的同时启动例程的想法可能会引入race conditions。另外，如果目标是确保100％的正常运行时间，则不会引入未经测试的例程，因为它们可能会生成不可捕获的例外。
也许你的想法作为基准测试而不是操作系统的优点是有用的吗？
我在实践中看到过类似的概念吗？不，但我会提出一个方法。
看来你的大部分目标似乎都可以通过某种超级资源控制系统来实现，这可以通过CruiseControl来实现。
CruiseControl可以运行单元测试以确保新版本的正确性。
您必须编写一个CruiseControl构建器pluggin，它可以针对一系列现有的基准测试执行系统的新版本，以确保新版本的改进。
如果CruiseControl构建循环通过，则新版本将被接受。这样的过程需要付出相当大的努力才能实施，但我认为这是可行的。单元测试和基准生成器必须非常光滑。
我认为像OSGi或Spring这样的控制容器反转可以完成大部分你正在谈论的内容。 （按名称动态加载）
你可以建立在他们的东西之上。然后执行你的代码
如果模块通过消息传递完成工作，则可以存储消息，直到操作成功完成并在发生异常时使用另一个模块进行重做。
有关高可用性系统的设计思路，请查看Erlang。
我不认为代码本身会学会更好。但是，一些运行时参数可以很容易地调整到最佳值，但这只是常规编程，对吧？
关于即时更改，我已经分享了这个问题，并将在Lua或类似的动态语言之上进行构建。人们可以装载部件，如果它们被替换，则重新加载使用。在这方面也没有火箭科学。如果“旧代码”仍然在运行，那么它是完全正确的，因为与DLL不同的是，只有在读入文件时才需要该文件，而不是执行来自那里的代码。
有用性？ Naa ...