JavaScript 闭包详解

3,021

闭包(Closure)是前端开发者经常会听到的一个概念,也是我们在求职面试中经常会遇到的题目之一。透过表象去理解闭包的本质,对前端开发者来说是进阶的必经之路。

闭包跟执行上下文中的变量对象和作用域链有着千丝万缕的关系,深刻理解变量对象以及作用域链对理解闭包的本质有很大的帮助。

MDN 中对闭包的定义是:闭包是函数和声明该函数的词法环境的组合。

我认为 MDN 中对闭包的定义比较抽象以致并不能让我们很清楚地知道闭包是什么东西。在这里我直接给闭包做一个我认为比较本质且好理解(前提当然是你对执行上下文系列已经有相应的了解啦)的定义:闭包是指其所在执行上下文已经出栈,但仍访问了其所在执行上下文变量对象的函数

我们经常问,闭包是什么?其实从上述的定义我们可以很简单地知道,闭包是一个函数。但跟普通的函数不一样,闭包是具有特殊能力的函数。

从上述的定义我们可以知道,闭包具有两个特点,即

  • 其所在执行上下文已经出栈
  • 访问了其所在执行上下文变量对象

这里需要注意的是,「其所在执行上下文」指的是闭包所在函数对应的执行上下文,而不是指闭包本身所对应的执行上下文。

一个简单的能够产生闭包的例子是,在函数 A 中创建了函数 B 并且返回函数 B,当函数 B 执行时,如果访问了 A 中的变量,则产生了闭包。

//一个简单的产生闭包的例子
function A(){
    var a = 2;
    function B(){
        console.log(a)
    }

    return B;
}

A()();  // 2

在大部分书中,对闭包的概念解释为:能够读取其它函数内部变量的函数。在上述的简单例子中,即以函数 B 指代闭包,在我们平时开发过程中,也经常会以函数 B 来指代闭包。而在 Chrome 的开发者工具中,则会以函数 A 指代闭包。

那么,闭包的本质又是什么呢?

我们都知道,JavaScript 拥有自动的垃圾回收机制,当一个值失去引用的时候,垃圾回收机制会根据特殊的算法找到它并将其回收。

函数的执行上下文在出栈后,其变量对象会失去引用等待被回收,而闭包的存在会阻止这一过程,因为闭包的作用域链包含了其所在执行上下文的变量对象。

举个例子来说明其中的过程,假设有一个 JavaScript 文件中包含如下代码

var a = 1;
function fn1(){
    var b = 2;
    function fn2(){
        return b;
    }
    
    return fn2;
}

var fn2=fn1();
fn2();

在代码执行过程中,执行上下文栈的行为如下

/*伪代码*/
// 代码执行时最先进入全局环境,全局上下文被创建并入栈
ECStack.push(globalContext);
// fn1 被调用,fn1 函数上下文被创建并入栈
ECStack.push(<fn1> functionContext);
// fn1 执行完毕,fn1 函数上下文出栈
ECStack.pop();
// fn2 被调用,fn2 函数上下文被创建并入栈
ECStack.push(<fn2> functionContext);
// fn2 执行完毕,fn2 函数上下文出栈
ECStack.pop();
// 代码执行完毕,全局上下文出栈
ECStack.pop();

从执行上下文栈的行为我们可知,在 fn2 函数执行的时候,其实 fn1 上下文已经出栈了,按照 javascript 的垃圾回收机制,fn1 上下文的变量对象失去引用后会被垃圾回收机制回收,但由于在 fn2 上下文的作用域链包含了 fn1 上下文的变量对象,所以 fn1 上下文的变量对象不会被垃圾回收机制回收。

我在之前的文章说过,函数作用域是在函数被定义(声明)的时候确定的。每一个函数都会包含一个 [[scope]] 内部属性,在函数被定义的时候,该函数的 [[scope]] 属性会保存其上层上下文的变量对象,形成包含上层上下文变量对象的层级链。

从代码中可知,在 fn2 函数被定义的时候,其上层上下文包括了 fn1 上下文和全局上下文

fn2.[[scope]]=[fn1Context.VO,globalContext.VO]

当 fn2 被调用的时候,其执行上下文被创建并入栈,此时会生成变量对象并将该变量对象添加进作用域链的顶端,并且将 [[scope]] 添加进作用域链

fn2Context.Scope=[fn2Context.VO].concat([[scope]])
=>
fn2Context.Scope=[fn2Context.VO,fn1Context.VO,globalContext.VO]
即
fn2Context={
    scope:[fn2Context.VO,fn1Context.VO,globalContext.VO]
}

可见,fn2 上下文的作用域链中包含了 fn1 上下文的变量对象,并且由于 fn2 访问了 fn1 中的变量,所以阻止了 fn1 上下文的变量对象被垃圾回收机制回收。

让我们来看一个面试题经常会遇到的一个关于闭包的很经典的题目~

var arr = [];
for (var i = 0; i < 3; i++) {
    arr[i] = function () {
        console.log(i);
    };
}

arr[0]();
arr[1]();
arr[2]();

求出上面代码三个函数的输入结果。

如果对前面执行上下文系列文章已经理解透彻的童鞋,应该能够很容易得出,三个函数都是输出 3 。让我们来分析一波~

在 arr[0] 函数执行之前,我们可以知道,全局上下文的变量对象如下所示

globalContext = {
    VO: {
        arr: [...],
        i: 3
    }
}

在 arr[0] 被调用执行时,其作用域链在函数上下文的创建阶段被创建,其作用域链如下

arr[0]Context = {
    Scope: [arr[0]Context.VO, globalContext.VO]
}

根据作用域链,arr[0] 函数会现在自身的变量对象中寻找 i ,如果找不到,会到全局上下文变量对象中寻找 i,所以最终输出 3 。

arr[1]、arr[2] 的分析与上述一致。

那么怎么使上述三个函数的输出结果是 0 1 2 呢?

一个经典的解决方式是通过闭包来实现,代码如下

var arr = [];
for (var i = 0; i < 3; i++) {
    arr[i] = (function (i) {
        return function(){
            console.log(i);
        }
    })(i);
}

arr[0]();  //  0
arr[1]();  //  1
arr[2]();  //  2

同样地,在 arr[0] 函数执行前,全局上下文的变量对象跟之前一样没有任何变化。

而在 arr[0] 被调用执行时,其作用域链在函数上下文的创建阶段被创建,其作用域链如下

arr[0]Context = {
    Scope: [arr[0]Context.VO, 匿名函数Context.VO, globalContext.VO]
}

可以看到其作用域链发生了变化,arr[0] 的变量对象之后紧跟着匿名函数的变量对象

匿名函数Context = {
    VO: {
        Arguments:{
            0:0,
            length:1
        },
        i: 0
    }
}

在匿名函数的变量对象中,能找到访问的变量 i,所以得到 i 值为 0.

arr[1]、arr[2] 的分析与上述一致,得到的 i 值分别为 1、2 。

通过闭包,我们能够访问其它函数上下文的变量对象

在实践中,闭包的应用场景很多,但其都是依据闭包能够访问其它函数上下文的变量对象的特性。

闭包能够被应用在模块化中:

;(function(){
    var a=1;
    var addOne=function(x){
        return x+a;
    }
    window.addOne=addOne;
})()

console.log(addOne(2));  // 3

如上是通过函数自执行以及闭包实现模块化的一个例子,通过将函数添加到全局对象的方式将方法(这里是闭包)暴露出来,addOne 闭包访问了自执行函数中的变量 a 。

闭包能够被应用在柯里化中:

柯里化是一种将使用多个参数的一个函数转换成一系列使用一个参数的函数的技术。

柯里化的实现方式同样用到了闭包,在这边文章中不做多余的赘述,感兴趣的童鞋可以查阅柯里化的资料。

闭包的应用场景多种多样,我们可以通过闭包实现许多不同的功能。闭包的魅力,需要我们去理解其本质,并在实践中灵活地应用它。

闭包的征途,是星辰大海