代码判断一：
click me

执行之，不出意外的话所有浏览器都会卡死，因为上面的for循环次数太多了，非常耗费cpu资源，而基于javascript单线程的事实，浏览器ui渲染被挂起而导致假死。
现在问题来了，我就是想要实现上述代码，怎么办？
concurrent.thread.js
该类库实质上还是使用settimeout来实现一个“假的多线程”。在html5 webworker问世之前是一个很好的选择。比如我们要实现上述“代码片段一”，可以这样写（点我下载类库）：
代码片段二：
click me

通过该类库提供的create方法可以创建一个“新线程”。另外，给script标签的type属性设置为 text/x-script.multithreaded-js 也可以实现同样的效果：
代码片段三：
click me

webworker
针对以上浏览器卡死这种糟糕的用户体验，html5怎么会熟视无睹呢？
下面我们用经典的斐波那契数列来做测试：
代码片段四：
主页面：
fibonacci.js：var fibonacci=function (n){ return n<3?n:(arguments.callee(n-1)+arguments.callee(n-2));}onmessage=function(e){ var num=parseint(e.data,10); postmessage(fibonacci(num));//向主页面发送数据}
基本的使用方法已在代码中做注释了，查看控制台，可以看见很快就打印出执行时间了。所以我们得出的结论是：webworker适合在前端执行复杂的大量的计算。需要注意的是，webworker不支持跨域，本地测试还是用http协议，不要用file协议，否则不能创建worker对象而报脚本错误 。
如果我们需要连续执行多个postmessage操作，最好不要work.postmessage一直写，像这样：
worker.postmessage(36); worker.postmessage(36); worker.postmessage(36);
因为此时只有一个webworker实例，postmessage会顺序执行而不是异步执行，就不能充分发挥它的性能了。可以通过创建多个webworker实例来发送数据。
        需要注意的几点事项有：
        1、我们观察到webworker通过接受一个url来创建一个worker，而jsonp的实现原理就是通过动态插入script标签加载数据，那我们尝试用webworker来实现同样的事情不是更好吗？因为webworker是多线程的，没有阻塞，岂不美哉？但实际上经过实验，我们发现webworker表现并不如意。所以这并不是它擅长的事，我们还是不要让它越俎代庖的好。
        2、webworker在接受其他来源信息的时候，其实也给站点的安全带来了隐患，如果接收不明来源的脚本信息，可能会导致xss注入攻击。所以这点需要防范，其实我们上面例子中使用innerhtml是不安全的，可以使用innertext或现代浏览器提供的textcontent来替代，以过滤掉html标签。
今天比较累了，想睡觉了，先写这么多吧。