随着库的发展，编程变得更容易，人们似乎正在将 JS 用于更多 Java 在其鼎盛时期会被使用的东西。
也就是说，我们知道 JS 存在许多性能问题，其中之一就是使用线程优化运行时的能力。
我看到了：为什么 JavaScript 不支持多线程？，但这在 3-4 年前得到了回答（一年内发生了很多变化，更不用说 3-4 年了）。随着 HTML5 的快速发展，我更加好奇这是否得到了更多的考虑。
问问题
132 次
3 回答
2
你应该问，ECMA TC39，他们拥有 ECMAScript。
但简短的回答是否定的，如果你有长时间运行的脚本想要“产生一个新线程”，你应该检查WebWorkers，它们在自己的上下文中运行，技术上在另一个线程上运行。
于 2012-04-13T00:36:34.320 回答
1
我认为随着时间的推移，我们将看到 WebWorkers 可以做什么以及它们如何与主 javascript 线程通信的扩展。今天它非常有限，但是有一些方法可以让它变得更强大，而不会冒险让主 javascript 线程成为单线程的稳定性和简单性。
例如，今天您无法在 WebWorker 中加载图像或准备图形，但这对于图形密集型应用程序将非常有用。您可以进行计算，但仅限于此。
例如，您不能在任何类型的后台进程中为动画操作 DOM 对象。这也将非常有用 - 认为浏览器引擎实现起来更复杂。
于 2012-04-13T00:42:39.293 回答
0
JS 不——也可能不会——支持多线程的原因是它不适合 JS 所做的工作，尤其是在浏览器中。如果您有大量 CPU 密集型工作要做并且不介意在锁定等方面付出代价，并发线程很有用。但是浏览器 JS 根本不——也不应该——做很多 CPU 密集型的工作：它是一个事件驱动的环境，所以 JS 只需要一个线程。它在每个工作块之后将控制权交给浏览器，等待下一个事件——计时器、点击、onLoad 或其他任何事件。并发性将极大地增加管理所有事件处理程序的工作量并且不会增加太多性能 - 您的所有线程都将等待相同的事件，除非您有大量的事件触发，否则将没有足够的工作来保持您的线程忙。
正如 Slace 上面所说，WebWorkers 旨在允许在浏览器 JS 中执行 CPU 密集型工作的奇怪情况，但它们不是真正的多线程。
于 2012-04-13T00:48:10.580 回答