当前普遍使用的垃圾收集器减轻了程序员手工管理内存的负担,提高了程序的可信性。但是,除了内存外,还有很多其他的有限系统资源,比如文件柄和数据库连接,程序员必须认真地管理这些资源。程序员不正确地使用资源造成的资源使用故障,主要包括释放资源后继续使用资源导致的资源安全(safety)故障和没有及时释放不再使用的资源导致的资源泄漏故障。资源使用故障作为一类十分普遍的软件故障,给软件系统的可信性造成了严重威胁。为了降低资源使用故障对软件系统可信性的危害,本文根据故障到失效的传播路径,从两个方面着手,避免资源使用故障导致的软件失效的发生:(1)在软件发布前的软件测试阶段,查找资源使用故障,然后修复它们,目的是尽量减少发布后的软件的故障数目,提高软件系统的可信性,减少后期软件维护的代价。鉴于当前资源使用故障分析技术的可用性差,以及需要形式化的资源规约的限制,本文研究不需要资源规约的轻量级资源使用故障测试方法;(2)尽管在软件开发过程中,软件开发者采用了各种手段减少软件故障,但是由于当前软件质量保证手段存在种种限制,发布后的软件还是包含大量的故障。为了避免这部分残存的资源使用故障导致软件系统失效,本文研究使用规约强制技术,通过强制资源规约,容错资源使用故障。本文进行了如下三个方面的研究。1.轻量级资源使用故障的测试本文提出一种面向Java程序的轻量级资源泄漏测试方法 Lea T(LEAk Test)。它的主要思想是,如果程序员没有在一个资源对象的终结方法(finalizer)执行前调用这个资源对象的清理方法(cleanup method),这个资源对象就泄漏了。Lea T是轻量级的,易于实现和使用,并且高效。与现有的资源泄漏测试和分析方法不同,程序员通过向测试程序中简单地添加几行代码就实现了这个方法,它可以检测大多数的系统资源的泄漏,不需要任何资源规约。对于存在资源规约的一般资源,Lea T也可以检测它们的泄漏。本文进行了一系列实验,评估该方法检测资源泄漏的能力,在几乎所有的Da Capo测试程序集的测试程序中(25个程序中的24个)和所有的Eclipse测试插件中发现了大量资源泄漏故障,平均性能代价是2.79%。由于Lea T检测的资源泄漏都是在运行时真实发生的,它不会出现误报。同时,本文通过实验,说明这个方法能够有效地发现资源泄漏故障,漏报率很低。2.利用子构件规约挖掘精确的资源规约本文利用已有的规约能够挖掘更好的规约,提出了使用基于状态的规约挖掘方法利用子构件的已有规约挖掘精确的组合构件的规约的方法 Pre Comm(PREciseCOMposite component specification Miner)。本文区分编码在子构件规约里的子构件的不同的状态,利用这些状态构造组合构件的抽象状态。当子构件的可用规约是有限状态性质时,根据这个性质监控执行轨迹中的子构件,把监控器当前到达的状态看着此时子构件的抽象状态,然后使用这些抽象状态标注组合构件的状态。通过这种方法,组合构件能够区分编码在子构件规约中的子构件的不同状态,规约挖掘工具能够有效增加挖掘的组合构件的状态数,生成的组合构件的规约更加精确。本文的方法具有广泛的适用性,能够挖掘十分复杂的模型。由于资源之间的包装关系(一个资源把另一个资源封装在自己的属性里)十分常见,本文的方法很好地利用了这种现象,特别适合挖掘精确的资源规约。本文通过实验评估了Pre Comm,实验比较了利用子构件的规约和使用null抽象方法挖掘的规约的不同。实验使用Da Capo测试程序集作为API客户程序,挖掘来自于Java系统库中17包中的类的规约。实验结果表明,该方法能够显著提高挖掘的规约的精确性,改进了10个过于泛化的模型中的7个,平均消除了这7个模型中25.05%的错误行为。同时,实验中没有观察到该方法挖掘的规约的完整性的损失。这个方法速度很快,监控子构件规约的代价也很小,分析执行轨迹的时间增加在10%左右。3.基于资源规约自动强制的资源使用故障容错在资源使用故障已经潜入部署后软件的情况下,一种减轻或者消除资源使用故障危害的容错技术就显得十分必要。本文注意到,少量的资源泄漏不会带来问题,既不会影响软件的行为,也不会影响软件的性能。只有当泄漏的资源消耗了所有的可用资源或者造成很大的性能代价时,才会发生系统失效。本文提出一种容错资源泄漏的自动资源回收技术Resco(RESource COllection),使得泄漏的资源不会超过特定的界限。当泄漏的资源消耗了足够多的资源以至于系统即将崩溃或者系统的性能受到影响时,就开始回收泄漏的资源。首先,识别泄漏的资源。如果一个资源对象不可达(unreachable),并且没有被释放,本文就认为它被泄露了。对于带有垃圾收集器的运行时系统(比如Java虚拟机),本文修改垃圾收集器,使得它在收集垃圾时保留泄漏的资源。然后,调用资源规约中相应的释放方法安全地释放泄漏的资源。本文通过标准的测试程序评估了Resco的性能代价。实验结果表明,Resco的性能代价很低,在1%和3%附近。本文使用了4个资源泄漏故障评估了Resco的回收泄漏的资源的能力。Resco成功容错了这4个资源泄漏故障中的3个,回收了全部泄漏的资源。从长期来看,Resco的性能是稳定的,只有当触发资源回收时Resco的性能才有较大波动。因为泄漏的资源对象依然是可达的,Resco不能回收第4个资源泄漏故障泄漏的资源对象。