为什么Node.js的异步？ [英] Why is node.js asynchronous?

问题描述

没有人居然问这（从所有的建议'我得到，也从之前搜索我问这里）。

那么，为什么Node.js的异步？

从我的一些研究后推断：

像PHP和Python等语言脚本语言（我可能是错了的脚本语言的实际语言），而JavaScript是不是。 （我想从一个事实，即JS不编译这个派生？）

Node.js的运行在一个单独的线程，而脚本语言使用多个线程。

异步意味着无状态的连接是否持久，而同步的是（几乎）相反。

也许答案是在什么地方找到如上所述，但我仍然不能确定。

我的与此相关的专题的第二和最后一个问题是这样的：

JavaScript的能制作成同步的语言？

PS。我知道有些人会问：为什么你要让JS同步？在你的答案，但事实是，我不知道。我只是问这些类型的问题，因为我敢肯定有更多的人在那里的不仅仅是自己，也想过这样的问题。

解决方案

  

Node.js的运行在一个单独的线程，而脚本语言使用多个线程。

不是技术上。 Node.js的使用多个线程，但是只有一个执行线程。背景线程与IO处理，使所有异步善良的工作。使用线程处理效率是一个皇家疼痛，所以接下来最好的选择是在一个事件循环运行，因此code可以运行，而后台线程被阻塞的IO。

  

异步意味着无状态的连接是否持久，而同步的是（几乎）相反。

不一定。您可以在异步系统pretty容易preserve状态。例如，在Javascript中，你可以使用绑定（）来绑定这个来一个功能，从而$ ​​P $明确当函数返回pserving状态：

 功能状态（）{
    //确保每当doStuff被称之为维持其状态
    this.doStuff = this.doStuff.bind（本）;
}
State.prototype.doStuff =功能（）{
};
 

异步意味着不等待操作完成，但注册一个监听器来代替。这种情况发生在其他语言的时候，尤其是任何需要从用户接受输入。例如，在一个Java GUI，您没有阻止等待用户preSS一个按钮，但您注册使用GUI的侦听器。

  

我的与此相关的专题的第二和最后一个问题是这样的：

  
  

JavaScript的能制作成同步的语言？

从技术上讲，所有的语言都是同步的，甚至和JavaScript。然而，JavaScript的作品好了很多，在异步设计，因为它被设计为单线程的。

基本上有两种类型的程序：

• CPU bound-让它走得更快唯一​​的办法是让更多的CPU时间


• IO bound-花费了大量的时间等待数据，因此速度更快的处理器并不重要

视频游戏，数字打交道和编译器是CPU密集型的，而网络服务器和图形用户界面一般都是IO界。 JavaScript是比较慢（因为它是多么复杂的），所以它不会是能够在一个CPU绑定的场景竞争（相信我，我已经写了我的CPU绑定的Javascript公平的份额）。

代替在类和对象的术语编码，使用Javascript适合于在可以串成简单的功能方面的编码。这个工作相当不错，在异步设计，因为算法可以被写入增量处理数据，因为它的用武之地。IO（特别是网络IO）速度很慢，所以有相当多的数据包之间的时间。

示例

让我们假设你有1000的现场连接，每个连接提供一个数据包每毫秒，并处理每个数据包需要1微秒（很合理）。让我们假设每个连接发送5个数据包。

在单线程，同步应用程序中，每一个连接将在系列处理。所用的总时间（5 * 1 + 5 * 0.001）* 1000毫秒，或〜5005毫秒。

在单线程，异步应用中，每个连接将被并行处理。由于每个数据包需要1毫秒，并处理每个数据包需要0.001毫秒，我们可以处理的数据包之间的每个连接的数据包，所以我们的公式变为：1000 * 0.001 + 5 * 1毫秒，或6〜毫秒

传统的解决这个问题是创建多个线程。这解决了IO问题，但是当连接数上升，所以做了内存使用（线程花费大量内存）和CPU使用率（复用100个线程到1核心是难度比1线程1核心）。

但是，也有缺点。如果你的Web应用程序恰好也需要做一些繁重的数字运算，你SOL，因为当你在处理数字，连接需要等待。线程解决了这个，因为当数据准备好一个线程等待IO操作系统可以换出你的CPU密集型任务。此外，Node.js的被绑定到一个单核，所以除非你旋转起来的多个实例，并将请求你不能利用你的多核处理器。

Nobody has actually asked this (from all the 'suggestions' I'm getting and also from searching before I asked here).

So why is node.js asynchronous?

From what I have deduced after some research:

Languages like PHP and Python are scripting languages (I could be wrong about the actual languages that are scripting languages) whilst JavaScript isn't. (I suppose this derives from the fact that JS doesn't compile?)

Node.js runs on a single thread whilst scripting languages use multiple threads.

Asynchronous means stateless and that the connection is persistent whilst synchronous is the (almost) opposite.

Maybe the answer is found somewhere stated above, but I'm still not sure.

My second and last question related to this topic is this:

Could JavaScript be made into a synchronous language?

PS. I know some of you will ask "why would you want to make JS synchronous?" in your answers, but the truth is that I don't. I'm just asking these types of questions because I'm sure there are more people out there than just myself that have thought about such questions.

解决方案

Node.js runs on a single thread whilst scripting languages use multiple threads.

Not technically. Node.js uses several threads, but only one execution thread. The background threads are for dealing with IO to make all of the asynchronous goodness work. Dealing with threads efficiently is a royal pain, so the next best option is to run in an event loop so code can run while background threads are blocked on IO.

Asynchronous means stateless and that the connection is persistent whilst synchronous is the (almost) opposite.

Not necessarily. You can preserve state in an asynchronous system pretty easily. For example, in Javascript, you can use bind() to bind a this to a function, thereby preserving state explicitly when the function returns:

function State() {
    // make sure that whenever doStuff is called it maintains its state
    this.doStuff = this.doStuff.bind(this);
}
State.prototype.doStuff = function () {
};

Asynchronous means not waiting for an operation to finish, but registering a listener instead. This happens all the time in other languages, notably anything that needs to accept input from the user. For example, in a Java GUI, you don't block waiting for the user to press a button, but you register a listener with the GUI.

My second and last question related to this topic is this:

Could JavaScript be made into a synchronous language?

Technically, all languages are synchronous, even Javascript. However, Javascript works a lot better in an asynchronous design because it was designed to be single threaded.

Basically there are two types of programs:

• CPU bound- the only way to make it go faster is to get more CPU time
• IO bound- spends a lot of time waiting for data, so a faster processor won't matter

Video games, number crunchers and compilers are CPU bound, whereas web servers and GUIs are generally IO bound. Javascript is relatively slow (because of how complex it is), so it wouldn't be able to compete in a CPU bound scenario (trust me, I've written my fair share of CPU-bound Javascript).

Instead of coding in terms of classes and objects, Javascript lends itself to coding in terms of simple functions that can be strung together. This works very well in asynchronous design, because algorithms can be written to process data incrementally as it comes in. IO (especially network IO) is very slow, so there's quite a bit of time between packets of data.

Example

Let's suppose you have 1000 live connections, each delivering a packet every millisecond, and processing each packet takes 1 microsecond (very reasonable). Let's also assume each connection sends 5 packets.

In a single-threaded, synchronous application, each connection will be handled in series. The total time taken is (5*1 + 5*.001) * 1000 milliseconds, or ~5005 milliseconds.

In a single-threaded, asynchronous application, each connection will be handled in parallel. Since every packet takes 1 millisecond, and processing each packet takes .001 milliseconds, we can process every connection's packet between packets, so our formula becomes: 1000*.001 + 5*1 milliseconds, or ~6 milliseconds.

The traditional solution to this problem was to create more threads. This solved the IO problem, but then when the number of connections rose, so did the memory usage (threads cost lots of memory) and CPU usage (multiplexing 100 threads onto 1 core is harder than 1 thread on 1 core).

However, there are downsides. If your web application happens to also need to do some heavy number crunching, you're SOL because while you're crunching numbers, connections need to wait. Threading solves this because the OS can swap out your CPU-intensive task when data is ready for a thread waiting on IO. Also, node.js is bound to a single core, so you can't take advantage of your multi-core processor unless you spin up multiple instances and proxy requests.

这篇关于为什么Node.js的异步？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！