Node.jsがシングルスレッドになるのはなぜですか？[閉まっている]

PHP（またはJava / ASP.NET / Ruby）ベースのWebサーバーでは、すべてのクライアント要求が新しいスレッドでインスタンス化されます。しかし、Node.jsでは、すべてのクライアントが同じスレッドで実行されます（同じ変数を共有することさえできます！）I / O操作はイベントベースであるため、メインスレッドのループをブロックしないことを理解しています。

私が理解していないのは、Nodeの作成者がシングルスレッドを選択した理由は何ですか？それは物事を困難にします。たとえば、メインスレッドをブロックする（そして新しいクライアント要求がブロックされる）ため、CPU集中型の関数を実行できないため、プロセスを生成する必要があります（つまり、別のJavaScriptファイルを作成して別のノードプロセスを実行する必要があります）それ）。ただし、PHPでは、CPUを集中的に使用するタスクは他のクライアントをブロックしません。マルチスレッドWebサーバーと比較した場合の利点は何ですか？

注：私はこれを回避するためにクラスタリングを使用しましたが、それはきれいではありません。

Node.jsは、非同期処理の実験として明示的に作成されました。理論は、単一のスレッドで非同期処理を行うと、通常のスレッドベースの実装よりも、通常のWeb負荷でより高いパフォーマンスとスケーラビリティを提供できるというものでした。

そして、あなたは何を知っていますか？私の意見では、理論は裏付けられています。CPU集中型の処理を実行していないnode.jsアプリは、Apache、IIS、または他のスレッドベースのサーバーよりも数千の同時接続を実行できます。

シングルスレッドの非同期の性質は、物事を複雑にします。しかし、正直に言うと、スレッド化よりも複雑だと思いますか？1つの競合状態が月全体を台無しにする可能性があります！または、どこかで設定が原因でスレッドプールを空にして、クロールに対する応答時間が遅いのを確認してください！デッドロック、優先順位の逆転、およびマルチスレッド化に伴うその他すべての旋回は言うまでもありません。

結局、私はそれが普遍的に良くも悪くもないと思います。それは違います、そして時にはそれはより良いこともあり、そうでないこともあります。ジョブに適したツールを使用します。

サーバーの「リクエストごとに1つのスレッド」モデルの問題は、イベントループスレッドモデルと比較して、いくつかのシナリオで適切にスケーリングされないことです。

通常、I / O集中型のシナリオでは、リクエストはI / Oが完了するのを待つほとんどの時間を費やします。この間、「リクエストごとに1つのスレッド」モデルでは、スレッドにリンクされたリソース（メモリなど）は使用されず、メモリが制限要因になります。イベントループモデルでは、ループスレッドは次のイベント（I / O終了）を選択して処理します。したがって、スレッドは常にビジーです（もちろん、正しくプログラムした場合）。

すべてが新しいように見えるイベントループモデルとすべての問題の解決策ですが、どのモデルを使用するかは、取り組む必要のあるシナリオによって異なります。集中的なI / Oシナリオ（プロキシなど）がある場合は、イベントベースモデルが適用されますが、同時プロセス数が少ないCPU集中的なシナリオは、スレッドベースのモデルで最適に機能します。

現実の世界では、ほとんどのシナリオは少し真ん中にあります。スケーラビリティの実際のニーズと開発の複雑さのバランスをとって、正しいアーキテクチャを見つける必要があります（たとえば、CPU集中型タスクのバックエンドに委任するイベントベースのフロントエンドがあります。フロントエンドは、タスクを待機しているリソースをほとんど使用しません結果。）他の分散システムと同様に、機能させるためには多少の努力が必要です。

どんなシナリオにも苦労せずに合う銀の弾丸を探しているなら、あなたはあなたの足に弾丸を置くことになります。

要するに、ノードは内部的にシングルスレッドであるV8から引き出されます。CPU集中型タスクの制約を回避する方法があります。

ある時点（0.7）で、作成者は複数の計算スレッドを実装する方法として分離を導入しようとしましたが、最終的には削除されました：https : //groups.google.com/forum/#!msg / nodejs / zLzuo292hX0 / F7gqfUiKi2sJ