混乱しています、Pythonのような言語、Rubyシングルスレッドですか？Javaとは異なりますか？（Webアプリの場合）
私はClojureがその構文のためにどのように「クール」であるかを読んでいました+それはJVMで実行されるため、マルチスレッドなどになります。
Rubyやpython本来はシングルスレッド）のような言語ですか（Webアプリとして実行している場合）。
Python/RubyとJava Tomcatで実行中）の根本的な違いは何ですか？
Webサーバーには、すべてのケースで動作するスレッドのプールがないのですか？
PythonおよびRubyはマルチスレッドを完全にサポートしています。実際にスレッドを並列実行できない実装（CPython、MRI、YARVなど）もあります。しかし、これは言語ではなく、これらの特定の実装の制限です。これはJavaに似ており、スレッドを並行して実行できない実装もいくつかありますが、Javaがシングルスレッド。
どちらの場合でも、スレッドを並列に実行するcanの実装が多数あることに注意してください。PyPy、IronPython、Jython、IronRuby、およびJRubyは、例のほんの一部です。
一方のClojureとPython、Ruby、Java、C＃、C++、C、PHPと、他のほとんどすべてのメインストリーム言語とそうではないメインストリーム言語との主な違いは、 Clojureにはsane並行処理モデルがあります。他のすべての言語はスレッドを使用しますが、これは少なくとも40年間は並行処理モデルとしては不適切であることがわかっています。ClojureOTOHには、更新できないモデルがあります。プログラマーに提供するのは1つだけですが、実際には複数の正しい並行処理モデルです。アトミック更新、ソフトウェアトランザクションメモリ、非同期エージェント、並行処理対応のスレッドローカルグローバル変数、フューチャー、プロミス、データフロー並行処理、そして将来的にはさらに多くの可能性があります。
混乱した答えがたくさんある混乱した質問...
まず、スレッド化と同時実行は異なります。 Pythonは、スレッドを適切にサポートします。実際の実装では、同時実行をサポートしていません。すべての深刻な実装では、1つのVMスレッドしか実行できません一度に; VMスレッドはすべて失敗しました。）
次に、これはWebアプリには関係ありません。 Pythonバックエンドを同時に実行する必要はありません同じプロセスで。バックエンドごとにseparateプロセスを生成します。まったく結びついていないため、リクエストを並行して処理します。
Webバックエンドにスレッドを使用することは悪い考えです。スレッド化の危険-ロック、競合状態、デッドロック-を、本質的に恥ずかしいほど平行なものに導入するのはなぜですか？各バックエンドを独自の独立したプロセスに入れておく方がはるかに安全であり、これらすべての問題の可能性を回避できます。
（メモリ空間を共有することには利点があります-静的コードを共有することによってメモリを節約します-しかし、それはスレッドなしで解決できます。）
CPythonには Global Interpreter Lock があり、Pythonのマルチスレッドコードのパフォーマンスを低下させる可能性があります。場合によっては、ロックの競合のために、スレッドを実際には同時に実行できないという最終的な影響があります。すべてのPython実装がGILを使用するわけではないため、これはJPython、IronPythonまたは他の実装には適用されない場合があります。
言語自体は、スレッド化やその他の非同期操作をサポートしています。 pythonライブラリは、Pythonインタプリタに直接公開することなく、内部でスレッドをサポートすることもできます。
Pythonとスレッドについて否定的なことを聞いた場合（またはそれがサポートされていない場合）は、おそらくGILがボトルネックを引き起こしている状況に遭遇している誰かです。
確かにウェブサーバーにはスレッドのプールがあります。それはあなたのプログラムの制御範囲外です。これらのスレッドは、HTTP要求を処理するために使用されます。各HTTP要求は個別のスレッドで処理され、関連付けられたHTTP応答が完了すると、スレッドは解放されてプールに戻されます。 Webサーバーにそのようなプールがない場合、サービスの提供が非常に遅くなります。
プログラミング言語がシングルスレッドかマルチスレッドかは、問題の言語を使用してプログラムでnewスレッドを生成する可能性に依存します。それが不可能な場合、言語はPHPなどのシングルスレッドです。私が見る限り、RubyとPythonはどちらもマルチスレッドをサポートしています。
短い答えはイエスです、彼らはシングルスレッドです。
長い答えは、それは場合によります。
JRubyはマルチスレッド化されており、他のJavaコードのようにTomcatで実行できます。MRI（デフォルトRuby）とPythonの両方にGIL（グローバルインタープリターロック）があり、したがって、シングルスレッドです。
Webサーバーでの動作は、利用可能なサーバー構成の数によってさらに複雑になります。ほとんどのRubyアプリケーションには、少なくとも2つのレベルのサーバーがあります。nginxのようなプロキシ/静的ファイルサーバーと、Rubyアプリサーバーです。
Nginxは、ApacheやTomcatのようなスレッドを使用せず、非ブロッキングイベントを使用します（フォークされたワーカープロセスだと思います）。これにより、ネイティブスレッドのオーバーヘッドとスケジューリングの非効率性で許可されるよりも高いレベルの同時実行性を処理できます。
さまざまなRubyアプリサーバーは、スレッドなしで高いスループットと同時実行性を得るためにさまざまな方法で動作します。ThinはlibevとNginxのような非同期イベントモデルを使用します。Mongrelはワーカープロセスのラウンドロビンプールを使用します。 UnicornはネイティブUnix IPC（ソケットで選択））を使用して、1つのマスタープロキシソケットを介してフォークされたプロセスのプールに負荷分散します。
スレッドは、並行性に対処する唯一の方法です。複数のプロセスとイベントモデルは、Unixベースと連携する別のアプローチです。これは、Javaが世界を扱う方法とは根本的に異なります。
ほとんどの言語はシングルまたはマルチスレッドを定義していません。通常、それは実装するライブラリに任されています。
とはいえ、一部の言語は他の言語よりも優れています。たとえば、CPythonにはマルチスレッド時のインタープリターロックに関する問題がありますが、Jython（JVM上で実行されるPython）にはありません。
Clojure（IMO）の真の力のいくつかは、JVMで実行できることです。マルチスレッドと大量のライブラリを無料で入手できます。
CPythonやRubyなどのいくつかのインタープリター型プログラミング言語はスレッド化をサポートしますが、グローバルインタープリターロック（GIL）と呼ばれる制限があります。GILはインタープリターによって保持される相互排除ロックで、インタプリタが同時に2つ以上のスレッドのアプリケーションコードを同時に解釈することを防ぎます。これにより、複数のコアシステムでの同時実行性が効果的に制限されます。
ウィキペディアから スレッド
これらの答えをここで読んでください...それらの多くは、実際の私見よりも賢く聞こえようとします（私は主にRuby関連するものについて話しています）。実際、JRubyは現在、真の同時実行性をサポートする唯一のRuby実装です。JVMではRubyスレッドはGILに干渉することなくOSネイティブスレッドにマップされます。したがって、完全にRubyはマルチスレッドではありません。1.8.xではRubyは実際には1つのOSスレッド内で実行されますが、並行性の偽の感覚はありますが緑のスレッドを使用すると、実際にはGILは真の同時実行性をほとんど妨げます。Ruby 1.9では、これは少し変更されました。Rubyプロセスは多くのOSスレッド（および緑のスレッド）が接続されていますが、GILは完全にポイントを破壊し、ボトルネックになります。
実際には、通常のwebappの観点からは、シングルスレッドとマルチスレッドのどちらでも問題ありません。とにかく問題はほとんどサーバー側で発生し、それは主にスケーリング技術の違いの問題です。
Python
より詳細な回答よりも簡単に説明します。
ここでの答えの核心は、実際にはPythonがシングルスレッドであるかマルチスレッドであるかとは関係ありません。スレッドとマルチプロセッシングでは、もっと関係があります。
Python is "single-threaded"と言っても、実際には現実を捉えることはできません。Pythonプロセス。スレッドライブラリを使用して、複数のスレッドを作成します。ここで、Pythonはシングルスレッドではないことを証明しました。
しかしPythonで複数のスレッドを使用しても、複数のCPUプロセッサを同時に使用しているとは限りません。実際、グローバルインタープリターロックはこれを防ぎます。質問が発生します。
基本的に、Pythonのスレッドは並列CPU計算に使用できません。ただし、Pythonを使用して並列CPU計算を行うことができますmultiprocessing multi-threadingの代わりに。
これを調査するときに、この記事は非常に役立ちました： https://timber.io/blog/multiprocessing-vs-multithreading-in-python-what-you-need-to-know/ 。マルチプロセッシングとマルチスレッディングのどちらを使用するかについての実例が含まれています。
これを非常に短く保ちます。
Pythonはマルチスレッドをサポートしています。
Python スレッドの並列実行をサポートしていません。
例外：
上記のステートメントは、Python GIL（Global Interpreter Locking）を使用しない）の実装によって異なる場合があります。
特定の実装がGILを使用していない場合、それはマルチスレッドであり、並列実行をサポートします。
はいRubyおよびPythonはマルチスレッドを処理できますが、多くの場合（web）はクライアントからのhttpリクエストによって生成されたスレッドに依存する方が良いです同じアプリケーションで多くのスレッドを生成してランタイムコストを低くしたり、一度に多くのタスクを処理したりする場合でも、通常は時間がかかりすぎるWebアプリケーションの場合、ほんの数分の1秒を超えて喜んで待つことはありません。単一のページでアプリケーションの応答を得るには、AJAX（非同期JavaScriptおよびXML））技術を使用する方が賢明です。Webのデザインがすばやく表示されることを確認し、非同期挿入を行います。後でハードコーディングするものの。
これは、マルチスレッドがWebに役に立たないという意味ではありません。再帰的な複雑なハードコアアプリケーション（ウェブサイトではない）を実行したい場合は、サーバーの負荷を低くすることを強くお勧めしますが、返されるものはファイルまたはデータベースで終了する必要があるため、柔らかくすることができますhttp応答によって提供されます。
ルビー
Rubyインタプリタはシングルスレッドです。つまり、そのメソッドのいくつかはスレッドセーフではありません。
Railsの世界では、このシングルスレッドは主にサーバーにプッシュされています。そのため、nginxは、それぞれメモリ内にインタープリターを持つ雑種サーバーのプールで実行されていることがわかります。一度に1つのリクエストを処理し、独自のスレッドで処理します。
Passinger、running "Ruby enterprise" は、ガベージコレクションの概念とスレッドの安全性をRailsにもたらします。それは素晴らしいことです。
Railsこの分野ではまだやるべきことですが、ゆっくりと進んでいますが、一般的には、複数のサービスとサーバーを用意するのが目的です。
すべてのそれらのスレッドで結び目をほどく方法...
Clojureはスレッド化を発明しませんでしたが、ソフトウェアトランザクションメモリ、Atoms、エージェント、並列マップ操作などで特に強力にサポートされています。
他のすべては、スレッドのサポートを蓄積しています。 Rubyは、ソフトウェアエミュレートされたスレッドの一種であり、すべてのコアを使用しない一部の実装ではグリーンスレッドがあるため、特殊なケースです。1.9ではこれを休止します。
Webサーバーに関しては、それらは常にマルチスレッドで動作するとは限りません。Apacheは伝統的に、個別のシングルスレッドプロセスのプールであるデーモンの群れとして実行されてきました。現在、Apacheサーバーを実行するためのより多くのオプションがあります。
すべての現代の言語を要約すると、スレッドは何らかの形でサポートされます。
scalaやclojureのような新しい言語は、明示的にロックすることなく複数のスレッドでの作業を改善するための特定のサポートを追加しています。これは伝統的にマルチスレッドの大きな落とし穴です。