3. Set your XMLHttpRequest onreadystatechange handlers to null when you are done with them.

I use YAHOO.util.Connect for all my XHR connections and it uses a
polling mechanism instead of readstate, so I don’t need to do this
anymore. If you can switch to YAHOO.util.Connect (or
YAHOO.ext.UpdateManager built on top of it), I’d recommend it.

2. Clean up all your DOM event handlers on unload if there’s a chance they could reference a DOM object.

There’s no reason to manually do this when there are libraries that
do it automatically. I use YAHOO.util.Event for all my event handlers,
it handles this for me automagically. Other libraries (prototype, dojo,
etc) have some sort of mechanism to do the same thing, although I’m not
sure how effective they are. If you look at the leak images above once
again, you will notice almost all of them are in event related code of
those libraries.

1. Never put anything in a DOM expando or property other than a primitive value unless you plan on cleaning it up.

This is the most important rule of all. It may seem convenient to
put your JS object in a DOM expando, so you can $() and get it, but
don’t do it. Sure, I know what you are thinking, I am being a little
paranoid. There are lots of instances where putting a JS Object in a
DOM expando won’t cause a leak. That’s true, but there are also
many that will… some which are not so easy to detect (i.e. closures).
So to avoid the possibility all together, I follow this simple rule.

อ้างอิง: 3 Easy Steps to Avoid JavaScript Memory Leaks

บทความที่เกี่ยวข้อง

• Linux Console Command Part1
• Zend Framework Preview 0.2.0 Released!
• Zend Studio 5.5 Beta Available Now!.
• How to disable Tab Scrolling in FireFox 2.0
• วิธีแก้ปัญหา PHP ส่งอีเมล์ไม่ได้บน Windows