`runtime.GOMAXPROCS` と `runtime.LockOSthread()` にもかかわらず、無限ループのゴルーチンが Go の HTTP サーバーをブロックするのはなぜですか?

Go で HTTP サーバーをブロックするゴルーチンの無限ループ

Go プログラミング言語では、並行して実行される同時ゴルーチンの作成が可能です。しかし、最近の観察により、HTTP サーバーでの無限ループ goroutine の動作に関する懸念が生じています。

Go のドキュメントによると、8 つの CPU コアで runtime.GOMAXPROCS(8) を設定すると、goroutine を並列実行できるようになるはずです。お互いをブロックすることなく。ただし、net/http パッケージを使用する場合はこの限りではありません。無限ループのゴルーチンは、いくつかのリクエストの後にサーバーをブロックしているようです。

この問題はコードに限定されず、runtime.LockOSthread() が無限ループのゴルーチンに追加されても継続します。 runtime.LockOSThread() はループが別のスレッドで実行され、他のゴルーチンを解放して実行を継続できるようにする必要があるため、これは予想外です。

説明

Go ランタイムのスケジューラは完全にプリエンプティブではありません。無限ループ コードの場合のように、関数呼び出しがない場合、スケジューラはトリガーされません。これにより、無限ループの goroutine が CPU を独占し、他の goroutine が実行されないようにすることができます。

解決策

この問題には、いくつかの解決策が考えられます。

• 無限ループにコンテンツを追加します:本体または関数が無限ループを呼び出すと、スケジューラがより頻繁にトリガーされ、他のゴルーチンが実行される機会が得られます。
• 定期的に runtime.Gosched: を呼び出します。 ) 関数を使用すると、手動でスケジューラを生成し、他のゴルーチンを実行できるようになります。このアプローチは、パフォーマンス重視のアプリケーションには理想的ではない可能性があります。

runtime.LockOSThread() はループを別のスレッドに完全に分離しないことに注意することが重要です。これにより、任意のスレッドでループを実行できますが、他の goroutine の実行が必要な場合、スケジューラがループを中断する可能性があります。

以上が`runtime.GOMAXPROCS` と `runtime.LockOSthread()` にもかかわらず、無限ループのゴルーチンが Go の HTTP サーバーをブロックするのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。