私はコンピュータ工学を勉強していて、いくつかの電子工学コースを持っています。私はそれを使用して回避することができる（これらのコースの）私の教授の2から、聞いたfree()（後に機能をmalloc()、calloc()おそらく割り当てられたメモリ空間は、他のメモリを割り当てるために再び使用されることはありませんので、など）。つまり、たとえば、4バイトを割り当ててから解放すると、4バイトのスペースができて、再び割り当てられない可能性があります。つまり、穴ができます。

私はそれがおかしいと思います：あなたはそれを解放せずにヒープにメモリを割り当てるおもちゃではないプログラムを持つことはできません。しかし、私には、それぞれにmalloc()がなければならないほど重要である理由を正確に説明する知識がありませんfree()。

だから：使用せmalloc()ずに使用することが適切であるかもしれない状況はありfree()ますか？そうでない場合は、どうすればこれを教授に説明できますか？

簡単：ほとんどすべての半真面目なmalloc()/free()実装のソースを読むだけです。これは、呼び出しの作業を処理する実際のメモリマネージャーを意味します。これは、ランタイムライブラリ、仮想マシン、またはオペレーティングシステムにある可能性があります。もちろん、コードはすべての場合に等しくアクセスできるわけではありません。

隣接する穴をより大きな穴に結合することにより、メモリが断片化されていないことを確認することは非常に一般的です。より深刻なアロケーターは、これを確実にするためにより深刻な技術を使用します。

したがって、3つの割り当てと割り当て解除を実行し、ブロックを次の順序でメモリに配置するとします。

+-+-+-+
|A|B|C|
+-+-+-+

個々の割り当てのサイズは重要ではありません。次に、最初と最後のAとCを解放します。

+-+-+-+
| |B| |
+-+-+-+

最終的にBを解放すると、（最初は少なくとも理論的には）次のようになります。

+-+-+-+
| | | |
+-+-+-+

断片化を解除して

+-+-+-+
|     |
+-+-+-+

つまり、1つの大きな空きブロックで、フラグメントは残っていません。

要求に応じて、参照：

• dlmallocのコードを読んでみてください。私ははるかに高度で、完全な本番品質の実装です。
• 組み込みアプリケーションでも、デフラグメンテーションの実装が利用可能です。たとえば、FreeRTOSのheap4.cコードに関するこれらの注意事項を参照してください。

他の回答には、すでにその完璧に本物の実装を説明malloc()し、free()より大きな自由チャンクに実際に合体（defragmnent）の穴を行います。しかし、そうではなかったとしても、それを放棄するのは悪い考えです。free()です。

重要なのは、プログラムがこれらの4バイトのメモリを割り当てた（そして解放したい）ということです。長期間実行する場合は、4バイトのメモリを再度割り当てる必要がある可能性があります。したがって、これらの4バイトがより大きな連続したスペースに合体することは決してない場合でも、プログラム自体で再利用できます。

これはまったくナンセンスです。たとえば、の実装にはさまざまなものがありmalloc、DougLeaやこれのようにヒープをより効率的にしようとするものもあります。

あなたの教授は、万が一、POSIXを使用していますか？彼らがたくさんの小さくてミニマルなシェルアプリケーションを書くことに慣れているなら、それはこのアプローチがそれほど悪くないだろうと私が想像できるシナリオです-OSの余暇で一度にヒープ全体を解放することはAを解放するよりも速くは千の変数。アプリケーションが1〜2秒間実行されると予想される場合は、割り当て解除をまったく行わずに簡単に回避できます。

もちろん、それでも悪い習慣です（パフォーマンスの向上は、漠然とした直感ではなく、常にプロファイリングに基づく必要があります）。他の制約を説明せずに学生に言うべきことではありませんが、小さな配管シェルがたくさん想像できます。 -アプリケーションはこのように記述されます（静的割り当てを完全に使用しない場合）。変数を解放しないことでメリットが得られるものに取り組んでいる場合は、非常に低レイテンシの条件で作業している（この場合、動的割り当てとC ++を購入する余裕はありますか？：D）。非常に、非常に間違ったことをしている（単一のメモリブロックではなく、1000個の整数を次々に割り当てることによって整数配列を割り当てるなど）。

あなたは彼らが電子工学の教授であると言いました。それらはファームウェア/リアルタイムソフトウェアの作成に使用される可能性があり、実行が必要になることが多いものを正確に計時することができました。そのような場合、すべての割り当てに十分なメモリがあることを知っていて、メモリを解放および再割り当てしないと、実行時間の計算がより簡単になる可能性があります。

一部のスキームでは、ハードウェアメモリ保護を使用して、割り当てられたメモリでルーチンが完了したことを確認したり、非常に例外的な場合にトラップを生成したりすることもできます。

これを以前のコメントや回答とは異なる角度から見ると、1つの可能性は、教授がメモリが静的に割り当てられたシステム（つまり、プログラムがコンパイルされたとき）の経験があることです。

静的割り当ては、次のような場合に発生します。

define MAX_SIZE 32
int array[MAX_SIZE];

多くのリアルタイムおよび組み込みシステム（EEまたはCEが遭遇する可能性が最も高いシステム）では、通常、動的メモリ割り当てを完全に回避することが望ましいです。だから、の使用malloc、newおよびその削除の対応はまれです。その上、近年、コンピュータのメモリが爆発的に増加しています。

512 MBが利用可能で、静的に1 MBを割り当てている場合、ソフトウェアが爆発する前に、約511 MBを処理する必要があります（正確には...しかし、ここで私と一緒に行ってください）。511 MBを悪用すると仮定すると、それらを解放せずに毎秒4バイトをmallocすると、メモリが不足する前に73時間近く実行できます。多くのマシンが1日に1回シャットダウンすることを考えると、プログラムのメモリが不足することはありません。

上記の例では、リークは4バイト/秒、つまり240バイト/分です。ここで、そのバイト/分の比率を下げると想像してください。その比率が低いほど、プログラムを問題なく実行できる時間が長くなります。もしあなたのmallocのがまれである、それは本当の可能性です。

ええと、あなたがmalloc一度だけ何かに行くことを知っていて、それmallocが二度とヒットしないことを知っているなら、それは静的割り当てによく似ていますが、あなたが割り当てているもののサイズを知る必要はありません-前面。例：再び512MBあるとしましょう。malloc整数の32配列が必要です。これらは典型的な整数です-それぞれ4バイト。これらの配列のサイズが1024整数を超えることはありません。私たちのプログラムでは、他のメモリ割り当ては発生しません。十分なメモリがありますか？32 * 1024 * 4 = 131,072。128KB-そうです。十分なスペースがあります。これ以上メモリを割り当てないことがわかっている場合は、安全にmallocそれらを解放せずにそれらの配列。ただし、これは、プログラムがクラッシュした場合にマシン/デバイスを再起動する必要があることを意味する場合もあります。プログラムを4,096回開始/停止すると、512MBすべてが割り当てられます。ゾンビプロセスがある場合、クラッシュした後でもメモリが解放されない可能性があります。

自分の痛みと悲惨さを救い、このマントラをThe One Truthとして消費してmallocください：常にに関連付けられるべきfreeです。 常にがnew必要です。 delete

質問で述べられている主張は、プログラマーの観点からは文字通り意味がないと思いますが、オペレーティングシステムの観点からは（少なくともいくつかは）真実があります。

malloc（）は、最終的にmmap（）またはsbrk（）のいずれかを呼び出し、OSからページをフェッチします。

重要なプログラムでは、割り当てられたメモリのほとんどをfree（）したとしても、プロセスの存続期間中にこのページがOSに返される可能性は非常に低くなります。したがって、free（）されたメモリは、ほとんどの場合同じプロセスでのみ使用でき、他のプロセスでは使用できません。

あなたの教授は間違っていませんが、間違っています（彼らは少なくとも誤解を招くか、過度に単純化しています）。メモリの断片化は、メモリのパフォーマンスと効率的な使用に問題を引き起こすため、場合によっては、それを考慮して、それを回避するためのアクションを実行する必要があります。古典的なトリックの1つは、同じサイズのメモリを多数割り当てる場合、起動時にそのサイズの倍数であるメモリプールを取得し、その使用量を完全に内部で管理することです。これにより、で断片化が発生しないようにします。 OSレベル（および内部メモリマッパーの穴は、そのタイプの次のオブジェクトにぴったりのサイズになります）。

そのようなことを処理するだけのサードパーティライブラリ全体があり、許容できるパフォーマンスと実行速度が遅すぎるものとの違いである場合があります。malloc()そしてfree()、あなたは彼らに多くのことを呼んでいる場合は、通知に始めましょう実行に著しく時間を取ります。

したがって、単純に使用することを回避することで、断片化とパフォーマンスの両方の問題を回避できますがmalloc()、free()それを理解するときは、特に理由がない限り、常にfree()すべてを確認する必要がmalloc()あります。内部メモリプールを使用している場合でも、優れたアプリケーションはfree()、終了する前にメモリをプールします。はい、OSはそれをクリーンアップしますが、アプリケーションのライフサイクルが後で変更された場合、プールがまだぶら下がっていることを忘れがちです...

もちろん、長時間実行されるアプリケーションは、割り当てられたすべてのものをクリーンアップまたはリサイクルすることに完全に注意を払う必要があります。そうしないと、メモリが不足してしまいます。

あなたの教授は重要な点を提起しています。残念ながら、英語の用法は、彼らが何を言っているのか完全にはわかりません。特定のメモリ使用特性を持ち、私が個人的に取り組んだおもちゃ以外のプログラムの観点から質問に答えさせてください。

一部のプログラムは正常に動作します。それらは、メモリをウェーブで割り当てます。繰り返しのサイクルで、多くの小規模または中規模の割り当てと、それに続く多くの解放です。これらのプログラムでは、一般的なメモリアロケータはかなりうまく機能します。それらは解放されたブロックを合体させ、ウェーブの終わりに、解放されたメモリのほとんどは大きな連続したチャンクになります。これらのプログラムは非常にまれです。

ほとんどのプログラムはうまく動作しません。それらは、非常に小さいものから非常に大きいものまでのさまざまなサイズで、多かれ少なかれランダムにメモリを割り当ておよび割り当て解除し、割り当てられたブロックの高い使用率を保持します。これらのプログラムでは、ブロックを合体させる機能は制限されており、時間の経過とともに、メモリは非常に断片化され、比較的連続しなくなります。合計メモリ使用量が32ビットメモリスペースで約1.5GBを超え、（たとえば）10MB以上の割り当てがある場合、最終的に大きな割り当ての1つが失敗します。これらのプログラムは一般的です。

他のプログラムは、停止するまでメモリをほとんどまたはまったく解放しません。実行中にメモリを段階的に割り当て、少量のみを解放してから停止します。停止すると、すべてのメモリが解放されます。コンパイラはこんな感じです。VMもそうです。たとえば、それ自体がC ++で記述された.NETCLRランタイムは、おそらくメモリを解放することはありません。なぜそれが必要ですか？

そしてそれが最終的な答えです。プログラムのメモリ使用量が十分に多い場合、mallocとfreeを使用してメモリを管理するだけでは、問題に対する十分な答えにはなりません。幸運にも正常に動作するプログラムを処理できる場合を除いて、メモリの大きなチャンクを事前に割り当ててから、選択した戦略に従ってサブ割り当てする1つ以上のカスタムメモリアロケータを設計する必要があります。プログラムが停止する場合を除いて、無料で使用することはできません。

あなたの教授が何を言ったかを正確に知らなくても、本当に生産規模のプログラムのために、私はおそらく彼らの側に出てくるでしょう。

編集

私はいくつかの批判に答えるつもりです。明らかに、SOはこの種の投稿には適していません。明確にするために、私はこの種のソフトウェアの作成に約30年の経験があり、いくつかのコンパイラーも含まれています。私には学術的な言及はなく、私自身の打撲傷だけです。経験がはるかに狭く、短い人々からの批判を感じずにはいられません。

重要なメッセージを繰り返します。mallocとfreeのバランスをとることは、実際のプログラムでの大規模なメモリ割り当てに対する十分な解決策ではありません。ブロック合体は正常であり、時間がかかりますが、それだけでは十分ではありません。真面目で賢いメモリアロケータが必要です。メモリアロケータは、メモリをチャンクで取得する傾向があり（mallocなどを使用）、ほとんど解放されません。これはおそらくOPの教授たちが念頭に置いていたメッセージであり、彼はそれを誤解していた。

私は、誰もが引用されなかったことを驚いているブックをまだ：

これは最終的には当てはまらない可能性があります。メモリが十分に大きくなり、コンピュータの存続期間中に空きメモリが不足する可能性がなくなるためです。例えば、3⋅10程度ある¹³我々は10個の程度必要となるマイクロ秒ごとに一度我々は短所にしたそうだとすれば、年間でマイクロ秒¹⁵のメモリが不足することなく、30年間動作することができるマシンを構築するためのメモリセル。今日の基準では、その量のメモリは途方もなく大きいように見えますが、物理的に不可能ではありません。一方、プロセッサは高速化しており、将来のコンピュータでは、単一のメモリ上で多数のプロセッサが並行して動作する可能性があるため、想定よりもはるかに速くメモリを使い果たす可能性があります。

http://sarabander.github.io/sicp/html/5_002e3.xhtml#FOOT298

したがって、実際、多くのプログラムは、メモリを解放することを気にせずに問題なく実行できます。

明示的にメモリを解放することが役に立たないよりも悪い場合の1つのケースについて知っています。つまり、プロセスの有効期間が終了するまですべてのデータが必要な場合です。言い換えれば、それらを解放するときは、プログラム終了の直前にのみ可能です。最新のOSは、プログラムが停止したときにメモリを解放するように注意しているfree()ため、その場合は呼び出す必要はありません。実際、メモリ内の複数のページにアクセスする必要がある場合があるため、プログラムの終了が遅くなる可能性があります。