Let’s talk in detail about how browsers view closures

Preface

Closures are a major difficulty in understanding JavaScript. There are many articles about closures on the Internet, but there are few articles that can make people fully understand them after reading them. The reason, I think, is that closure involves a series of knowledge points. Only by thoroughly understanding this series of knowledge points and achieving a closed loop of a concept can you truly understand it. Today I plan to understand closures from a different perspective, from the perspective of memory allocation and recycling, hoping to help you truly digest the closure knowledge you have seen. At the same time, I also hope that this article will be the last article you read about closures.

When you look at the pictures in this article, please keep in mind the direction of the arrows. Because it is the principle that the root object window relies on to traverse memory garbage, anything that can be found along the arrow starting from the window is not memory garbage and will not be recycled. Only those objects that cannot be found are memory garbage and will be recycled by GC at the appropriate time.

Introduction to Closures

When functions are nested, the inner function references the variables in the outer function scope, and the inner function is referenced by the variables in the global environment, thus forming a closure.

Closures are essentially a byproduct of function scope.

One thing we need to pay special attention to about closures is that all functions defined inside a function share the same closure object. What does it mean? Look at the following code:

var a
function b() {
  var c = new String('1')
  var d = new String('2')
  function e() {
    console.log(c)
  }
  function f() {
    console.log（d）
  }
  return f
}
a = b()

In the above code, f references the variable d, and f is referenced by the external variable a, so a closure is formed, causing the variable d to remain in the memory. Let's think about it, what about variable c? It seems that we didn't use c, so it shouldn't stay in the memory. Then there is the fact that c will also linger in memory. The closure formed by the above code contains two members, c and d. This phenomenon is called intra-function closure sharing.

Why do we need to pay special attention to this feature? Because of this feature, it is easy to write code that causes memory leaks if we are not careful.
I have said so much about the concept of closures, but if you really want to understand closures, you still need to understand a few knowledge points.

• Function scope chain
  
• Execution Context
  
• Variable object, activity object

You can search these contents on Google or Baidu to get a general understanding. Next I will talk about how to understand closures from the browser's perspective, so I won't explain it in detail.

How to identify memory garbage

The garbage collection process of modern browsers is relatively complicated. You can google the detailed process yourself. Here I will only talk about how to determine memory garbage. Generally speaking, it can be understood that starting from the root object, anything that can be found by following the reference cannot be recycled. Objects that cannot be found by following the reference are considered garbage and are recycled at the next garbage collection node. Looking for garbage can be understood as a process of following the clues.

Memory representation of closures

Starting with the simplest code, let's look at the global variable definition.

var a = new String('小歌')

Such a piece of code is represented in memory as follows

In the global environment, a variable a is defined and a string is assigned to it. The arrow indicates a reference.

Let's define another function:

var a = new String('小歌')
function teach() {
  var b = new String('小谷')
}

The memory structure is as follows:

Everything is easy to understand. If you are careful, you will find that there is an attribute called [[scopes]] in the function object teach. What is this? Why does this attribute appear after the function is created? I'm glad you asked this, it's a key point to understand closures.

Please remember: Once a function is created, the JavaScript engine will attach a property called scope chain to the function object. This property points to an array object that contains the function's scope and parent scope, all the way to the global scope.

So the above figure can be simply understood as: the teach function is created in the global environment, so the scope chain of teach has only one layer, that is, the global scope global

It should be clear that in the browser, global refers to the window object, and in the nodejs environment, global refers to the global object.

Please remember again: When a function is executed, space is requested to create an execution context. The execution context includes the scope chain when the function is defined, and secondly includes the variables and parameters defined inside the function. When the function is executed in the current scope, it will first search for variables under the current scope. If it cannot be found, it will search in the scope chain when the function is defined until it reaches the global scope. If the variable cannot be found in the global scope, an error will be thrown.

We all know that when a function is executed, an execution context is created, which is actually applying for a memory space of a stack structure. The local variables in the function are allocated in this space. After the function is executed, the local variables are recycled at the next garbage collection node. OK, let's update the code again and take a look at the memory structure when the function is running.

var a = new String('小歌')
function teach() {
  var b = new String('小谷')
}
teach()

The memory is represented as follows:

Obviously, we can see that the function only assigns a local variable during execution and has no relationship with the variables in the global environment. Therefore, if we search from the window object along the reference (arrow in the figure), we cannot find the variable b in the execution context. Therefore, after the function is executed, the variable b will be recycled.

Let's update the code again:

var a = new String('小歌')
function teach() {
  var b = new String('小谷')
  var say = function() {
    console.log(b)
  }
  a = say
}
teach()

The memory is represented as follows:

Note: Gray indicates objects that cannot be tracked from the root object.

Function execution order:

1. Before the teach function starts executing, stack space is requested, as shown in the blue square in the figure above.
2. Create a context scope (a stack-like structure) and push the [[scopes]] defined in the teach function into the scope.
3. Initialize variable b (variable promotion), create function say, initialize the scopes property of say, and first push the scopes of function teach into [[scopes]] of function say. Since say refers to the variable b, a closure is formed. So we also need to push the closure object into the [[scopes]] of the function say.
4. Create a variable object local to point to local variables b and say, and push local into the scope of step 2.
5. Function starts executing
   1. Assign the string object 'Xiaogu' to variable b.
   2. Set the global variable a to point to the function say.

After the function is executed, variable b should be released under normal circumstances. However, we find that we can find b by searching along the window. According to the principle of determining memory garbage we mentioned earlier, b is not memory garbage, so b cannot be released. This is why closures keep variables within functions in memory.

Upgrading the code again, let's look at the memory representation shared by the closure:

var a = new String('0')
function b() {
  var c = new String('1')
  var d = new String('2')
  function e() {
    console.log(c)
  }
  function f() {
    console.log（d）
  }
  return f
}
a = b()

The gray graphics are memory garbage and will be recycled by the garbage collector.

It is easy to see from the above figure that although function f does not use variable c, c is referenced by function e, so variable c exists in the closure closure. Variable c can be found by starting from the window object, so variable c cannot be released.

You may ask, how can this feature lead to memory leaks? Well, consider the following code, a classic meteor memory leak problem.

        var t = null;
        var replaceThing = function() {
            var o = t
            var unused = function() {
                if (o)
                    console.log("hi")
            }
            t = {
                    longStr: new Array(1000000).join('*'),
                    someMethod: function() {
                      console.log(1)
                    }
                }
        }
        setInterval(replaceThing, 1000)

This code has a memory leak. If you execute this code in the browser, you will find that the memory keeps rising. Although GC releases some memory, there is still some memory that cannot be released, and it rises in a gradient. As shown below

This curve indicates that there is a memory leak. We can use developer tools to analyze which objects have not been recycled. In fact, I can tell you that the memory that is not released is actually the large object t we create each time. Let’s take a look at this by drawing a picture:

The above picture assumes that the replaceThing function is executed three times. You will find that each time we assign a large object to the variable t, due to closure sharing, the previous large object can still be tracked from the window object, so these large objects cannot be recycled. In fact, what is really useful to us is the large object assigned to t last time, so the previous object caused a memory leak.

As you can imagine, if we don't realize this and let the program run, the browser will crash soon.

The solution to this problem is also very simple. Each time the code is executed, set the variable o to null. You can try it.

Conclusion

This is the end of this article about how browsers view closures. For more information about how browsers view closures, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!