工作线程如何在Node.js中工作? [英] How worker threads works in Nodejs?

问题描述

Node.js不能具有Java和.net之类的内置线程API 做.如果添加线程，则语言本身的性质将 改变.无法将线程添加为一组新的可用线程 类或函数.

Nodejs can not have a built-in thread API like java and .net do. If threads are added, the nature of the language itself will change. It’s not possible to add threads as a new set of available classes or functions.

Nodejs 10.x作为实验添加了工作线程，现在从12.x开始稳定.我浏览了一些博客，但由于缺乏知识，所以了解得不多.它们与线程有何不同?

Nodejs 10.x added worker threads as an experiment and now stable since 12.x. I have gone through the few blogs but did not understand much maybe due to lack of knowledge. How are they different than the threads.

推荐答案

Javascript中的工作线程在某种程度上类似于浏览器中的WebWorkers.它们不与主线程或彼此共享对任何变量的直接访问，并且它们与主线程通信的唯一方法是通过消息传递.此消息传递是通过事件循环同步的.这避免了多个线程试图访问相同变量的所有经典竞争条件，因为两个单独的线程无法访问node.js中的相同变量.每个线程都有其自己的变量集，影响另一个线程变量的唯一方法是向其发送消息并要求其修改自己的变量.由于该消息是通过该线程的事件队列同步的，因此在访问变量时没有经典竞争条件的风险.

Worker threads in Javascript are somewhat analogous to WebWorkers in the browser. They do not share direct access to any variables with the main thread or with each other and the only way they communicate with the main thread is via messaging. This messaging is synchronized through the event loop. This avoids all the classic race conditions that multiple threads have trying to access the same variables because two separate threads can't access the same variables in node.js. Each thread has its own set of variables and the only way to influence another thread's variables is to send it a message and ask it to modify its own variables. Since that message is synchronized through that thread's event queue, there's no risk of classic race conditions in accessing variables.

Java线程类似于C ++或本机线程，因为它们共享对相同变量的访问，并且线程被自由分时，因此恰好在线程A中运行的functionA的中间，执行可能被中断，而functionB在threadB中运行可以运行.由于两者都可以自由访问相同的变量，因此除非您手动使用线程同步工具(例如互斥体)来协调和保护对共享变量的所有访问，否则就有各种竞争条件的可能.这类编程通常是很难找到的来源，并且几乎不可能可靠地重现并发错误.尽管功能强大且对某些系统级的事情或更多实时的代码有用，但对于非常资深且经验丰富的开发人员而言，任何人都很容易犯下代价高昂的并发错误.而且，很难设计出一种测试来告诉您在所有负载类型下它是否真的稳定.

Java threads, on the other hand, are similar to C++ or native threads in that they share access to the same variables and the threads are freely timesliced so right in the middle of functionA running in threadA, execution could be interrupted and functionB running in threadB could run. Since both can freely access the same variables, there are all sorts of race conditions possible unless one manually uses thread synchronization tools (such as mutexes) to coordinate and protect all access to shared variables. This type of programming is often the source of very hard to find and next-to-impossible to reliably reproduce concurrency bugs. While powerful and useful for some system-level things or more real-time-ish code, it's very easy for anyone but a very senior and experienced developer to make costly concurrency mistakes. And, it's very hard to devise a test that will tell you if it's really stable under all types of load or not.

node.js试图通过将线程划分到它们自己的变量空间中，并迫使它们之间的所有通信通过事件队列进行同步来避免经典的并发性错误.这意味着threadA/functionA绝不会被任意中断，并且您进程中的其他一些代码会在不查找时更改它正在访问的某些共享变量.

node.js attempts to avoid the classic concurrency bugs by separating the threads into their own variable space and forcing all communication between them to be synchronized via the event queue. This means that threadA/functionA is never arbitrarily interrupted and some other code in your process changes some shared variables it was accessing while it wasn't looking.

node.js还有一个后盾，它可以运行可以用任何语言编写的child_process，并且可以在需要时使用本机线程，或者可以使用add实际上将本机代码和实际系统级线程直接挂接到node.js中. -on SDK(它通过SDK接口与node.js Java脚本通信).而且，实际上，许多node.js内置库完全做到了这一点，以浮出水面，这些功能要求对nodejs环境具有该级别的访问权限.例如，文件访问的实现使用本地线程池来执行文件操作.

node.js also has a backstop that it can run a child_process that can be written in any language and can use native threads if needed or one can actually hook native code and real system level threads right into node.js using the add-on SDK (and it communicates with node.js Javascript through the SDK interface). And, in fact, a number of node.js built-in libraries do exactly this to surface functionality that requires that level of access to the nodejs environment. For example, the implementation of file access uses a pool of native threads to carry out file operations.

因此，尽管如此，仍然可能发生某些类型的竞争条件，这与访问外部资源有关.例如，如果两个线程或进程都试图做自己的事情并写入同一文件，则它们显然会彼此冲突并产生问题.

So, with all that said, there are still some types of race conditions that can occur and this has to do with access to outside resources. For example if two threads or processes are both trying to do their own thing and write to the same file, they can clearly conflict with each other and create problems.

因此，在访问外部资源时，在node.js中使用Workers仍必须注意并发问题. node.js保护每个Worker的局部变量环境，但不能对外部资源之间的争用做任何事情.在这方面，node.js Worker具有与Java线程相同的问题，程序员必须为此编写代码(专有文件访问，文件锁，每个Worker的单独文件，使用数据库来管理存储的并发性，等等.) ).

So, using Workers in node.js still has to be aware of concurrency issues when accessing outside resources. node.js protects the local variable environment for each Worker, but can't do anything about contention among outside resources. In that regard, node.js Workers have the same issues as Java threads and the programmer has to code for that (exclusive file access, file locks, separate files for each Worker, using a database to manage the concurrency for storage, etc...).

这篇关于工作线程如何在Node.js中工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！