3

これは非常にクローズできる質問かもしれませんが、私は壁にくっついているのを見るタイプです. ガベージ コレクトされたランタイムによって提供されるメモリおよび有効期間管理のすべての利点について、アプリケーションとそのガベージ コレクタの間の競合状態によって引き起こされるプログラムの不確定性の注目すべきケースはありますか? この種のことに対する防御的なプログラミングのゲシュタルトが出現しましたか? 確かに、RAII に慣れているプログラマーは、GC の存在下で教訓を学ばなければなりません。

4

4 に答える 4

7

ガベージ コレクションの問題は、メモリ リソースしか管理しないことです。残念ながら、プログラマーは他にも非常に多くの種類のリソースを管理する必要があります。

  • ファイルとソケットのハンドル
  • データベース接続
  • 同期オブジェクト
  • GUI リソース

ほんの少し例を挙げれば。これらをうまく管理するには、RAII イディオムに具体化された概念が本当に必要です。

于 2009-03-14T11:21:43.403 に答える
6

自動ガベージ コレクションのしくみを誤解していると思います。アプリケーションと正しく実装されたガベージ コレクターとの間で競合状態が発生することは、原則としてあり得ません。ガベージ コレクターは、アプリケーションがアクセスできないオブジェクトのみを収集します。

特定のオブジェクトを「所有」できるのは 2 つのうちの 1 つだけなので、競合状態は発生しません。

于 2009-03-14T06:02:36.307 に答える
5

私が 6 年ほど前に .NET の世界に移ったとき、私は GC に不安を感じ、GC はもっと遅くなるべきだと当然のように思っていました。パフォーマンス豚。

6年経って、私の見方は完全に変わったと言えます！忘れられた .Dispose() が原因でメモリ リークが発生したのは、ここ数年で1回だけです。それを、コーディングの1時間ごとにメモリリークを生成するC++と比較してください... ;-)

私は最近 C++ の世界に戻ることを余儀なくされました。私はこれを使って仕事をしていて、一度気に入ったことがありますか？C++ よりも C# の方が少なくとも 10 倍は生産性が高いと感じています。それに加えて、GC メモリ アロケータは非常に高速で、いまだに信じられません。私の特定のケースでは、.NET バージョン (C# または C++/CLI) が C++ MFC バージョンの 10 倍の速さで実行されたという結論を導き出さなければならなかったこの質問を見てください: C++ string memory allocation。

私は完全に改心しましたが、それを完全に受け入れるには長い時間がかかりました。

于 2009-03-14T06:04:50.483 に答える
0

私が最初に CI でプログラミングを始めたときは、malloc と realloc を非常に整然と使用する必要があり、使用していないものはすべて解放する必要がありました。これは、バイナリ ツリーの作成などの小さな大学の課題で簡単な作業でした。単純...

すべて C で記述された GUI を持つアプリケーションの開発を開始したとき、メモリ リークの可能性に注意を払わなければならないという事実のために、より多くのことを考え、プログラミングを減らす必要がありました。これが面倒になってきました。私は半ケツの製品よりも半製品の方がはるかに好きです.

Java と C# に移行し始めました。オブジェクトを逆参照するだけで、ガベージ コレクターが来てそれを拾ってくれるのが気に入りました。また、Java の Swing を使用すると (予想どおり) プログラムの実行速度が少し遅くなることに気付きましたが、扱いやすいものでした。

私の調査結果では、プロセッサが安価になり、メモリが安価で高速になり、GUI プログラムが以前よりも多くのメモリを消費しているためです。ガベージ コレクターは、メモリ リークの問題を最小限に抑えて動作する製品をリリースするのに非常に役立ちます。非常に便利で、悪いコーディング習慣につながる可能性がありますが、それらは修正できます.

編集：

これも参照してください。質問に答えるのに役立つ場合があります。よく読んだ IMO

于 2010-07-28T04:55:30.213 に答える