我刚观看了以下视频:Node.js简介,但仍然不明白你如何获得速度优势.
主要是,有一点Ryan Dahl(Node.js的创建者)说Node.js是基于事件循环而不是基于线程的.线程很昂贵,应该只留给并发编程的专家来使用.
之后,他展示了Node.js的体系结构堆栈,它具有底层的C实现,内部有自己的Thread池.显然,Node.js开发人员永远不会启动自己的线程或直接使用线程池...他们使用异步回调.我明白了.
我不明白的是,Node.js仍然在使用线程...它只是隐藏了实现,所以如果有50个人请求50个文件(当前不在内存中),那么如何更好,那么不需要50个线程？
唯一的区别是,由于它在内部管理,Node.js开发人员不必编写线程细节的代码,但在其下面仍然使用线程来处理IO(阻塞)文件请求.
那么你是不是真的只是遇到一个问题(线程)并在问题仍然存在时将其隐藏起来:主要是多线程,上下文切换,死锁......等等？
必须有一些我仍然不明白的细节.
我在网络编程方面不是很有经验,我还没有在Node.js中编写任何东西,只是对事件驱动的方法感到好奇.看起来确实不错.
本文解释了当我们使用基于线程的方法处理请求时可能发生的一些不好的事情,并且应该选择事件驱动的方法.在基于线程的情况下,收银员/线程一直困扰着我们,直到我们的食物/资源准备就绪.在事件驱动下,收银员将我们送到请求队列之外的某个地方,这样我们就不会在等待食物时阻止其他请求.要扩展基于阻塞线程,需要增加线程数.对我而言,这似乎是一个不正确使用线程/线程池的错误借口.
难道不能使用IHttpAsyncHandler正确处理？ASP.Net接收请求,使用ThreadPool并运行处理程序(BeginProcessRequest),然后在其中我们使用回调加载文件/数据库.那个线程应该可以自由处理其他请求.文件读取完成后,再次调用ThreadPool并执行剩余的响应.对我来说没有那么不同,那为什么不那么可扩展呢？
我所知道的基于线程的缺点之一是,使用线程需要更多内存.但只有这些,您才能享受多核的好处.我怀疑Node.js根本没有使用任何线程/核心.
因此,基于事件驱动vs基于线程(不要带"因为它是Javascript和每个浏览器..."的论点),有人可以指出我使用Node.js而不是使用Node.js的实际好处是什么现有技术？
这是一个很长的问题.谢谢 :)