动态空间管理-web服务稳定性测试 负载测试 可靠性测试 测试报告

时间:2021-07-10 17:12:19
【文件属性】:
文件名称:动态空间管理-web服务稳定性测试 负载测试 可靠性测试 测试报告
文件大小:10.35MB
文件格式:PDF
更新时间:2021-07-10 17:12:19
数据结构 邓俊辉 清华大学 mooc学堂在线 教材 第2章 向量 §2.4 劢态空间管理 3333 需强调的是,由于向量内部含有动态分配的空间,默认的运算符"="不足以支持向量之间的 直接赋值。例如,6.3节将以二维向量形式实现图邻接表,其主向量中的每一元素本身都是一维 向量,故通过默认赋值运算符,并不能复制向量内部的数据区。 为适应此类赋值操作的需求,可如代码2.3所示,重载向量的赋值运算符。 1 template Vector& Vector::operator=(Vector const& V ) { //重载赋值操作符 2 if (_elem) delete [] _elem; //释放原有内容 3 copyFrom(V._elem, 0, V.size()); //整体复刢 4 return *this; //迒回弼前对象癿引用,以便链式赋值 5 } 代码2.3 重轲向量赋值操作符 2.3.3 析构方法 与所有对象一样,不再需要的向量,应借助析构函数(destructor)及时清理(cleanup), 以释放其占用的系统资源。与构造函数不同,同一对象只能有一个析构函数,不得重载。 向量对象的析构过程,如代码2.1中的方法~Vector()所示:只需释放用于存放元素的内部 数组_elem[],将其占用的空间交还操作系统。_capacity和_size之类的内部变量无需做任何 处理,它们将作为向量对象自身的一部分被系统回收,此后既无需也无法被引用。 若不计系统用于空间回收的时间,整个析构过程只需O(1)时间。 同样地,向量中的元素可能不是程序语言直接支持的基本类型。比如,可能是指向动态分配 对象的指针或引用,故在向量析构之前应该提前释放对应的空间。出于简化的考虑,这里约定并 遵照“谁申请谁释放”的原则。究竟应释放掉向量各元素所指的对象,还是需要保留这些对象, 以便通过其它指针继续引用它们,应由上层调用者负责确定。 §2.4 动态空间管理 2.4.1 静态空间管理 内部数组所占物理空间的容量,若在向量的生命期内不允许调整,则称作静态空间管理策略。 很遗憾,该策略的空间效率难以保证。一方面,既然容量固定,总有可能在此后的某一时刻,无 法加入更多的新元素即导致所谓的上溢(overflow)。例如,若使用向量来记录网络访问 日志,则由于插入操作远多于删除操作,必然频繁溢出。注意,造成此类溢出的原因,并非系统 不能提供更多的空间。另一方面反过来,即便愿意为降低这种风险而预留出部分空间,也很难在 程序执行之前,明确界定一个合理的预留量。以上述copyFrom()方法为例,即便将容量取作初 始规模的两倍,也只能保证在此后足够长的一段时间内(而并非永远)不致溢出。 向量实际规模与其内部数组容量的比值(即_size/_capacity),亦称作装填因子(load factor),它是衡量空间利用率的重要指标。从这一角度,上述难题可归纳为: 如何才能保证向量的装填因子既不致于超过1,也不致于太接近于0? 为此,需要改用动态空间管理策略。其中一种有效的方法,即使用所谓的可扩充向量。

网友评论