Memory leak patterns in javascript

Memory leak patterns in javascript

• 1.
  Memory leaks in Javascript:  JavaScript is garbage collected language, meaning that memory is allocated to objects upon  their creation and reclaimed by the browser when there are no more references to them. While  there is nothing wrong with JavaScript's garbage collection mechanism, it is at odds with the  way some browsers handle the allocation and recovery of memory for DOM objects.  Internet Explorer and Mozilla Firefox are two browsers that use reference counting to handle  memory for DOM objects.     In a ​reference counting system​, each object referenced maintains a count of how many  objects are referencing it. If the count becomes zero, the object is destroyed and the memory is  returned to the heap. Although this solution is generally very efficient, it has a blind spot when  it comes to circular (or ​cyclic​) references.    Memory Leak Patterns and their solutions:  There are four common memory leak patterns as listed below:  ● Circular References​—When mutual references are counted between Internet Explorer's  COM infrastructure and any scripting engine, objects can leak memory. This is the  broadest pattern.    ● Closures​—Closures are a specific form of circular reference that pose the largest pattern  to existing Web application architectures. Closures are easy to spot because they rely on  a specific language keyword and can be searched for generically.    ●Cross­Page Leaks​—Cross­page leaks are often very small leaks of internal book­keeping  objects as you move from site to site. We'll examine the DOM Insertion Order issue,  along with a workaround that shows how small changes to your code can prevent the  creation of these book­keeping objects.    ● Pseudo­Leaks​—These aren't really leaks, but can be extremely annoying if you don't  understand where your memory is going. We'll examine the script element rewriting  and how it appears to leak quite a bit of memory, when it is really performing as  required.    Circular Reference Pattern: 
• 2.
  JavaScript Objects and DOM ​elements that store references to one another​ cause Internet  Explorer’s garbage collector to not reclaim memory, resulting in memory leaks.  A circular reference is formed when two objects reference each other, giving each object a  reference count of 1. In a purely garbage collected system, a circular reference is not a  problem: If neither of the objects involved is referenced by any other object, then both are  garbage collected. In a reference counting system, however, neither of the objects can be  destroyed, because the reference count never reaches zero and is always one due to the  mutual references.                                         
• 3.
  To break the leak pattern you can make use of ​explicit null assignments​. By assigning null  before the document unloads you are telling the script engine there is no longer an association  between the element and the object inside the engine. It can now properly clean up references  and will release the DOM element.  Closures  One of JavaScript's strengths is that it ​allows functions to be nested within other functions​. A  nested, or inner, function can ​inherit the arguments and variables of its outer function​, and is  private to that function.  Normally, a function's local variables and the parameters used when calling a function only  exist for the lifetime of the function itself. With closures, these variables and parameters  continue to have an outstanding reference as long as the closure is alive, and since closures can  live beyond the lifetime of their parent function so can any of the locals and parameters in that  function.                   
• 4.
  Example 1:                  Cross Page Leaks                                
• 5.
    Example 2:  Leak Model:   Non­leak Model:                            Cross Page Leaks:  Leaks that are based on order of insertion are almost always caused by the creation of  intermediate objects that don't get cleaned up properly. That is exactly the case when creating  dynamic elements and then attaching them to the DOM. The basic pattern is attaching two  dynamically created objects together temporarily which creates a scope from the child to the  parent element. Later, when you attach this two­element tree to the primary tree, they both  inherit the scope of the document and a temporary object is leaked. The following diagram shows  two methods for attaching dynamically created elements to the tree.  In the ​first model, attach each child element to its parent,​ and finally attach the entire subtree to the  primary tree. This method can cause leaks through temporary objects if other conditions are met. 
• 6.
  In the ​second model, we attach elements into the primary tree ​working our way from top­level  dynamically created element down through all of the children. Because each attachment inherits the  scope of the primary document we never generate temporary scopes.    Leak Model:                     
• 7.
      When we append childDiv to parentDiv, a temporary scope from childDiv to parentDiv  is created which will leak a temporary script object.  Non­Leaking model:                                  Pseudo Leaks:  Like the DOM Insertion Order issue, this pseudo leak issue also relies on the creation of temporary  objects in order to "leak" memory. By rewriting the script text inside of a script element over and  over again, slowly you'll begin to leak various script engine objects that were attached to the 
• 8.
  previous contents. Pseudo­leaks almost always appear on the same page during dynamic scripting  operations and should rarely be visible after navigation away from the page to a blank page.                          If you run the above code and use the Task Manager trick again, while navigating between the  "leaking" page and a blank page, you won't notice a script leak. This script leak is entirely within a  page and when you navigate away then you get your memory back. The reason this one is bad is  due to expected behavior. You expect that after rewriting some script that the original script  won't stay around. But it really has to, because it might have been used already for event  attachments and there might be outstanding reference counts.