Malloc

malloc（マロック, エムアロック）、calloc、reallocは、動的メモリ確保を行うC言語の標準ライブラリの関数である^[1][2][3]。確保したメモリの解放にはfree関数を使用する。

mallocが使用する実際のメモリ確保機構には様々な実装がある。それらの性能は、実行時間と要求されるメモリの両面で様々である。

C言語は通常メモリを「静的メモリ確保」か「自動メモリ確保」で管理する。静的変数は主記憶上にプログラムが存在する期間中ずっと確保されている。自動変数（局所変数）は通常コールスタック上に確保され、対応するサブルーチンが実行中の間だけ存在する。しかし、いずれの方法も限界があり、確保できるメモリ量（変数のサイズ）はコンパイル時に決められてしまう。必要なサイズが実行時でないと判明しない場合、例えばディスク上のファイルから任意のサイズのデータを読み込むような場合、固定サイズのデータオブジェクトだけでは不十分である。

確保されたメモリの生存期間（使用可能期間）も問題となる。静的でも自動的でも確保されたメモリの生存期間はあらゆる状況に対応できるものではない。スタック上のデータは複数の関数呼出をまたいで持続できないし、静的データは必要かどうかにかかわらずプログラムが動作中ずっとメモリ領域を確保し続ける。しかし、そうではなく確保したメモリの生存期間をプログラマが自由に制御できる必要がある場合も多い。

これらの制限は動的メモリ確保を使用することで解決する。メモリの管理は明示的に行う必要が出てくるが、柔軟性が向上する。「ヒープ領域」はこのために用意されたメモリ領域である。C言語では、malloc関数を使ってヒープ領域からメモリブロックを確保する。プログラムはmallocの戻り値であるポインタを使って、そのメモリブロックにアクセスする。メモリブロックが不要になったら、そのポインタをfreeに渡して解放し、他の用途に再利用できるようにする。

ヒープではなくCのスタックフレームから実行時に動的にメモリを確保するライブラリルーチンもある^{[注釈 1]}。このように確保したメモリは呼び出した関数から抜ける時点で自動的に解放される。ただし、スタックオーバーフローに注意する必要がある。GCC言語拡張の可変長配列がC99標準でサポートされ^[8]、実行時に大きさを決定でき任意の静的スコープの範囲で存在するメモリ確保法が言語構文に組み込まれたが、C11ではサポート必須ではなくオプションに格下げとなった。

mallocはC言語におけるヒープ領域からのメモリ確保に使われる基本関数である。その関数プロトタイプはstdlib.hヘッダに次のように定義されている^[1]。

void *malloc(size_t size)

ここで、sizeバイトのメモリが確保される。確保が成功するとそのメモリブロックへのポインタが返される。

ANSI Cにおいてmallocが返すのは、void型へのポインタ (void *) であり、そのポインタが指す領域のデータ型が不明であることを示している。C言語では汎用ポインタvoid *と任意の型TへのポインタT *との間の型変換 (キャスト) は暗黙的に実行されるため、mallocの戻り値は特に明示的な型変換を記述せずとも任意の型へのポインタ変数にそのまま代入できる。しかし、明示的に型変換を記述する必要が無いにもかかわらず、あえて意図的に型変換を記述することもある。明示的に型変換を記述する目的は、かつてANSI以前の仕様のC（K&R C）においては、void *が存在せず、mallocはchar *を返していたからである^[9][10]。また、C言語よりも厳密な型システムを持つC++では、T *からvoid *への型変換は暗黙的に行なわれるものの、void *からT *への型変換は暗黙的に行なわれないため、C/C++両方でコンパイルすることのできるソースコードを書く際には型変換の記述が必要となる。

int *ptr = (int *)malloc(sizeof(int) * 10);

しかし、stdlib.hをインクルードし忘れた場合（malloc関数の前方宣言がない場合）、C99よりも前のバージョンのCコンパイラはmallocがint型を返す関数であるとみなす。mallocの戻り値を明示的に型変換していると、ヘッダーをインクルードし忘れたことに気づかない。一方、明示的に型変換していないと、コンパイル時にintをポインタ型変数に代入しようとしているとして何らかの警告あるいはエラーメッセージがコンパイラから表示されることでインクルード忘れに気づける可能性がある^[11][9][12]。例えば64ビットのシステムでLP64というデータモデルを採用している場合、longとポインタは64ビットだが、intは32ビットとなる。この場合stdlib.hのインクルード忘れに気づかないと、mallocが実際には64ビットのポインタを返すのに、32ビットの値を返すと暗に宣言したことになり、バグが生じる可能性がある。ただし、多くのコンパイラは宣言のない関数を使用していると（キャストの有無にかかわらず）コンパイル時に警告を出す。C99以降では前方宣言のない関数の戻り値をintとみなさなくなったため、コンパイルエラーとなる。

C99およびC++03まではスレッドの概念が標準化されていなかったため、スレッドセーフ性に関しては何も言及がなかったが、C11およびC++11以降はスレッドセーフであることが規定されるようになった^{[13][14][15][16]}。

mallocで確保されたメモリは持続性がある。プログラム終了時か明示的にプログラマが解放しない限り存在し続ける。解放はfree関数で行われる。そのプロトタイプは次のようになる。

void free(void *pointer)

ここで、pointerの指すメモリブロックが解放される。

mallocはメモリブロックを確保して返すが、その領域は初期化されていない。必要に応じてメモリは個別に初期化する。例えば、memset関数で初期化したり、個別の代入文で初期化したりする。他にもcalloc（カロック、シーアロック）関数を使って、メモリ確保と初期化を行うこともできる。そのプロトタイプは以下のようになる。

void *calloc(size_t nelements, size_t bytes)

bytesのサイズのメモリ領域をnelements個格納できるメモリ領域を確保する。確保された領域はゼロで初期化される。

メモリブロックを大きくしたり小さくしたりできれば便利である。これはmallocとfreeを組み合わせて、新たなメモリブロックを確保して内容を前のメモリブロックからコピーし、前のメモリブロックを解放することで実現できる。しかし、この方法は回りくどい。代わりにrealloc（リアロック）関数を使うことができる。そのプロトタイプは以下の通りである。

void *realloc(void *pointer, size_t bytes)

reallocは指定されたサイズのメモリ領域へのポインタを返す。新しいサイズが前のサイズより大きければブロックは大きくされ、逆ならば小さくされる。

vallocはmallocとほとんど同じだが、メモリ確保がページ境界になる点が異なる。vallocで確保された領域へのポインタをreallocに渡すことはできない[1]。また、これは標準Cライブラリに含まれる関数ではない。

スタック上に10個の整数の配列を作成する一般的な方法は次の通りである。

int array[10];

同様の配列を動的に確保するには、以下のようにmallocを使う。

#include <stdlib.h>

/* 10個のintの配列のためのメモリを確保 */
int *ptr = malloc(sizeof(int) * 10);
if (NULL == ptr) {
    exit(EXIT_FAILURE); /* メモリを確保できなかったので終了 */
} else {
    /* 確保成功 */
    /* ここでその配列を使った処理を行う */

    /* 処理が完了し、使わなくなったメモリブロックを解放する */
    free(ptr);
    /* 解放したメモリにアクセスしてはならないことを示すため、NULLを代入しておく */
    ptr = NULL; 
}

mallocおよび関連するC言語の関数の使用は、以下のような理由でバグの発生源になりやすい。

mallocは必ず成功するとは限らない。利用可能な空きメモリ領域がないとき、プログラムが限界値を超えてメモリを使用しようとしたときなど、mallocはヌルポインタを返す。環境によって、このような状況の起きる可能性は異なる。もしmallocが失敗することを考慮していないプログラムで、mallocがヌルポインタを返してきたとき、プログラムはNULLに相当するアドレスにアクセスしてクラッシュするだろう。メモリ確保失敗をチェックすることは、ライブラリでは特に重要である。ライブラリはメモリ量が限られた状況でも使用される可能性がある。ライブラリ内でメモリ確保に失敗した場合、呼び出したアプリケーション側にエラーを通知して、アプリケーションプログラムに判断を委ねるのがよいとされる。

プロトタイピング目的で書かれたコードなどでは、メモリ確保失敗をチェックしないこともある。というのもメモリ確保に失敗するという状況は、画像処理などを除いた一般的な用途では珍しく、発生した場合には終了する以外にプログラミング上できることがないからでもある。ごく少量のメモリさえ確保に失敗するような状況では、メモリ確保失敗に対処したとしてもプログラムを正常に続行できる見込みがない。一方で、ライブラリ製品やアプリケーション製品では異常系すなわち例外処理への対処は重要であり、メモリ確保失敗への対処も例外ではない。

mallocで確保したメモリブロックを使用しなくなってもfreeで解放せず、次々と新たなメモリブロックを確保していると空きメモリが少なくなってくる。これをメモリリークと呼ぶ。メモリリークによるメモリ消費が無視できない量に達するとページ置換アルゴリズムによってページアウトが発生し、システム性能が低下する。さらに仮想記憶の容量限界に達すると、システム内の他の全プロセスでメモリ確保が失敗してシステムがストールする。メモリリークは、利用のたびにプロセスの起動・終了が行われるプログラムにおいて、特に重要な問題を引き起こさないため、メモリリークが混入した状態で出荷される商用プログラムは多い。しかしながら、連続稼動が要求されるサーバコンピュータ上のプログラム（サービス、デーモン）や、組み込みプログラム等の場合は、メモリリークは死活問題とされる。

ポインタがfree関数に渡され、メモリが解放された後でその領域への参照を行っても、その内容は未定義であり利用できない。しかし、ポインタ自体が残っていると誤って使ってしまうことがある。次のコードはその例である。

int *ptr = malloc(sizeof(*ptr)); /* メモリ領域を動的確保 */
...
free(ptr);
/* ptr は解放済みの領域をまだ指したまま */
*ptr = 0; /* 何が起きるかわからない！ */

このようなコードは予測不能の振る舞いをする。メモリが解放された後でシステムがその領域を他の用途に転用しているかもしれない。従って解放済みメモリ領域へのポインタ（ダングリングポインタ; dangling pointer）を使った書き込みはプログラム内の別のデータを不正に書き換えてしまう。どういうデータを書き換えたかによって、その後のプログラムの動作も異なる。単なるデータ破壊で済むかもしれないし、クラッシュするかもしれない。特に破壊的なバグとしては、同じポインタを2回free関数に渡してしまうことであり、これを「二重解放; double free」と呼ぶ。これを防ぐため、解放した後でポインタ変数にNULLを格納することがある。ポインタ変数が無効な領域を指しているかどうかを後で調べるとき、NULLが格納されているかどうかで簡単に判定できるようになる。また、free(NULL)は何もしないことが規格で保証されているので、NULLを代入しておけば（free関数を再度呼んだとしても）二重解放の危険はない。この技法は寿命の長いグローバル変数でポインタを定義する場合は必須だが、寿命の短いローカル変数でポインタを定義する場合でもフールプルーフのために用いることができる。

int *ptr = malloc(sizeof(*ptr));
...
free(ptr);
ptr = NULL;

メモリ管理の実装はオペレーティングシステム (OS) と（ハードウェア）アーキテクチャに大きく依存する。OSによってはmallocのためのアロケータを提供しているし、データ領域の制御関数を提供している場合もある。

同じ動的メモリアロケータでmallocだけでなくC++のoperator newも実装していることが多い。そこでこれを malloc ではなく「アロケータ」と呼ぶ。

IA-32アーキテクチャでのアロケータの実装には一般にヒープまたはデータセグメントが使用されている（セグメント方式）。 アロケータがメモリを確保するとき、ヒープに未使用領域がない場合はヒープを拡張することでメモリを確保する。

ヒープ方式はフラグメンテーションという問題がある。どのようなメモリ確保方式でもヒープではフラグメントが発生する。つまり、ヒープ上に飛び飛びに使用中領域と未使用領域が存在することになる。優秀なアロケータはヒープを拡張する前に未使用領域を再利用しようとする。しかし性能問題があるため、リアルタイムシステムでは代わりに「メモリプール」という方式を使う必要がある（特定サイズのメモリブロックのプールを予め用意しておく方式）。

ヒープ方式の欠点は、先頭位置が変更できないため、ヒープの最後の位置に使用中ブロックがある限り、ヒープを縮小することができないことである。従って、このような時は実際に使用しているメモリが少ないのにもかかわらず、ヒープのアドレス空間に占める領域が拡大し続けるという問題が生じる。

mmapで確保した領域は、縮小したり開放したりすることができる。これらによって開放された領域は、OSのメモリ管理システムに委ねることになる。

dlmalloc はニューヨーク州立大学オスウェゴ校の Doug Lea が1987年に開発を始めた汎用アロケータ^[17]で、パブリックドメインライセンス（CC0ライセンス）のオープンソースライブラリである。GNU Cライブラリ (glibc) の malloc は、dlmalloc を元に作られている^[18]。

ヒープ領域上のメモリは "chunk" という8バイト境界のデータ構造として確保され、その中にヘッダ部と利用可能なメモリがある。chunk および利用中フラグがあるため、8バイトまたは16バイトのオーバヘッドを含めたメモリ確保が必要である。アロケートされていないchunkも他のフリーなchunkへのポインタを持つため、chunkの最小サイズは24バイトとなっている^[18]。

アロケートされていないメモリは "bin" と呼ばれる同じサイズのchunkのグループに分けて管理される。binはchunkを双方向連結リストで連結したものである。

小さな領域（256バイト未満）を確保するときには2の累乗フリーリストが使われる。領域が不足したときは、より大きなサイズ用の領域からプールを確保する^[18]。

中程度の大きさの領域は、ビット単位トライ木 (bitwise trie) により管理される。領域が不足したときは、（sbrkによる）ヒープの拡張が行われる。

大きな領域（デフォルトでは256KB以上^{[注釈 2]}）は、mmap が使える環境の場合、mmap() により直接確保される。この大きさならば、ページサイズ^{[注釈 3]}単位でしか割り当てられないことによるオーバーヘッドや、システムコールの遅さによるオーバーヘッドはほとんどない。一方で、先に述べたヒープ方式のアロケーションの問題が起こらないので、この方法が使われる。

FreeBSD 7.0以降と NetBSD 5.0以降では、古い実装 (phkmalloc) をJason Evansが開発したjemallocに置換した。phkmalloc はマルチスレッド環境でのスケーラビリティに問題があった。ロックの衝突を防ぐため、jemallocはCPU毎に分離した "arena" と呼ばれる領域を用意する。実験によれば、スレッド数に比例して1秒間のmalloc回数が増えていくとき、phkmallocとdlmallocではスレッド数に反比例した性能を示した^[21]。

OpenBSDのmalloc関数の実装はmmapを使用している。ページサイズ以上の要求はmmapで行われ、ページサイズ未満ならmalloc内で管理しているメモリプールから割り当てる。そのメモリプールもmmapで確保したものである。freeを実行すると、munmapを使ってプロセスのアドレス空間からアンマップされて解放される。このシステムはアドレス空間のレイアウトをランダム化することによってセキュリティを高めるための設計でもあり、OpenBSDのmmapが持つギャップページ機能も利用している（mmapで確保した領域が仮想空間上で隣接しないようにする機能）。また、解放後の領域は仮想空間としてマッピングが存在しないため、解放後のアクセスの検出も容易である（普通ならセグメンテーション違反が発生してプログラムが終了する）。

Hoardメモリアロケータ（英語版）は、スケーラブルなメモリ確保性能を目指したアロケータである。OpenBSDのアロケータと同様、Hoard はmmapのみを使用するが、64キロバイトのスーパーブロックと呼ばれる塊ごとにメモリを管理する。Hoardのヒープは論理的にグローバルな1つのヒープとプロセッサ毎のヒープに分けられている。さらにスレッド毎のキャッシュを持ち、制限された数のスーパーブロックを保持できる。確保はスレッド毎またはプロセッサ毎のヒープからのみ行い、解放されたスーパーブロックの多くはグローバルなヒープに戻して他のプロセッサが使えるようにする。このようにしてHoardではスレッド数に対してほぼ比例したスケーラビリティを維持しつつ、フラグメンテーションを最小に抑えている^[22]。

スレッド毎に小さいメモリ確保のための領域を設ける。大きなメモリ確保にはmmapかsbrkを使用する。TCMallocはGoogleが開発したもので^[23]、スレッドが終了した際にローカルな領域を掃除するガベージコレクション機能を備えている。マルチスレッド環境では、glibcのptmallocの2倍以上の性能を発揮するという^[24][25]。

OSのカーネルでもアプリケーションと同様にメモリ確保が必要である。カーネル内にもmalloc相当の関数はあるが、その実装はCライブラリのものとは大きく異なる。例えば、DMA用のバッファには特別な制限が課せられることがあるし、割り込み処理でメモリを動的に確保したい場合もある^[26]。このため、カーネルの仮想記憶サブシステムと密に連携した malloc 実装が要求される。

mallocが確保できるメモリブロックの最大サイズはシステムに依存する。特に物理メモリ量とOSの実装に依存する。ディスクスワップによる仮想記憶をサポートしているシステムでは、物理メモリの空きが不足していてもストレージをメモリの代わりに使うため、その許容範囲内であればmallocが成功する可能性はある。ただし、たとえmallocが成功してnon-nullの値を返したとしても、実際に物理メモリやスワップ領域に十分な空きがあったかどうかは分からない。Linuxの場合、物理メモリを使い切ってしまうと、mallocで確保した仮想アドレス空間内のメモリ領域にデータを書き込もうとした時点で、仮想アドレスから物理アドレスへのマッピングが失敗し、OOM Killer (Out of Memory Killer) によってプロセスが強制終了されてしまう可能性がある^[27][28]。

引数sizeの型size_tは、sizeof演算子の結果を表す符号なし整数型^{[注釈 4]}であり、それ以上の意味は持たないが、一般的な実装ではポインタと同じサイズを持つ型として定義されている。size_tの最大値は、C99ではマクロ定数SIZE_MAXによって規定されており、少なくとも65535以上であることが保証されている^{[注釈 5]}が、一般的な実装では2^{CHAR_BIT × sizeof(size_t)} − 1と等しく、プロセスの論理アドレス空間の上限値となっているため、そのようなサイズのヒープ確保を試みても絶対に失敗する（または異常動作を引き起こす）。C言語標準は一回の確保で保証される最小値を提示している（C89では0x7FFF、C99では0xFFFF）。^[要出典]

Microsoft Visual C++では、許可されるユーザーリクエストの最大サイズがマクロ定数_HEAP_MAXREQによって規定されている^[29]。32ビット環境では0xFFFFFFE0に、64ビット環境では0xFFFFFFFFFFFFFFE0に展開される。この値はヒープ確保のリクエストが許可されるという意味であり、実際に成功するという保証値ではない。もしリクエストされたサイズが_HEAP_MAXREQを超える場合、errnoはENOMEMに設定され、呼び出しは失敗する^[30]。

C++でもmalloc関数は利用できるが、この利用は後述の問題を引き起こすため推奨されない。C++では言語の機能としてnew演算子、delete演算子が用意されている^[31]。mallocで確保したメモリ領域に対してdeleteしたり、逆にnewで確保した領域をfreeしたりすると結果は未定義となる。mallocによって生まれたポインタとnewによって生まれたポインタの混在はバグの温床であり、また、new/delete演算子と違い、malloc/free関数ではクラスのコンストラクタとデストラクタが呼ばれないという違いもあり、C++でのmallocは禁じ手の扱いである。

• バッファオーバーラン
• メモリデバッガ
• メモリ保護
• New演算子

この節には参考文献や外部リンクの一覧が含まれていますが、脚注による参照が不十分であるため、情報源が依然不明確です。 適切な位置に脚注を追加して、記事の信頼性向上にご協力ください。（2024年5月）

• 英語ページ
  • Definition of malloc in IEEE Std 1003.1-2017 standard - POSIX
  • malloc(3) - Linux manual page
  • Gloger, Wolfram; The ptmalloc homepage
  • Berger, Emery; The Hoard homepage
  • Douglas, Niall; The nedmalloc homepage
  • Evans, Jason; The jemalloc homepage
  • Berger, Emery; Hoard: A Scalable Memory Allocator for Multithreaded Applications
  • Michael, Maged M.; Scalable Lock-Free Dynamic Memory Allocation
  • Memory Reduction (GNOME) wiki page with lots of information about fixing malloc
  • C99 standard draft, including TC1/TC2/TC3
  • Some useful references about C
  • ISO/IEC 9899 – Programming languages – C
  • Bartlett, Jonathan; Inside memory management - The choices, tradeoffs, and implementations of dynamic allocation
• 日本語の解説
  • Man page of MALLOC - JM Project
  • Jonathan Bartlett (2004年11月16日). “メモリー管理の内側 動的アロケーションの選択肢とトレードオフ、そして実装”. チュートリアル>Linux. IBM. 2018年12月26日閲覧。
  • 技術本部 クラウド基盤エキスパート 角馬 文彦 (2007年11月30日). “malloc(3)のメモリ管理構造”. VA Linux Systems Japan. 2018年12月26日閲覧。