alert在不同thread下(iframe)到底会怎样我倒是没有研究过 我把您的code改成 var $ = function(id){return document.getElementById(id);}; $('ifa').src = 'javascript:alert("A");alert("B")'; $('ifb').src = 'javascript:alert("C");alert("D")'; 我刚刚试的结果 意外发现FF下会先出现A(很快来不急按) 然後被C盖住 之後D 回到A 最後B 这有点两个alert一起出现的味道(只是被盖住了) IE的结果就是同一时间只有一个alert 然後ABCD 这跟browser的实作有关 我只能推断 FF的alert出现时 容许其他的thread的alert也出现 (不确定是 出现两个 一个被"盖住" 或是同一个alert box然後内容被取代 在我的FF中没办法用滑鼠移动alert box) 而IE的UI不容许这种情况出现 然後回到问题 在两个thread并行下 ACBD交叉出现我觉得是有可能的 (但我不知道哪个browser可以 也没试着去制造出来过) 但是在一个event-driven 的single thread中(前篇文章) 是不会发生的 一个callback只会执行完在去执行下一个 不会互相跳来跳去 ============== 各家浏览器对alert的实作略有不同 一般当alert出现时 产生alert那段程式会暂停 直到按了之後在继续 然而有些浏览器在alert出现时 会继续dispatch的动作 dispatch进去的handler中 如果是UI trigger的 他不会执行 但如果是non-UI 的event handler 像是ajax的callback 在某些browser中是会同时执行的 即使你的alert还挂在那里 所以用alert debug的习惯是非常不好的 在你还没按下时 可能有东西就跑起来了 以致於你alert出来的变数也有可能被影响 而看到错的值 真的用在application中更是有可能造成错误 (confirm,prompt等等都一样) 根据你甚麽时候按下去 你的那段程式才会继续跑 但是你的non-UI event在背後一样的dispatch然後fire (如page load,timeout) 所以希望大家改掉直接用这种东西当UI的习惯 避免不必要的timing issue 全部的UI都要自己兜出来比较好 === 这里就有现成的例子 刚刚用FF看 好像是CDAB (按掉CD时A或若隐若现) 如果你没有注意那个若隐若现的A 你就会以为他的顺序真的是CDAB这样 然而如果你改成console.log("A") 就会知道他的真正的顺序是ABCD 给大家参考:D ※ 引述《senser (彷佛曾经一起死过)》之铭言： : 跟大家分享一下 我对一般常见的browser处理javascript的认知 : 有错误请大家不吝指教 : 先回答标题好了 : 就我所知 目前javascript在browser的implementeation中 : 在一个"window"下中只有一个thread 在这种情况下 你可以说javascript是单一thread : 事实上大部分的时候 我们只要以这出发点来考虑问题就足够了 : 然而 如果你的页面中有iframe 他会有另外一个window去维护另一个thread : 在同网域下 他甚至可以存取相同的global物件 造成所谓的race condition : 在这种状况下 你可以说javascript 是 multi-thread 我想也是合理的 : ======================= : 所以说 与其讨论javascript到底是不是multi-thread : 其实应该讨论的问题是 browser的实作方式 : 首先我们开启一个页面 在这个window中会开启一个thread 处理包括 : 1.html的parse : 2.dispatching of events : 3.执行javascript : 然後在parse的过程中 如果遇到某些tag像是img, embed, iframe,object 等等 : 他会开启另外一个thread去下载,render,或是执行iframe里面的js等等 : 这也是为甚麽 我们会看到在load一个网页 下载图片是分开的 每张独立下载 独立显示 : 同时这种作法 也大大加速了我们显示整个网页的速度 : 而这和我们的问题有甚麽关系呢? : 在我们前端开发人员的圣经"High Performance Web Sites"中提到 : 我们应该尽量的把javascript放在网页的下面 : 为甚麽呢 因为在同一个window的single thread中 如果遇到<script> : html parsing的动作会停下来 直到 : 1.下载 javascript(如果是外部连结的话) : 2.parse : 3.执行 : 三个动作结束後 才会继续往下 : 如果这个javascript特别久 那下面网页就久久不parse,整个page loading就卡在那里 : 所以呢 你应该已经猜到 在你load page时 不同<script>间的javascript执行一定是分开 : 的 : 只有一段<script>跑完 才有机会继续往下parse HTML : 也才有机会遇到另外一个<script> 然後执行它 : 而这个部分 我相信每个人都可以直观的观察到 这是single thread的感觉 : 那为甚麽有人会提出这类的问题 : 我想主要是因为javascript的一些feature如ajax,timer,alert...等等造成困惑 : 要理解这些困惑 我们要先理解 javascript是怎麽被执行的 : 以下有两种状况会执行js : 1.page load时立刻执行的js : 2.event handler : 第一种我们已经讨论过了 很单纯的由上往下 一个一个来 : 第二肿 在js中我们都视为一种callback 当事件引发时 才会执行 : 在browser对js的处理中 它maintain一个queue叫做 "Dispatch Sequence" : 当事件触发时 会立刻把handler放到里面(这动作叫作dispatch) : 然後根据先来後到的顺序执行handler : 而在这过程中 当前一个handler没跑完之前 下一个hander不会被执行 : 所以说 js依然是single thread : timeout,或是ajax callback等等 我们都要视为是一个event 一样是用这个规则在跑 : 所以 timeout 5秒不一定会在5秒时跑 ajax callback也不一定会在respose 抵达时马上 : fire : 一切都要看 前面的handler执行完了没 轮到他了没 : (题外话 alert 是个special case, 每个browser不太一样 , 写js的人要尽量少用) : 那最後回到我们的问题来 : 那个alert ABCD会不会交叉出现呢 答案是不会 (alert要少用 像是sk1765的test case就 : 非常好) : 相信你已经知道 在timeout中的function A B都是一个event handler(callback) : 在执行时 会结束才有可能去执行另一个 所以不会ABCD交叉出现 : 最後我想说的是 js要看成是 event-driven的东西 : 用thread去分析 就会陷入把他拆成一行一行看的陷阱 : 而event-driven 产生的timing issue 对我来说 也是js bug中最难trace的一种 : 文章写的有点长 但其实还有很多细节 : opera这篇文章写得非常非常好 有兴趣的各位可以参考看看 : http://dev.opera.com/articles/view/timing-and-synchronization-in-javascript/ : ※ 引述《TonyQ (自立而後立人。)》之铭言： : : javascript 是同步的 : : 也就是不会有两行 statement 同时执行的 : : 但是他可以是多执行续。 : : 也就是假设你有一个 funciont 是 : : function A(){ : : alert("A"); : : alert("B"); : : } : : function B(){ : : alert("C"); : : alert("D"); : : } : : 透过 setTimeout / setItnerval , : : 是有可能会发生这样的执行序 : : alert("A");//from A : : alert("C");//from B : : alert("B");//from A : : alert("D");//from B : : 你把 js 底层的引擎想像成一个 queue ， : : 有要执行的指令就推进去，引擎会去跑他， : : 但同时间他只能处理一个指令。 : : 一般当你真的很需要控制执行的顺序的时候， : : 我们会多加几个 flag 作为 lock ，或者自己实做queue。 : : 但是基本上 javascript 要作到 java 的 synchronized keyword 做的事情， : : 是没有办法保证一定做的到的，最好尽量避免这麽严苛的状况。:P --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 71.107.60.113