Chrome now offers much better tools to find memory leaks, than at the time of most answers.
Here is to find memory leaks in javascript with a recent Chrome browser:

1. Press F12 to open the developer tools and go to the Memory Tab.

1. Pick a feature or a part of your app that you want to inspect for leaks. For example, when a dialog is opened and closed again, the memory used by it should be released.
2. Do the action (for example opening a dialog) you want to check for memory leaks once, so potential global services can be loaded. This prevents these objects, that are intentionally preserved from showing up as leaks.
3. Now select Record Allocation Timeline and press Start. Repeat the action you want to check for leaks a few times. So for example open a dialog, close it and repeat. While you do this Chrome draws the timeline with partially grey or blue bars. Usually you see a bar for each time you performed the action on your page. When the bar from several previous iterations of the action stays partially blue it usually means there is a memory leak. The blue part of the bar represents memory that was allocated at this time and has not yet been released again. Stop the recording by pressing the red dot on the top left of the developer tools.

1. When you see potential leaks you have to inspect this part of the timeline to find the source. Select a part of the timeline that is a few iterations of your actions in the past. And Chrome will show a list of object-types that are still present in the memory. The retained size column gives you an impression how much memory is still used. Browse into one of the object-types and select an object. If you do that, the list of retainers will appear below.

1. The list of retainers shows the "parent" objects that reference the selected object. Now you need to look at the retainers and your code to understand why the memory has not been released. For example in the image you see the object of the type scope. The second line says the scope is "context in initFormat()". The problem was that initFormat was an event listener that was not unbound after a dialog was left.
2. After you fixed your code check if the problem has been solved. Refresh the page and repeat the steps 3 to 6 again. If you have never checked for memory leaks before it is not unlikely that you find multiple problems.

Additional hints:

• Sometimes there are caches that retain a part of the memory. Usually you can ignore them.
• When you see the HTMLDivElement or other DOM elements in the list of object-types have a look. If the objects in this list are highlighted red it means they are no longer present in your page. This means they must be reference somewhere in the code. You may have forgotten to unbind an event listener.
• Read about memory leaks in general , so you can identify them quicker in your code.

In Chrome developer tools, there is a Timeline - Memory tab:

We can watch the memory occupied by it.
There is also Profiles - Memory, where we can take a snapshot and see what’s inside. Snapshots can be compared to each other:

Most of time, it doesn’t tell you anything. But at least you can see which objects are piling up, and probably the structure of the leak.
Other way is using 'Task Manager' here is an article regarding this:
http://www.javascriptkit.com/javatutors/closuresleak/

Google为此开源了一个工具leak-finder-for-javascript，他们还提出了一种所谓的三快照技术（也可参见this article中的简要描述）。
First paragraph of the leak-finder link

注意：jsleakcheck不再受支持！它是针对一个非官方的、不稳定的开发工具协议来获取堆快照的。该协议正在改进中，它还不够稳定，我无法让jsleakcheck在各种Chrome版本中工作。此外，jsleakcheck用来与开发工具通信的一个较低级别的兼容性工具remote_inspector_client.py被删除了。

我发现这篇文章很有见地：
http://addyosmani.com/blog/taming-the-unicorn-easing-javascript-memory-profiling-in-devtools/
它确实广泛地涵盖了Chrome开发人员工具，并非常好地解释了当您的应用程序似乎有内存问题时如何进行。

引自JavaScript Kit：
如果你正在开发客户端可重用的脚本对象，迟早你会发现自己发现了内存泄漏。很有可能你的浏览器会像海绵一样吸收内存，你很难找到一个原因来解释为什么你可爱的DHTML导航在访问了网站中的几个页面后，响应速度会严重下降。
微软开发人员贾斯汀·罗杰斯描述了IE泄漏模式in his excellent article（来自web.archive.org）。
在本文中，我们将从稍微不同的Angular 来回顾这些模式，并用图表和内存利用率图来支持它。我们还将介绍几种更微妙的泄漏场景。在开始之前，如果你还没有读过那篇文章，我强烈建议你读一读。

为什么内存泄漏？

内存泄漏的问题不仅仅局限于Internet Explorer。几乎任何浏览器（包括但不限于Mozilla、Netscape和Opera）都会发生内存泄漏，只要你提供足够的条件（而且这并不难做到，我们很快就会看到）。但是（以我的拙见，ymmv等）Internet Explorer是泄漏者之王。
不要误会我的意思。我不属于那群大喊“嘿，IE有内存泄漏，检查这个新工具[链接到工具]，看看自己”的人。让我们讨论一下IE浏览器有多糟糕，并掩盖其他浏览器的所有缺陷。
每种浏览器都有自己的优点和缺点，比如Mozilla在初始 Boot 时占用内存太多，不擅长字符串和数组操作;如果您编写的DHTML脚本过于复杂，会混淆其呈现引擎，Opera可能会崩溃。
虽然我们将重点讨论Internet Explorer中的内存泄漏情况，但此讨论同样适用于其他浏览器。
continue reading...

下面是一个很好的帖子，介绍如何使用Google Developper工具查找内存泄漏：http://gent.ilcore.com/2011/08/finding-memory-leaks.html
下面是另一个很好的网页：http://javascript.crockford.com/memory/leak.html

我没有看到提到的window.performance.memory，它为您提供了运行时监视能力，并根据内存使用情况采取行动。

window.performance.memory:

MemoryInfo {
  totalJSHeapSize: 7084834,
  usedJSHeapSize: 6486770,
  jsHeapSizeLimit: 4294705152
}

要获得方便的百分比，请使用以下方法：

window.performance.memory.usedJSHeapSize / window.performance.memory.jsHeapSizeLimit

https://developer.mozilla.org/en-US/docs/Web/API/Performance/memory