关于javascript:JavaScript高级程序设计笔记04-变量作用域与内存

变量、作用域与内存

变量

特定工夫点一个特定值的名称。

• 分类

  • 原始值：按值拜访

    • 复制：两个独立应用、互不烦扰

  • 援用值（由多个值形成的对象）：按援用拜访

    操作对象时，实际上操作的是对该对象的援用（reference）而非理论的对象自身

    • 复制：复制的值实际上是一个指针，指向存储在 堆内存 中的对象。实际上两个变量指向同一个对象
    • 函数传参：都是按值传递，如果是援用值，就跟援用值变量的复制一样

• 判断类型

  • typeof

    最适宜用来判断一个变量是否为原始类型，对援用值的用途不大。

  • instanceof

    什么类型的对象（由对象的原型链决定）

作用域

• 执行上下文

  变量或函数的上下文决定了它们能够拜访哪些数据，以及它们的行为。每个上下文都有一个关联的 变量对象（variable object），而这个上下文中定义的所有变量和函数都存在于这个对象上。

  全局上下文是最外层的上下文。依据 ECMAScript 实现的宿主环境，示意全局上下文的对象可能不一样。在浏览器中，就是常说的 window 对象。

  上下文在其所有代码都执行结束后会被销毁，包含定义在它下面的所有变量和函数。

  上下文栈。当代码执行流进入函数时，函数的上下文被推倒一个上下文栈上；在函数执行结束之后，上下文栈会弹出该函数上下文，将控制权返还给之前的执行上下文。

  作用域链（scope chain）。决定了各级上下文中的代码在拜访变量和函数时的程序。代码正在执行的上下文的变量对象始终位于作用域链的最前端；全局上下文的变量对象始终是作用域链的最初一个变量对象。上下文之间的连贯是线性的、有序的，外部能够拜访内部，内部无法访问外部。

  函数参数被认为是以后上下文中的变量。

  标识符解析。搜寻过程始终从作用域链的最前端开始，逐级往后，直到找到或者达到最初端。

  部分作用域中定义的变量会产生遮蔽（下层同名变量）成果，援用全局变量能够应用齐全限定的写法：window.propName。

• 加强作用域链

  在作用域链前端长期增加一个上下文。

  • try/catch 的 catch 语句：创立一个新的变量对象（蕴含要抛出的谬误对象的申明）
  • with：增加指定的对象

  eval()：批改作用域链。

• 不同关键字的申明

  • var

    通过 var 定义的全局变量和函数都会成为 window 对象的属性和办法。

    应用 var 申明变量时，变量会被主动增加到最靠近的上下文。

    会导致变量申明被晋升，在（代码中）变量申明之前就能够拜访到变量。

  • let/const

    顶级申明不会定义在全局上下文中，但在作用域链解析上成果是一样的。

    块作用域由最近的一对蕴含花括号界定。不能反复申明。

    const 申明不能从新赋值，繁多类型且不可批改。

    V8 引擎针对 const 的优化：const 申明的变量都替换成理论的值，而不通过查问表进行变量查找。

• 变量查找（作用域链）

  标识符查找：部分上下文 -> 沿作用域链

  拜访局部变量比全局变量要快，因为不必切换作用域。

垃圾回收。GC

执行环境负责在代码执行时治理内存（内存调配和闲置资源回收）。

基本思路：确定哪个变量不会再应用，而后开释它占用的内存。此过程是周期性的，每隔肯定工夫就会主动运行。（近似且不完满的计划，是否还有用属于“不可判定”的问题。不是所有时候都会很显著）

• 如何 标记未应用的变量，两种次要的标记策略：

  • 标记清理 mark-and-sweep：最罕用

    过程：

    1. 标记内存中存储的所有变量；
    2. 将所有在上下文中的变量，以及被在上下文中的变量援用的变量的标记去掉；
    3. 之后再被加上标记的变量，就是待删除的了，因为任何在上下文中的变量都拜访不到它们了；
    4. GC 程序做一次内存清理，销毁带标记的所有值并发出它们的内存。

  • 援用计数 reference counting

    GC 下次运行的时候会开释援用数为 0 的值的内存。

    重大的问题：循环援用。典型：IE8 及更早版本的 BOM 和 DOM（应用 COM 对象）。

    应该在确保不应用的状况下切断原生 JavaScript 对象与 DOM 元素之间的连贯。

    把变量设置为 null实际上会切断变量与其之前援用值之间的关系。

• GC 调度（性能）

  最好的方法：写代码时做到，无论什么时候开始收集垃圾，都能让它尽快完结工作

  古代 GC 程序会基于对 JavaScript 运行时环境的探测来决定何时运行。

  探测机制：基本上是依据已调配对象的大小和数量来判断。（V8 的堆增长策略：依据沉闷对象的数量外加一些余量来确定何时再次垃圾回收。）

  不举荐被动触发垃圾回收。（某些浏览器能够）

  • 缩小 GC 次数（缩小不合理调配）
  • 尽快实现回收

• 内存治理

  调配给浏览器的内存通常比调配给桌面软件的要少很多，调配给挪动浏览器的更少。——> 次要出于平安思考，防止运行大量 JavaScript 的网页耗尽零碎内存而导致操作系统解体。

  这个内存限度不仅影响变量调配，也影响调用栈以及可能同时在一个线程中执行的语句数量。

  内存占用量放弃在一个较小的值能够让页面性能更好。优化内存占用的最佳伎俩：保障在执行代码时只保留必要的数据。如果数据不再必要就解除援用（设置为 null）——尤其是全局变量和全局对象的属性，下次垃圾回收时会被回收。

  • 利用 let/const 提前回收：块作用域比函数作用域更早终止

  • v8 引擎的暗藏类：几个实例共享同一个构造函数和原型。

    给实例减少新属性或删除其属性，就不能共享一个暗藏类。——最佳实际：不想要的属性设置为 null，达到删除援用值供 GC 程序回收的成果。

    防止“先创立再补充”式的动静属性赋值。

  • 内存透露

    1. 意外申明全局变量
    2. 闭包

  • 动态调配与对象池（正当调配，防止多余 GC：保住因开释内存而损失的性能）

    缩小浏览器执行垃圾回收的次数。

    浏览器决定何时运行 GC 程序的一个规范，就是对象更替的速度。——》一个策略：应用对象池（治理一组可回收的对象）

    可应用数组来保护，但必须注意不要导致额定的垃圾回收。