为什么没有得到的JavaScript在常见的浏览器都有自己的线程？ [英] Why doesn't JavaScript get its own thread in common browsers?

问题描述

没有足够的JavaScript不是多线程，显然JavaScript的甚至没有获得自己的，但共享一个线程与其他的东西的负载。即使在最现代的浏览器中的JavaScript通常是在同一个队列绘画，更新的款式和处理用户操作。

Not enough that JavaScript isn't multithreaded, apparently JavaScript doesn't even get its own but shares a thread with a load of other stuff. Even in most modern browsers JavaScript is typically in the same queue as painting, updating styles, and handling user actions.

这是为什么？

这是我的经验，一个巨大的改进，用户体验可以得到，如果JavaScript的运行在自己的线程，独自一人被JS不阻止UI渲染或复杂的或有限的消息队列优化样板解放（是的，你也，webworkers！），这开发商有自己写的，以保持UI响应所有的地方，当它真的发生的时候。

From my experience an immensely improved user experience could be gained if JavaScript ran on its own thread, alone by JS not blocking UI rendering or the liberation of intricate or limited message queue optimization boilerplate (yes, also you, webworkers!) which the developer has to write themselves to keep the UI responsive all over the place when it really comes down to it.

我有兴趣了解其管辖这样一个看似不幸的设计决定的动机，有没有从软件架构的角度来看一个令人信服的理由？

I'm interested in understanding the motivation which governs such a seemingly unfortunate design decision, is there a convincing reason from a software architecture perspective?

推荐答案

用户动作可以触发JavaScript事件（点击，焦点事件，重要事件等）参与，并可能影响用户操作，以便清楚，而用户操作正在处理，因为单个的JS线程不能被执行，如果是这样的话，JS线程可以不参加的用户操作，因为它已经在做别的事情。所以，直到JS线程可以参与该进程的浏览器不处理默认的用户操作。

User Actions Require Participation from JS Event Handlers

User actions can trigger Javascript events (clicks, focus events, key events, etc...) that participate and potentially influence the user action so clearly the single JS thread can't be executing while user actions are being processed because, if so, then the JS thread couldn't participate in the user actions because it is already doing something else. So, the browser doesn't process the default user actions until the JS thread is available to participate in that process.

渲染更为复杂。一个典型的DOM修改顺序是这样的：1）通过JS修改后的DOM，布局标记为脏，2）JS线程执行完因此浏览器现在知道JS做修改DOM，3）浏览器的布局重新布局改变DOM，4 ）根据需要浏览器绘制屏幕。

Rendering is more complicated. A typical DOM modification sequence goes like this: 1) DOM modified by JS, layout marked dirty, 2) JS thread finishes executing so the browser now knows that JS is done modifying the DOM, 3) Browser does layout to relayout changed DOM, 4) Browser paints screen as needed.

步骤2）在这里很重要。如果浏览器的每一个JS DOM修改后做了一个新的布局和屏幕上画，整个过程可能是令人难以置信的效率低下，如果JS实际上要作一堆DOM修改。另外，将有线程同步的问题，因为如果你有JS修改DOM在为浏览器试图做一个重新布局和重绘的同时，你必须来同步活动（例如阻止别人这样的操作可能没有完成基础数据被另一个线程改变）。

Step 2) is important here. If the browser did a new layout and screen painting after every single JS DOM modification, the whole process could be incredibly inefficient if the JS was actually going to make a bunch of DOM modifications. Plus, there would be thread synchronization issues because if you had JS modifying the DOM at the same time as the browser was trying to do a relayout and repaint, you'd have to synchronize that activity (e.g. block somebody so an operation could complete without the underlying data being changed by another thread).

仅供参考，还有一些可以用来强制重新布局或从您的JS code范围内（不完全是你问的是什么，但有用的在某些情况下）强制重绘了一些变通。

FYI, there are some work-arounds that can be used to force a relayout or to force a repaint from within your JS code (not exactly what you were asking, but useful in some circumstances).

DOM是本质上是一个大的共享数据结构。浏览器构建它时，页面被解析。然后加载脚本和各种JS事件有机会对其进行修改。

The DOM is essentially a big shared data structure. The browser constructs it when the page is parsed. Then loading scripts and various JS events have a chance to modify it.

如果你突然有多个线程JS可以访问并发运行的DOM，你有一个非常复杂的问题。你会怎么同步访问？你甚至不能写最基本的DOM操作将涉及寻求在页面DOM对象，然后修改它，因为这不会是一个原子操作。 DOM中你能找到的DOM对象的时候，当你做了修改之间得到改变。相反，你可能必须在至少在DOM $ P $由其他线程被更改pventing它，而你在操纵或搜索其子树获取锁。然后，使修改后，你必须释放锁，并从code释放的DOM的状态的任何知识（因为一旦你释放了锁，其他线程可能会改变它）。而且，如果你没有正确地做事情，你可以死锁或各种讨厌的错误的结束。在现实中，你不得不对待DOM像并发，多用户的数据存储。这将是一个显著更复杂的编程模型

If you suddenly had multiple JS threads with access to the DOM running concurrently, you'd have a really complicated problem. How would you synchronize access? You couldn't even write the most basic DOM operation that would involve finding a DOM object in the page and then modifying it because that wouldn't be an atomic operation. The DOM could get changed between the time you found the DOM object and when you made your modification. Instead, you'd probably have to acquire a lock on at least a sub-tree in the DOM preventing it from being changed by some other thread while you were manipulating or searching it. Then, after making the modifications, you'd have to release the lock and release any knowledge of the state of the DOM from your code (because as soon as you release the lock, some other thread could be changing it). And, if you didn't do things correctly, you could end up with deadlocks or all sorts of nasty bugs. In reality, you'd have to treat the DOM like a concurrent, multi-user datastore. This would be a significantly more complex programming model.

有是单线程JS的设计决策中的一个统一的主题。 让事情简单一些。不需要的理解多线程环境和线程同步工具和多线程的调试才能写出扎实，可靠的浏览器的Javascript。

There is one unifying theme among the "single threaded JS" design decision. Keep things simple. Don't require an understanding of a multiple-threaded environment and thread synchronization tools and debugging of multiple threads in order to write solid, reliable browser Javascript.

原因之一浏览器的Javascript是一个成功的平台，是因为它是开发商各级交通十分便利，它比较容易学习，并写固体code。虽然浏览器JS可能会随着时间的推移得到更多先进的功能（如与我们WebWorkers了），你可以绝对肯定，这些会的方式，简单的事情保持简单，同时更先进的东西能够被更多的高级开发人员来完成来完成，但没有违反任何的是让事情变得简单了。

One reason browser Javascript is a successful platform is because it is very accessible to all levels of developers and it relatively easy to learn and to write solid code. While browser JS may get more advanced features over time (like we got with WebWorkers), you can be absolutely sure that these will be done in a way that simple things stay simple while more advanced things can be done by more advanced developers, but without breaking any of the things that keep things simple now.

仅供参考，我已经写在Node.js的多用户Web服务器应用程序，我怎么那么复杂得多的服务器设计是因为Java脚本的NodeJS的单线程性质不断赞叹不已。是的，有几件事情，更多的是一种痛苦的写（学习承诺写入大量的异步code），但哇简化假设，你的JS code永远不会被另一个请求中断大大简化了设计，测试和减少很难找到并修复错误的并发设计和编码总是充满了。

FYI, I've written a multi-user web server application in node.js and I am constantly amazed at how much less complicated much of the server design is because of single threaded nature of nodejs Javascript. Yes, there are a few things that are more of a pain to write (learn promises for writing lots of async code), but wow the simplifying assumption that your JS code is never interrupted by another request drastically simplifies the design, testing and reduces the hard to find and fix bugs that concurrency design and coding is always fraught with.

当然，第一个问题可以通过允许用户操作的事件处理程序在自己的线程中运行，因此他们可能出现的任何时间内解决。但是，那么你立刻拥有多线程JavaScript和现在均要求线程同步和错误的全新班一个全新的JS基础设施。浏览器的Javascript的设计者一直决定不打开盒子。

Certainly the first issue could be solved by allowing user action event handlers to run in their own thread so they could occur any time. But, then you immediately have multi-threaded Javascript and now require a whole new JS infrastructure for thread synchronization and whole new classes of bugs. The designers of browser Javascript have consistently decided not to open that box.

如果需要的话，渲染问题可以改进，但在显著的并发症浏览器code。你不得不创造一些方法去猜测当运行JS code好像不再改变DOM（也许毫秒的一定数量没有更多的变化去了），因为你必须避免做一个重新布局和屏幕马上搽每DOM变化。如果浏览器做了，一些JS操作将成为慢100倍（100X的是胡乱猜测，但问题是他们会是慢了很多）比他们今天。而且，你必须执行的布局，绘画和JS DOM的修改是可行的，但复杂的，大量的工作，并为浏览器的实现错误的沃土之间的线程同步。而且，你必须决定做什么，当你部分的方式，通过重新布局或重新绘制和JS线程进行修改DOM（无答案是伟大的）。

The Rendering issue could be improved if desired, but at a significant complication to the browser code. You'd have to invent some way to guess when the running JS code seems like it is no longer changing the DOM (perhaps some number of ms go by with no more changes) because you have to avoid doing a relayout and screen paint immediately on every DOM change. If the browser did that, some JS operations would become 100x slower than they are today (the 100x is a wild guess, but the point is they'd be a lot slower). And, you'd have to implement thread synchronization between layout, painting and JS DOM modifications which is doable, but complicated, a lot of work and a fertile ground for browser implementation bugs. And, you have to decide what to do when you're part-way through a relayout or repaint and the JS thread makes a DOM modification (none of the answers are great).

这篇关于为什么没有得到的JavaScript在常见的浏览器都有自己的线程？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！