Go にはレイテンシのないガベージ コレクションはありません。それらの主張がどこにあるかを指摘していただけるなら、私はそれらを修正しようと思います.
Java に対する Go の利点の 1 つは、メモリ レイアウトをより細かく制御できることです。たとえば、単純な 2D グラフィックス パッケージは次のように定義できます。
type Rect struct {
Min Point
Max Point
}
type Point struct {
X int
Y int
}
Go では、Rect はメモリ内で連続する 4 つの整数です。&r.Max を *Point を期待して関数に渡すこともできます。これは、Rect 変数 r の中央への単なるポインターです。
Java では、同等の式は Rect および Point クラスを作成することです。この場合、Rect の Min フィールドと Max フィールドは、個別に割り当てられたオブジェクトへのポインターになります。これには、より多くのオブジェクトを割り当てる必要があり、より多くのメモリを消費し、ガベージ コレクターに追跡と実行させる作業が増えます。一方、オブジェクトの中央へのポインターを作成する必要はありません。
Java と比較すると、Go ではプログラマーがメモリ レイアウトをより細かく制御でき、その制御を使用してガベージ コレクターの負荷を軽減できます。これは、大量のデータを扱うプログラムでは非常に重要です。メモリ レイアウトの制御は、キャッシュ効果などによりハードウェアからパフォーマンスを引き出すためにも重要な場合がありますが、それは元の質問とは関係ありません。
現在の Go ディストリビューションのコレクタは合理的ですが、決して最先端ではありません。今後 1 年か 2 年かけて、より多くの努力を払って改善する予定です。明確にするために言うと、Go のガベージ コレクターは確かに最新の Java ガベージ コレクターほど優れていませんが、最初からそれほど多くのガベージ コレクションを必要としないプログラムを書く方が Go の方が簡単であると考えているため、最終的な効果は依然としてガベージ コレクションは、同等の Java プログラムよりも Go プログラムの方が問題になりません。