プロセスに十分な仮想メモリアドレスがあると仮定します。
64 ビット システムの仮想アドレスはほぼ無限であり、OS メモリ プールに使用可能な物理メモリ領域がまだある場合、メモリ割り当てに失敗する可能性はゼロであると想定できますか?
プロセスに十分な仮想メモリアドレスがあると仮定します。
64 ビット システムの仮想アドレスはほぼ無限であり、OS メモリ プールに使用可能な物理メモリ領域がまだある場合、メモリ割り当てに失敗する可能性はゼロであると想定できますか?
場合によります。プロセスを制限して ( Linux のsetrlimit(2)などを使用して) すべてのリソースを使用しないようにすることもできます。また、そのような制限を設ける正当な理由があります (たとえば、バグのあるプログラムがすべてのリソースを消費するのを避けたり、一部を他のより重要なプロセスに任せたりする必要があります)。 )。
したがって、適切に動作するプログラムは常にメモリ割り当てをテストする必要があります(たとえば、 malloc(3)またはその両方は、多くの場合、 mmap(2)operator new
などの低レベルのシステムコールに基づいています ...)。もちろん、リソースは無限ではありません (最大で物理 RAM + スワップ領域)。
多くの場合、メモリが枯渇した場合に行う唯一のことは、適切なメッセージ (システム管理者が理解できる) でプログラムを中止することです。より手の込んだことを行うことははるかに困難ですが、可能です (サーバー プログラムでは、他の要求を処理し続けたいため、必要です...)。
したがって、C で次のように記述します。
void* p = malloc(somesize);
if (!p) { perror("malloc"); exit(EXIT_FAILURE); };
_exit
または、 atexit(3)を介してabort
登録されたターミネーターが怖い場合は...を使用できますが、気にしません。malloc
多くの場合、上記を実行するルーチンはxmalloc
、歴史的な理由から呼び出されます。
また、C++演算子 newでは、 std::bad_alloc例外をスローすることによって失敗する場合があります (または、nullptr
を使用する場合は、 std::nothrownew(std::nothrow)
を参照してください)。
Linux でのメモリーのオーバーコミット、仮想メモリー、およびJoachim Pileborgがコメントしたように、メモリーの断片化について詳しく学んでください。ガベージ コレクションについてお読みください。