本文示例源代码或素材下载
目录
了解运行时故障
处理故障
回收宿主进程
镜像的进程
回收部分进程
什么是 AppDomain?
状态损坏
检测共享状态
升级策略
复原到升级
编写可靠的代码
选择可靠性级别
清理代码
受约束的执行区域
可靠性约定
缓解故障的艰难旅程
何时使用稳固的可靠性约定
SafeHandle
使用锁
硬 OOM 条件和软 OOM 条件
当我们谈论某样东西具有可靠性时,我们是指它值得信赖,而且可以预测。但是就软件而言,还必须具备其他重要属性,才可以说代码具有可靠性。
软件必须具有复原性,意思是说在出现内部和外部中断情况时,它仍然可以继续正常运行。它必须是可恢复的,以便它知道如何将自己恢复到先前已知的一致状态。软件必须可预测,这样它会提供及时的预期服务。它必须不可中断,意思是更改和升级都不会影响它的服务。最后,软件必须是生产就绪的,意思是它包含最少的 bug,并且只需要进行数量有限的更新。如果满足了这些条件,那么软件就真正称得上可靠了。
可靠代码的这些关键属性取决于不同的因素 — 有些取决于软件的整体体系结构,有些取决于将运行软件的操作系统,还有一些则取决于用来开发应用程序的工具和构建应用程序所基于的框架。复原能力是一种依赖于每一层的属性,应用程序的复原能力取决于其最薄弱的一环。
现在,请设想一下基于 Microsoft® .NET Framework 的应用程序。这些应用程序委托运行时进行某些操作,这些操作在本机环境中不存在(例如 IL 代码的实时编译),或者已处于开发人员的直接控制之下(例如内存管理)。就可靠性而言,平台自身可以引入自己的故障点,这些故障点会影响在其上运行的应用程序的可靠性。了解这些故障可能在哪里发生以及可以使用什么样的技术来创建更可靠的基于 .NET 的应用程序非常重要。
版权与免责声明
1、本站所发布的文章仅供技术交流参考,本站不主张将其做为决策的依据,浏览者可自愿选择采信与否,本站不对因采信这些信息所产生的任何问题负责。
2、本站部分文章来源于网络,其版权为原权利人所有。由于来源之故,有的文章未能获得作者姓名,署“未知”或“佚名”。对于这些文章,有知悉作者姓名的请告知本站,以便及时署名。如果作者要求删除,我们将予以删除。除此之外本站不再承担其它责任。
3、本站部分文章来源于本站原创,本站拥有所有权利。
4、如对本站发布的信息有异议,请联系我们,经本站确认后,将在三个工作日内做出修改或删除处理。
请参阅权责声明!