Go

現代のソフトウェア エンジニアリングでは、複数のタスクを同時に実行できるアプリケーションを構築することはもはや贅沢ではなく、中核的な要件となっています。高スループットの Web サーバーからリアルタイム ストリーミング サービスに至るまで、同時実行性はパフォーマンスの中心です。 何十年もの間、C++、Java、Python などの従来のプログラミング言語は、オペレーティング システムのネイティブ スレッド モデルに依存して同時タスクを処理していました。しかし、2000 年代後半に Google が Go (Golang) を設計したとき、彼らは根本的に異なる道を歩みました。 Go は、生の OS スレッドを公開する代わりに、Goroutines と特殊な M:N Scheduler を導入しました。 この記事では、従来のスレッド モデルのアーキテクチャ上の制限を検討し、Go の同時実行設計が大幅に効率的でスケーラブルで開発者に優しい理由を探ります。 1. 従来のスレッディング (1:1 モデル) のボトルネック 従来のランタイム システムのほとんどは 1:1 スレッド モデル を使用します。このモデルでは、ユーザー空間コードで作成されたすべてのスレッドが、オペレーティング システム (OS) によって管理される 1 つのカーネル空間スレッドに直接マップされます。 この 1:1 マッピングは単純ですが、次の 3 つの重大なボトルネックを引き起こします。 A. メモリのオーバーヘッド (大きなスタック サイズ) OS スレッドは重いリソースです。デフォルトでは、オペレーティング システムは各スレッドに固定の連続したスタック サイズ (通常は 1MB ～ 8MB) を割り当てます。