JavaScript — 原型与原型链、垃圾回收
作者:互联网
目录
一、原型
1.原型prototype
我们所创建的每一个函数,解析器都会向函数中添加一个属性 prototype ,这个属性对应着一个对象,这个对象就是我们所谓的原型对象。
如果函数作为普通函数调用prototype没有任何作用,当函数以构造函数的形式调用时,它所创建的对象中都会有一个隐含的属性,指向该构造函数的原型对象,我们可以通过 __proto__ 来访问该属性。
原型对象就相当于一个公共的区域,所有同一个类的实例都可以访问到这个原型对象,我们可以将对象中共有的内容,统一设置到原型对象中。
当我们访问对象的一个属性或方法时,它会先在对象自身中寻找,如果有则直接使用,如果没有则会去原型对象中寻找,如果找到则直接使用
以后我们创建构造函数时,可以将这些对象共有的属性和方法,统一添加到构造函数的原型对象中,这样不用分别为每一个对象添加,也不会影响到全局作用域,就可以使每个对象具有这些属性和方法了。
function MyClass(){
}
//向MyClass的原型中添加属性a
MyClass.prototype.a = 123;
//向MyClass的原型中添加一个方法
MyClass.prototype.sayHello = function(){
alert("Hello")
}
let mc = new MyClass();
let mc2 = new MyClass();
let mc3 = new MyClass();
//向mc中添加属性a
mc.a = "我是mc中的a"
console.log(MyClass.prototype);
console.log(mc.__proto__ == MyClass.prototype); //true
2.constructor
原型对象中有一个 constructor,它指向函数对象。
function Person() {
}
var person = new Person()
console.log(person.__proto__ === Person.prototype) //true
console.log(Person.prototype.constructor===Person) //true
//获得对象的原型
console.log(Object.getPrototypeOf(person) === Person.prototype) // true
3.原型链
对象和对象之间也有关系。对象之间的继承关系,在JavaScript中是通过prototype对象指向父类对象,直到指向Object对象为止,这样就形成了一个原型指向的链条,专业术语称之为原型链。
原型对象也是对象,所以它也有原型,当我们在使用一个对象的属性或方法时,会先在自身寻找,自身如果有,则直接使用,如果没有则去原型对象中寻找,如果原型对象中有,则使用,如果没有去原型的原型中寻找,直到找到Object对象的原型,Object对象的原型没有原型,如果在Object中依然没有找到,则返回undefined。
4. in 和 hasOwnProperty()
使用 in 检查对象中是否含有某个属性时,如果对象中没有但是原型中有,也会返回true
可以使用对象的 hasOwnProperty() 来检查对象自身中是否含有该属性,使用该方法只有当对象自身中含有属性时,才会返回true。
function MyClass(){
}
//向MyClass的原型中添加属性a
MyClass.prototype.a = 123;
//向MyClass的原型中添加一个方法
MyClass.prototype.sayHello = function(){
alert("Hello")
}
let mc = new MyClass();
//向mc中添加属性a
mc.a = "我是mc中的a"
mc.age = 18;
//使用in检查对象中是否含有某个属性时,如果对象中没有但是原型中有,也会返回true
console.log("a" in mc);
//可以使用对象的hasOwnProperty()来检查对象自身中是否含有该属性,使用该方法只有当对象自身中含有属性时,才会返回true
console.log(mc.hasOwnProperty("age"));
二、垃圾回收(GC)
程序在运行过程中会产生垃圾,这些垃圾积攒过多以后,会导致程序运行速度变慢,所以我们需要一个垃圾回收的机制,来处理程序运行过程中产生的垃圾。
当一个对象没有任何的变量或属性对它进行引用,此时我们将永远无法操作该对象,此时这种对象就是一个垃圾,这种对象过多会占用大量的内存空间,导致程序运行变慢,所以这种垃圾必须进行清理。
在JS中有自动的垃圾回收机制,会自动将这些垃圾对象从内存中销毁,我们不需要也不能进行垃圾回收的操作,我们需要做的只是将不再使用的对象设置为 null 即可。
let obj = new Object()
obj = null
1.可达性
JavaScript 中主要的内存管理概念是 可达性。
简而言之,“可达”值是那些以某种方式可访问或可用的值。它们一定是存储在内存中的。
这里列出固有的可达值的基本集合,这些值明显不能被释放。这些值被称作 根(roots)。
- 当前执行的函数,它的局部变量和参数。
- 当前嵌套调用链上的其他函数、它们的局部变量和参数。
- 全局变量。
- (还有一些内部的)
如果一个值可以通过引用或引用链从根访问任何其他值,则认为该值是可达的。
比方说,如果全局变量中有一个对象,并且该对象有一个属性引用了另一个对象,则该对象被认为是可达的。而且它引用的内容也是可达的。
在 JavaScript 引擎中有一个被称作垃圾回收器的东西在后台执行。它监控着所有对象的状态,并删除掉那些已经不可达的。
举个例子:
// user 具有对这个对象的引用
let user = {
name: "John"
};
这里的箭头描述了一个对象引用。全局变量 “user” 引用了对象 {name: "John"} (为简洁起见,我们称它为 John)。John 的 “name” 属性存储一个原始值,所以它被写在对象内部。
如果 user 的值被重写了,这个引用就没了:
user = null;
John变成不可达的了。因为没有引用了,就不能访问到它了。垃圾回收器会认为它是垃圾数据并进行回收,然后释放内存。
2.两个引用
把 user 的引用复制给 admin:
// user 具有对这个对象的引用
let user = {
name: "John"
};
let admin = user;
重写 user 的值:
user = null;
重写 user 的值后,对象仍然可以被通过 admin 这个全局变量访问到,所以对象还在内存中。如果我们又重写了 admin,对象就会被删除。
3.相互关联的对象
如下例所示:
function marry(man, woman) {
woman.husband = man;
man.wife = woman;
return {
father: man,
mother: woman
}
}
let family = marry({
name: "John"
}, {
name: "Ann"
});
由此产生的内存结构:
到目前为止,所有对象都是可达的。
现在移除两个引用:
delete family.father;
delete family.mother.husband;
仅删除这两个引用中的一个是不够的,因为所有的对象仍然都是可达的。
但是,如果把这两个都删除,那么可以看到再也没有对 John 的引用了:
对外引用不重要,只有传入引用才可以使对象可达。所以,John 现在是不可达的,并且将被从内存中删除,同时 John 的所有数据也将变得不可达。
经过垃圾回收:
几个对象相互引用,但外部没有对其任意对象的引用,这些对象也可能是不可达的,并被从内存中删除。
family = null;
内存内部状态将变成:
"family" 对象已经不再与根相连,没有了外部对其的引用,所以它变成了一座“孤岛”,并且将被从内存中删除。
4.内部算法
垃圾回收的基本算法被称为 “mark-and-sweep”。
定期执行以下“垃圾回收”步骤:
- 垃圾收集器找到所有的根,并“标记”(记住)它们。
- 然后它遍历并“标记”来自它们的所有引用。
- 然后它遍历标记的对象并标记 它们的 引用。所有被遍历到的对象都会被记住,以免将来再次遍历到同一个对象。
- ……如此操作,直到所有可达的(从根部)引用都被访问到。
- 没有被标记的对象都会被删除。
一些优化建议:
- 分代收集(Generational collection)—— 对象被分成两组:“新的”和“旧的”。许多对象出现,完成它们的工作并很快死去,它们可以很快被清理。那些长期存活的对象会变得“老旧”,而且被检查的频次也会减少。
- 增量收集(Incremental collection)—— 如果有许多对象,并且我们试图一次遍历并标记整个对象集,则可能需要一些时间,并在执行过程中带来明显的延迟。所以引擎试图将垃圾收集工作分成几部分来做。然后将这几部分会逐一进行处理。这需要它们之间有额外的标记来追踪变化,但是这样会有许多微小的延迟而不是一个大的延迟。
- 闲时收集(Idle-time collection)—— 垃圾收集器只会在 CPU 空闲时尝试运行,以减少可能对代码执行的影响。
标签:对象,JavaScript,原型,垃圾,MyClass,prototype,引用 来源: https://blog.csdn.net/m0_59897687/article/details/122791746