{ "componentChunkName": "component---src-templates-post-js", "path": "/imasarali-jie-suru-sutateitukurinku-to-dainamitukurinku-webapurikesiyonenzinianotamenodi-reiyaru-men-sirizu-sono1/", "result": {"data":{"ghostPost":{"id":"Ghost__Post__69c3346171fa390001b3661c","title":"いまさら理解する「メモリとは？」- Webアプリケーションエンジニアのための低レイヤー入門シリーズ その２","slug":"imasarali-jie-suru-sutateitukurinku-to-dainamitukurinku-webapurikesiyonenzinianotamenodi-reiyaru-men-sirizu-sono1","featured":false,"feature_image":null,"excerpt":"先日、とあるサービスで OOMKilled \nが発生しまして、メモリリミットに引っかかったんですが、「そもそもなんでこんなにメモリ使ってるんだ？」を調査するのに、メモリの基礎知識が改めて大事だなと思いました。\n\nということで、「低レイヤー入門シリーズ」の第二弾はメモリについて深掘りしていきます！\n\n前回の「スタティックリンクとダイナミックリンク」\n[https://tech.anti-pattern.co.jp/imasarali-jie-surusutateitukurinkutodainamitukurinkunituite/]\nでは、プログラムがどのように実行ファイルになるかを学びました。今回は、その実行ファイルが動くときに欠かせないメモリの仕組み\nを、C言語を使って体感していきましょう。\n\n\n--------------------------------------------------------------------------------\n\nなぜWebエンジニアがメモリを理解すべきか？\n普段、Ruby on\nRailsやNode.js、Goなどで開発していると、メモ","custom_excerpt":null,"visibility":"public","created_at_pretty":"25 March, 2026","published_at_pretty":"08 April, 2026","updated_at_pretty":"08 April, 2026","created_at":"2026-03-25T10:03:29.000+09:00","published_at":"2026-04-08T14:35:32.000+09:00","updated_at":"2026-04-08T14:35:32.000+09:00","meta_title":null,"meta_description":null,"og_description":null,"og_image":null,"og_title":null,"twitter_description":null,"twitter_image":null,"twitter_title":null,"authors":[{"name":"Akihiro YAGASAKI","slug":"akihiro","bio":null,"profile_image":"https://ghost.tech.anti-pattern.co.jp/content/images/2022/04/yagasaki--2-.jpeg","twitter":null,"facebook":null,"website":null}],"primary_author":{"name":"Akihiro YAGASAKI","slug":"akihiro","bio":null,"profile_image":"https://ghost.tech.anti-pattern.co.jp/content/images/2022/04/yagasaki--2-.jpeg","twitter":null,"facebook":null,"website":null},"primary_tag":null,"tags":[],"plaintext":"先日、とあるサービスで OOMKilled \nが発生しまして、メモリリミットに引っかかったんですが、「そもそもなんでこんなにメモリ使ってるんだ？」を調査するのに、メモリの基礎知識が改めて大事だなと思いました。\n\nということで、「低レイヤー入門シリーズ」の第二弾はメモリについて深掘りしていきます！\n\n前回の「スタティックリンクとダイナミックリンク」\n[https://tech.anti-pattern.co.jp/imasarali-jie-surusutateitukurinkutodainamitukurinkunituite/]\nでは、プログラムがどのように実行ファイルになるかを学びました。今回は、その実行ファイルが動くときに欠かせないメモリの仕組み\nを、C言語を使って体感していきましょう。\n\n\n--------------------------------------------------------------------------------\n\nなぜWebエンジニアがメモリを理解すべきか？\n普段、Ruby on\nRailsやNode.js、Goなどで開発していると、メモリを意識することは少ないかもしれません。しかし、こんな場面に遭遇したことはありませんか？\n\n * 「メモリリーク」でアプリケーションが落ちた\n * 「OutOfMemoryError」に悩まされた\n * Dockerのメモリ制限で苦労した\n * パフォーマンスチューニングで「ヒープ」「スタック」という言葉が出てきた\n\nこれらを理解するためには、メモリの基礎知識が必要です。C言語は、メモリを直接操作できる言語なので、メモリの仕組みを学ぶのに最適なんです。\n\n\n--------------------------------------------------------------------------------\n\nメモリとは何か？\n概念図で理解する\nまず、メモリの全体像を把握しましょう。\n\n┌─────────────────────────────────────────────────────────────────┐\n│ 物理メモリ（RAM） │\n│ │\n│ メモリは「番地（アドレス）がついた巨大なロッカー」のようなもの │\n│ │\n│ ┌──────┬──────┬──────┬──────┬──────┬──────┬──────┬──────┐ │\n│ │ 0x00 │ 0x01 │ 0x02 │ 0x03 │ 0x04 │ 0x05 │ 0x06 │ 0x07 │ ... │\n│ │ │ │ │ │ │ │ │ │ │\n│ │ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ │\n│ └──────┴──────┴──────┴──────┴──────┴──────┴──────┴──────┘ │\n│ ↑ │\n│ アドレス（16進数で表される） │\n└─────────────────────────────────────────────────────────────────┘\n\nポイントは3つです。\n\n 1. メモリには「アドレス」という番地がある\n 2. 1つのアドレスには（基本は）1バイト（8ビット）のデータが格納できる\n 3. アドレスは通常、16進数（0x...）で表現される\n\n駅のコインロッカーを想像してみてください。ロッカー番号がアドレスで、中に入れる荷物がデータです。ただし、1つのロッカーに入る荷物は1バイト分だけ。大きなデータは、複数のロッカーにまたがって入れる必要があります。\n\nプログラムが使うメモリ領域\nプログラムが実行されると、OSはそのプログラム専用のメモリ空間を割り当てます。このメモリ空間は、いくつかの領域に分かれています。\n\n┌─────────────────────────────────────────┐ 高いアドレス\n│ スタック領域 │ ← 関数のローカル変数など\n│ ↓ │ （自動で確保・解放）\n│ ↓ │\n├─────────────────────────────────────────┤\n│ │\n│ 空き領域 │\n│ │\n├─────────────────────────────────────────┤\n│ ↑ │\n│ ↑ │\n│ ヒープ領域 │ ← 動的に確保するメモリ\n│ │ （mallocなど）\n├─────────────────────────────────────────┤\n│ BSS領域 │ ← 初期化されていない\n│ (未初期化データ) │ グローバル変数\n├─────────────────────────────────────────┤\n│ データ領域 │ ← 初期化された\n│ (初期化済みデータ) │ グローバル変数\n├─────────────────────────────────────────┤\n│ テキスト領域 │ ← プログラムのコード\n│ (コード領域) │ （機械語）\n└─────────────────────────────────────────┘ 低いアドレス\n\n今回は特にスタック領域とヒープ領域に注目します。この2つの違いがわかると、「なぜメモリリークが起きるのか」がスッキリ理解できるようになります。\n\n\n--------------------------------------------------------------------------------\n\n環境準備\n前回と同じく、実際にコードを動かしていきましょう。GCCが必要です。GCCが入っていない方は、ご自身の環境に合わせてググってインストールしてください！\n\n# バージョン確認\ngcc --version\n\n\n--------------------------------------------------------------------------------\n\n変数とメモリアドレス\n変数はメモリ上のどこにある？\nまず、変数がメモリ上のどこに配置されるかを確認してみましょう。\n\nファイル名: address.c\n\n#include \n\nint main() {\n int number = 42;\n char letter = 'A';\n double pi = 3.14159;\n \n printf(\"=== 変数の値とアドレス ===\\n\\n\");\n \n printf(\"int型変数 number\\n\");\n printf(\" 値: %d\\n\", number);\n printf(\" アドレス: %p\\n\", (void*)&number);\n printf(\" サイズ: %zu バイト\\n\\n\", sizeof(number));\n \n printf(\"char型変数 letter\\n\");\n printf(\" 値: %c\\n\", letter);\n printf(\" アドレス: %p\\n\", (void*)&letter);\n printf(\" サイズ: %zu バイト\\n\\n\", sizeof(letter));\n \n printf(\"double型変数 pi\\n\");\n printf(\" 値: %f\\n\", pi);\n printf(\" アドレス: %p\\n\", (void*)&pi);\n printf(\" サイズ: %zu バイト\\n\", sizeof(pi));\n \n return 0;\n}\n\nコンパイルと実行\ngcc -o address address.c\n./address\n\n実行結果の例\n=== 変数の値とアドレス ===\n\nint型変数 number\n 値: 42\n アドレス: 0x7ffd5c8b3a4c\n サイズ: 4 バイト\n\nchar型変数 letter\n 値: A\n アドレス: 0x7ffd5c8b3a4b\n サイズ: 1 バイト\n\ndouble型変数 pi\n 値: 3.141590\n アドレス: 0x7ffd5c8b3a40\n サイズ: 8 バイト\n\nここで注目すべきなのは、型によってサイズが違うこと。intは4バイト、charは1バイト、double\nは8バイト。そしてアドレスを見ると、変数ごとにちゃんと別々の場所が割り当てられているのがわかります。\n\n解説\n * &演算子：変数の前に&をつけると、その変数のメモリアドレスが取得できます\n * %p：アドレスを表示するためのフォーマット指定子です\n * sizeof：変数や型のサイズ（バイト数）を返します\n\nメモリのイメージ（上記の例の場合）\n\nアドレス 値 変数名\n0x7ffd5c8b3a40 [3.14159....] pi (8バイト)\n :\n0x7ffd5c8b3a4b ['A'] letter (1バイト)\n0x7ffd5c8b3a4c [42......] number (4バイト)\n ↓\nスタック領域（高いアドレスから低いアドレスへ伸びる）\n\n> 💡 Webエンジニア向けメモ\n> JavaScriptではtypeofで型を調べますが、メモリサイズは完全に隠蔽されています。 C言語では、型によってメモリの使用量が明確に決まります。\nこれが「型を意識する」ということの本質です。 Goのunsafe.Sizeof()やRustのstd::mem::size_of()\nでも同じようにサイズを確認できます。\n\n--------------------------------------------------------------------------------\n\nポインタの超基礎\nポインタとは？\nC言語といえばポインタ！…そして、挫折ポイントでもありますよね。でも恐れることはありません。一言でいうと、\n\n> ポインタ = メモリアドレスを格納する変数\nそれだけです。「値そのもの」ではなく「値がある場所（住所）」を覚えておく変数、というだけ。\n\n┌────────────────────────────────────────────────────────────┐\n│ │\n│ 通常の変数 ポインタ変数 │\n│ ┌─────────┐ ┌─────────────┐ │\n│ │ 42 │ │ 0x7ffd...4c │ │\n│ └─────────┘ └──────┬──────┘ │\n│ number │ │\n│ (int型) │ 「ここを見て！」 │\n│ ↓ │\n│ ┌─────────┐ │\n│ │ 42 │ │\n│ └─────────┘ │\n│ number │\n│ │\n└────────────────────────────────────────────────────────────┘\n\nポインタを使ってみよう\nファイル名: pointer_basic.c\n\n#include \n\nint main() {\n int number = 42;\n int *ptr = &number; // numberのアドレスをptrに格納\n \n printf(\"=== ポインタの基本 ===\\n\\n\");\n \n // 元の変数\n printf(\"number の値: %d\\n\", number);\n printf(\"number のアドレス: %p\\n\\n\", (void*)&number);\n \n // ポインタ変数\n printf(\"ptr の値（= numberのアドレス）: %p\\n\", (void*)ptr);\n printf(\"ptr が指す先の値（*ptr）: %d\\n\", *ptr);\n printf(\"ptr 自身のアドレス: %p\\n\\n\", (void*)&ptr);\n \n // ポインタを使って値を変更\n printf(\"--- ポインタ経由で値を変更 ---\\n\");\n *ptr = 100; // ポインタを通じてnumberの値を変更\n printf(\"*ptr = 100 を実行後:\\n\");\n printf(\"number の値: %d\\n\", number);\n printf(\"*ptr の値: %d\\n\", *ptr);\n \n return 0;\n}\n\n実行結果\ngcc -o pointer_basic pointer_basic.c\n./pointer_basic\n\n=== ポインタの基本 ===\n\nnumber の値: 42\nnumber のアドレス: 0x7ffd5c8b3a4c\n\nptr の値（= numberのアドレス）: 0x7ffd5c8b3a4c\nptr が指す先の値（*ptr）: 42\nptr 自身のアドレス: 0x7ffd5c8b3a40\n\n--- ポインタ経由で値を変更 ---\n*ptr = 100 を実行後:\nnumber の値: 100\n*ptr の値: 100\n\n*ptr = 100 しただけなのに、numberの値も100に変わっています。同じメモリを指しているから当然なんですが、初めて見るとちょっと不思議ですよね。\n\nポインタの記号まとめ\n* が宣言時と使用時で意味が変わるのがハマりポイントです。\n\n記号意味使用例* (宣言時)「これはポインタ変数です」int *ptr;* (使用時)デリファレンス（参照先の値を取得）*ptr = 100;&アドレスを取得\n&number宣言と使用の違い\n\nint *ptr = &number; ← 宣言時の * は「ポインタ型」を示す\n ↓\n*ptr = 100; ← 使用時の * は「参照先にアクセス」を示す\n\n> 💡 Webエンジニア向けメモ\n> 「ポインタ」って難しそうに聞こえますが、実はJavaScriptやRubyでも似た概念はあります。\nオブジェクトを変数に代入すると、値のコピーではなく「参照」が渡される、あれです。 C言語のポインタは、その参照を明示的に操作できるというだけの話なんです。\n\n--------------------------------------------------------------------------------\n\nメモリの動的確保（malloc / free）\nスタックとヒープ\nここまで見てきた変数は、すべてスタック領域に確保されていました。スタック領域の変数は、関数が終了すると自動的に解放されます。\n\n一方、ヒープ領域は、プログラマが明示的に確保・解放するメモリです。\n\n┌─────────────────────────────────────────────────────────────┐\n│ │\n│ スタック領域 ヒープ領域 │\n│ ───────────── ───────────── │\n│ │\n│ ✅ 自動で確保・解放 ⚠️ 手動で確保・解放 │\n│ ✅ 高速 ⚠️ やや低速 │\n│ ❌ サイズはコンパイル時に決定 ✅ サイズを実行時に決定可能 │\n│ ❌ 関数内でのみ有効 ✅ 関数をまたいで使える │\n│ │\n│ 用途: ローカル変数 用途: 可変長データ、 │\n│ 関数の引数 長期間保持するデータ │\n│ │\n└─────────────────────────────────────────────────────────────┘\n\nRubyやJavaScriptでは new \nするだけでヒープにオブジェクトが作られますが、C言語では自分で「これだけのメモリをください！」とOSにお願いする必要があります。それが malloc() です。\n\nmalloc と free\nファイル名: malloc_basic.c\n\n#include \n#include // malloc, free に必要\n\nint main() {\n printf(\"=== 動的メモリ確保 ===\\n\\n\");\n \n // 整数1つ分のメモリを確保\n // ※C言語ではmallocの戻り値(void*)は暗黙的にキャストされるため、\n // キャストは省略可能です。ここでは意図を明示するために記載しています。\n // （C++ではキャストが必須です）\n int *ptr = (int *)malloc(sizeof(int));\n \n // 確保できたか確認（重要！）\n if (ptr == NULL) {\n printf(\"メモリの確保に失敗しました\\n\");\n return 1;\n }\n \n printf(\"メモリを確保しました\\n\");\n printf(\"確保したアドレス: %p\\n\", (void*)ptr);\n printf(\"確保したサイズ: %zu バイト\\n\\n\", sizeof(int));\n \n // 確保したメモリに値を格納\n *ptr = 12345;\n printf(\"格納した値: %d\\n\\n\", *ptr);\n \n // メモリを解放\n free(ptr);\n printf(\"メモリを解放しました\\n\");\n \n // 解放後のポインタはNULLにするのが安全\n ptr = NULL;\n \n return 0;\n}\n\n実行結果\ngcc -o malloc_basic malloc_basic.c\n./malloc_basic\n\n=== 動的メモリ確保 ===\n\nメモリを確保しました\n確保したアドレス: 0x55a8b6c4a2a0\n確保したサイズ: 4 バイト\n\n格納した値: 12345\n\nメモリを解放しました\n\nmalloc → 使う → free の3ステップ。これがC言語のメモリ管理の基本です。free を忘れると大変なことになりますが、それは後ほど\n\n配列を動的に確保する\nスタック上の配列は int array[5]; のようにサイズをコンパイル時に決める必要がありますが、malloc を使えば実行時にサイズを決められます。\n\nファイル名: malloc_array.c\n\n#include \n#include \n\nint main() {\n int n;\n printf(\"配列の要素数を入力してください: \");\n scanf(\"%d\", &n);\n \n // n個のint配列を動的に確保\n int *array = (int *)malloc(sizeof(int) * n);\n \n if (array == NULL) {\n printf(\"メモリの確保に失敗しました\\n\");\n return 1;\n }\n \n printf(\"\\n%d個のint型配列を確保しました\\n\", n);\n printf(\"確保したサイズ: %zu バイト\\n\", sizeof(int) * n);\n printf(\"先頭アドレス: %p\\n\\n\", (void*)array);\n \n // 配列に値を格納\n for (int i = 0; i < n; i++) {\n array[i] = i * 10;\n }\n \n // 配列の内容とアドレスを表示\n printf(\"インデックス | 値 | アドレス\\n\");\n printf(\"-------------|------|------------------\\n\");\n for (int i = 0; i < n; i++) {\n printf(\" %d | %3d | %p\\n\", i, array[i], (void*)&array[i]);\n }\n \n // メモリを解放\n free(array);\n array = NULL;\n \n printf(\"\\nメモリを解放しました\\n\");\n \n return 0;\n}\n\n同様に実行すると？\n\n実行結果\n配列の要素数を入力してください: 5\n\n5個のint型配列を確保しました\n確保したサイズ: 20 バイト\n先頭アドレス: 0x55a8b6c4a2a0\n\nインデックス | 値 | アドレス\n-------------|------|------------------\n 0 | 0 | 0x55a8b6c4a2a0\n 1 | 10 | 0x55a8b6c4a2a4\n 2 | 20 | 0x55a8b6c4a2a8\n 3 | 30 | 0x55a8b6c4a2ac\n 4 | 40 | 0x55a8b6c4a2b0\n\nメモリを解放しました\n\nアドレスが4バイトずつ増えているのがわかりますか？ これは int \n型が4バイトだからです。メモリ上にきれいに並んでいるのが見えると、配列の正体がよくわかりますね。\n\n> 💡 Webエンジニア向けメモ\n> GoやRustでは make([]int, n) や Vec::with_capacity(n) のように、\n動的にサイズを指定して配列やスライスを作ることがよくあります。 裏側では似たようなヒープへのメモリ確保が行われています。\n\n--------------------------------------------------------------------------------\n\nメモリリークを体験する\nメモリリークとは？\nメモリリーク\nとは、確保したメモリを解放し忘れることで、使えるメモリが徐々に減っていく現象です。Webアプリの運用でよくある「なぜかメモリ使用量が右肩上がりで、定期的に再起動しないといけない」の原因、だいたいコレです。\n\nファイル名: memory_leak.c\n\n#include \n#include \n\nvoid bad_function() {\n // メモリを確保するが、解放しない（これがメモリリーク！）\n int *ptr = (int *)malloc(sizeof(int) * 1000);\n if (ptr == NULL) return;\n *ptr = 42;\n // free(ptr); ← これがない！\n}\n\nvoid good_function() {\n int *ptr = (int *)malloc(sizeof(int) * 1000);\n if (ptr == NULL) return;\n *ptr = 42;\n free(ptr); // ちゃんと解放\n}\n\nint main() {\n printf(\"=== メモリリークのデモ ===\\n\\n\");\n \n printf(\"bad_function を1000回呼び出します...\\n\");\n for (int i = 0; i < 1000; i++) {\n bad_function();\n }\n printf(\"完了（約4,000,000バイトがリークしています）\\n\\n\");\n \n printf(\"good_function を1000回呼び出します...\\n\");\n for (int i = 0; i < 1000; i++) {\n good_function();\n }\n printf(\"完了（メモリリークなし）\\n\");\n \n return 0;\n}\n\nbad_function は1回呼ぶたびに sizeof(int) * 1000 = 4,000バイト \nをリークします。1,000回呼ぶと約4,000,000バイト（約3.8MB）の漏れです。たった数行の free \nの書き忘れで、これだけのメモリが無駄になるんですね。\n\nValgrindでメモリリークを検出\nC言語にはメモリリークを検出する定番ツール Valgrind があります。Linuxでは、以下で確認できます！\n\n# Valgrindのインストール（Ubuntu）\nsudo apt install valgrind\n\n# コンパイル（デバッグ情報付き）\ngcc -g -o memory_leak memory_leak.c\n\n# Valgrindで実行\nvalgrind --leak-check=full ./memory_leak\n\n検出結果\n==12345== LEAK SUMMARY:\n==12345== definitely lost: 4,000,000 bytes in 1,000 blocks\n==12345== indirectly lost: 0 bytes in 0 blocks\n==12345== possibly lost: 0 bytes in 0 blocks\n==12345== still reachable: 0 bytes in 0 blocks\n==12345== suppressed: 0 bytes in 0 blocks\n\ndefinitely lost: 4,000,000 bytes — バッチリ検出されました！ こんなふうに、C言語ではメモリの問題を直接確認できます。\n\n> 💡 Webエンジニア向けメモ\n> Node.jsでも同様のメモリリークは起こります。例えば、グローバル変数に配列を追加し続けたり、イベントリスナーを解除し忘れたり、クロージャで大きなオブジェクトを参照し続けたり。原理は同じで、「使わなくなったメモリが解放されない」ことが問題です。\n> Node.jsの場合は --inspect フラグをつけて起動し、Chrome DevToolsの「Memory」タブでHeap\nSnapshotを取ると、Valgrindのようにリークを調査できます。Goなら pprof が同様のツールになります。\n\n--------------------------------------------------------------------------------\n\nスタックとヒープの違いを実感する\nダングリングポインタの危険\n最後に、スタックとヒープの違いが生む典型的なバグを見てみましょう。\n\nダングリングポインタとは、すでに無効になったメモリを指すポインタのことです。「存在しない住所が書かれたメモ」みたいなものですね。\n\nファイル名: dangling.c\n\n#include \n#include \n\n// ダメな例：スタック上の変数のアドレスを返す\nint* bad_get_number() {\n int local = 42;\n return &local; // ⚠️ 関数終了後、localは無効になる\n}\n\n// 良い例：ヒープ上にメモリを確保して返す\nint* good_get_number() {\n int *ptr = (int *)malloc(sizeof(int));\n if (ptr == NULL) return NULL;\n *ptr = 42;\n return ptr; // ✅ ヒープ上なので関数終了後も有効\n}\n\nint main() {\n printf(\"=== ダングリングポインタのデモ ===\\n\\n\");\n \n printf(\"【危険】スタック上の変数を返す場合:\\n\");\n int *bad = bad_get_number();\n printf(\"アドレス: %p\\n\", (void*)bad);\n // ⚠️ この行は未定義動作です！何が表示されるかわかりません\n // コンパイラの最適化レベルによって挙動が変わります\n printf(\"値（未定義動作！）: %d\\n\\n\", *bad);\n \n printf(\"【安全】ヒープ上のメモリを返す場合:\\n\");\n int *good = good_get_number();\n if (good != NULL) {\n printf(\"アドレス: %p\\n\", (void*)good);\n printf(\"値: %d\\n\", *good);\n free(good); // 使い終わったら解放\n }\n \n return 0;\n}\n\nコンパイル時の警告\n# 最適化なしでコンパイル（未定義動作の挙動を確認するため）\ngcc -Wall -O0 -o dangling dangling.c\n\ndangling.c: In function 'bad_get_number':\ndangling.c:7:12: warning: function returns address of local variable [-Wreturn-local-addr]\n 7 | return &local;\n | ^~~~~~\n\nコンパイラが警告してくれますね！ -Wall オプションをつけてコンパイルすると、こうした危険なコードを事前にキャッチできます。\n\nこの例がまさに「スタック vs ヒープ」の違いです。スタック上の変数（local）は関数を抜けた瞬間に無効になりますが、ヒープ上のメモリ（malloc \nで確保したもの）は free \nするまで有効。だからこそ、ヒープに確保して返すのが正しいパターンなんです。ただし、前述のメモリリークのように、freeを忘れないようにしないといけません！\n\n> 💡 Webエンジニア向けメモ\n> GoやRustでは、この種のバグはコンパイラが防いでくれます。 Goでは「エスケープ解析」によって、関数外に渡される変数は自動的にヒープに配置されます。 go\nbuild -gcflags=\"-m\" で確認できるので、興味のある方はぜひ試してみてください。\nRustではさらに厳密で、所有権とライフタイムの仕組みによって、ダングリングポインタの発生をコンパイル時に完全に防いでいます。\n\n--------------------------------------------------------------------------------\n\nまとめ\n今回学んだことを整理しましょう。\n\n┌─────────────────────────────────────────────────────────────────┐\n│ 今回のまとめ │\n├─────────────────────────────────────────────────────────────────┤\n│ │\n│ 1. メモリにはアドレスがある │\n│ → & でアドレスを取得、%p で表示 │\n│ │\n│ 2. ポインタ = アドレスを格納する変数 │\n│ → int *ptr = &number; │\n│ → *ptr でポインタが指す値にアクセス │\n│ │\n│ 3. 動的メモリ確保 │\n│ → malloc() で確保、free() で解放 │\n│ → 解放を忘れるとメモリリーク │\n│ │\n│ 4. スタック vs ヒープ │\n│ → スタック：自動管理、関数内で有効 │\n│ → ヒープ：手動管理、プログラム全体で有効 │\n│ │\n└─────────────────────────────────────────────────────────────────┘\n\nWeb系っぽい言語との対応\nC言語で学んだ概念は、普段使っている言語にも対応しています。\n\nC言語Web系っぽい言語での対応malloc()new Object() / オブジェクト生成free()GC（ガベージコレクション）が自動で行うポインタ\n参照（Reference）スタックプリミティブ型の値（※言語による）ヒープオブジェクト / 配列（※言語による）※\nスタックとヒープの割り当ては言語や実装によって異なります。例えばGoではエスケープ解析によって、見た目はローカル変数でもヒープに配置されることがあります。上記はJavaでの一般的なイメージとして参考にしてください。\n\n\n前回のリンクの話と今回のメモリの話で、だいぶコンピュータの「裏側」が見えてきたのではないでしょうか？\nこの知識があると、Dockerのリソース制限とかOOMKilledとか、「あ、あれのことね」とピンとくるようになりますよ！\n\nたぶん！\n\nこちらからは以上です。","html":"

先日、とあるサービスで OOMKilled が発生しまして、メモリリミットに引っかかったんですが、「そもそもなんでこんなにメモリ使ってるんだ？」を調査するのに、メモリの基礎知識が改めて大事だなと思いました。

ということで、「低レイヤー入門シリーズ」の第二弾はメモリについて深掘りしていきます！

前回の「スタティックリンクとダイナミックリンク」では、プログラムがどのように実行ファイルになるかを学びました。今回は、その実行ファイルが動くときに欠かせないメモリの仕組みを、C言語を使って体感していきましょう。

なぜWebエンジニアがメモリを理解すべきか？

普段、Ruby on RailsやNode.js、Goなどで開発していると、メモリを意識することは少ないかもしれません。しかし、こんな場面に遭遇したことはありませんか？

  • 「メモリリーク」でアプリケーションが落ちた
  • 「OutOfMemoryError」に悩まされた
  • Dockerのメモリ制限で苦労した
  • パフォーマンスチューニングで「ヒープ」「スタック」という言葉が出てきた

これらを理解するためには、メモリの基礎知識が必要です。C言語は、メモリを直接操作できる言語なので、メモリの仕組みを学ぶのに最適なんです。

メモリとは何か？

概念図で理解する

まず、メモリの全体像を把握しましょう。

┌─────────────────────────────────────────────────────────────────┐\n│                        物理メモリ（RAM）                          │\n│                                                                 │\n│  メモリは「番地（アドレス）がついた巨大なロッカー」のようなもの      │\n│                                                                 │\n│  ┌──────┬──────┬──────┬──────┬──────┬──────┬──────┬──────┐      │\n│  │ 0x00 │ 0x01 │ 0x02 │ 0x03 │ 0x04 │ 0x05 │ 0x06 │ 0x07 │ ...  │\n│  │      │      │      │      │      │      │      │      │      │\n│  │ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│ 1byte│      │\n│  └──────┴──────┴──────┴──────┴──────┴──────┴──────┴──────┘      │\n│     ↑                                                           │\n│  アドレス（16進数で表される）                                     │\n└─────────────────────────────────────────────────────────────────┘

ポイントは3つです。

  1. メモリには「アドレス」という番地がある
  2. 1つのアドレスには（基本は）1バイト（8ビット）のデータが格納できる
  3. アドレスは通常、16進数（0x...）で表現される

駅のコインロッカーを想像してみてください。ロッカー番号がアドレスで、中に入れる荷物がデータです。ただし、1つのロッカーに入る荷物は1バイト分だけ。大きなデータは、複数のロッカーにまたがって入れる必要があります。

プログラムが使うメモリ領域

プログラムが実行されると、OSはそのプログラム専用のメモリ空間を割り当てます。このメモリ空間は、いくつかの領域に分かれています。

┌─────────────────────────────────────────┐  高いアドレス\n│              スタック領域                │  ← 関数のローカル変数など\n│                  ↓                      │    （自動で確保・解放）\n│                  ↓                      │\n├─────────────────────────────────────────┤\n│                                         │\n│              空き領域                    │\n│                                         │\n├─────────────────────────────────────────┤\n│                  ↑                      │\n│                  ↑                      │\n│              ヒープ領域                  │  ← 動的に確保するメモリ\n│                                         │    （mallocなど）\n├─────────────────────────────────────────┤\n│              BSS領域                     │  ← 初期化されていない\n│          (未初期化データ)                 │    グローバル変数\n├─────────────────────────────────────────┤\n│              データ領域                  │  ← 初期化された\n│           (初期化済みデータ)              │    グローバル変数\n├─────────────────────────────────────────┤\n│              テキスト領域                │  ← プログラムのコード\n│            (コード領域)                  │    （機械語）\n└─────────────────────────────────────────┘  低いアドレス

今回は特にスタック領域とヒープ領域に注目します。この2つの違いがわかると、「なぜメモリリークが起きるのか」がスッキリ理解できるようになります。

環境準備

前回と同じく、実際にコードを動かしていきましょう。GCCが必要です。GCCが入っていない方は、ご自身の環境に合わせてググってインストールしてください！

# バージョン確認\ngcc --version

変数とメモリアドレス

変数はメモリ上のどこにある？

まず、変数がメモリ上のどこに配置されるかを確認してみましょう。

ファイル名: address.c

#include <stdio.h>\n\nint main() {\n    int number = 42;\n    char letter = 'A';\n    double pi = 3.14159;\n    \n    printf(\"=== 変数の値とアドレス ===\\n\\n\");\n    \n    printf(\"int型変数 number\\n\");\n    printf(\"  値: %d\\n\", number);\n    printf(\"  アドレス: %p\\n\", (void*)&number);\n    printf(\"  サイズ: %zu バイト\\n\\n\", sizeof(number));\n    \n    printf(\"char型変数 letter\\n\");\n    printf(\"  値: %c\\n\", letter);\n    printf(\"  アドレス: %p\\n\", (void*)&letter);\n    printf(\"  サイズ: %zu バイト\\n\\n\", sizeof(letter));\n    \n    printf(\"double型変数 pi\\n\");\n    printf(\"  値: %f\\n\", pi);\n    printf(\"  アドレス: %p\\n\", (void*)&pi);\n    printf(\"  サイズ: %zu バイト\\n\", sizeof(pi));\n    \n    return 0;\n}

コンパイルと実行

gcc -o address address.c\n./address

実行結果の例

=== 変数の値とアドレス ===\n\nint型変数 number\n  値: 42\n  アドレス: 0x7ffd5c8b3a4c\n  サイズ: 4 バイト\n\nchar型変数 letter\n  値: A\n  アドレス: 0x7ffd5c8b3a4b\n  サイズ: 1 バイト\n\ndouble型変数 pi\n  値: 3.141590\n  アドレス: 0x7ffd5c8b3a40\n  サイズ: 8 バイト

ここで注目すべきなのは、型によってサイズが違うこと。intは4バイト、charは1バイト、doubleは8バイト。そしてアドレスを見ると、変数ごとにちゃんと別々の場所が割り当てられているのがわかります。

解説

  • &演算子：変数の前に&をつけると、その変数のメモリアドレスが取得できます
  • %p：アドレスを表示するためのフォーマット指定子です
  • sizeof：変数や型のサイズ（バイト数）を返します
メモリのイメージ（上記の例の場合）\n\nアドレス        値              変数名\n0x7ffd5c8b3a40  [3.14159....]   pi (8バイト)\n    :\n0x7ffd5c8b3a4b  ['A']           letter (1バイト)\n0x7ffd5c8b3a4c  [42......]      number (4バイト)\n    ↓\nスタック領域（高いアドレスから低いアドレスへ伸びる）
💡 Webエンジニア向けメモ
JavaScriptではtypeofで型を調べますが、メモリサイズは完全に隠蔽されています。 C言語では、型によってメモリの使用量が明確に決まります。 これが「型を意識する」ということの本質です。 Goのunsafe.Sizeof()やRustのstd::mem::size_of()でも同じようにサイズを確認できます。

ポインタの超基礎

ポインタとは？

C言語といえばポインタ！…そして、挫折ポイントでもありますよね。でも恐れることはありません。一言でいうと、

ポインタ = メモリアドレスを格納する変数

それだけです。「値そのもの」ではなく「値がある場所（住所）」を覚えておく変数、というだけ。

┌────────────────────────────────────────────────────────────┐\n│                                                            │\n│   通常の変数                      ポインタ変数              │\n│   ┌─────────┐                   ┌─────────────┐            │\n│   │   42    │                   │ 0x7ffd...4c │            │\n│   └─────────┘                   └──────┬──────┘            │\n│   number                               │                   │\n│   (int型)                              │ 「ここを見て！」   │\n│                                        ↓                   │\n│                                   ┌─────────┐              │\n│                                   │   42    │              │\n│                                   └─────────┘              │\n│                                   number                   │\n│                                                            │\n└────────────────────────────────────────────────────────────┘

ポインタを使ってみよう

ファイル名: pointer_basic.c

#include <stdio.h>\n\nint main() {\n    int number = 42;\n    int *ptr = &number;  // numberのアドレスをptrに格納\n    \n    printf(\"=== ポインタの基本 ===\\n\\n\");\n    \n    // 元の変数\n    printf(\"number の値: %d\\n\", number);\n    printf(\"number のアドレス: %p\\n\\n\", (void*)&number);\n    \n    // ポインタ変数\n    printf(\"ptr の値（= numberのアドレス）: %p\\n\", (void*)ptr);\n    printf(\"ptr が指す先の値（*ptr）: %d\\n\", *ptr);\n    printf(\"ptr 自身のアドレス: %p\\n\\n\", (void*)&ptr);\n    \n    // ポインタを使って値を変更\n    printf(\"--- ポインタ経由で値を変更 ---\\n\");\n    *ptr = 100;  // ポインタを通じてnumberの値を変更\n    printf(\"*ptr = 100 を実行後:\\n\");\n    printf(\"number の値: %d\\n\", number);\n    printf(\"*ptr の値: %d\\n\", *ptr);\n    \n    return 0;\n}

実行結果

gcc -o pointer_basic pointer_basic.c\n./pointer_basic
=== ポインタの基本 ===\n\nnumber の値: 42\nnumber のアドレス: 0x7ffd5c8b3a4c\n\nptr の値（= numberのアドレス）: 0x7ffd5c8b3a4c\nptr が指す先の値（*ptr）: 42\nptr 自身のアドレス: 0x7ffd5c8b3a40\n\n--- ポインタ経由で値を変更 ---\n*ptr = 100 を実行後:\nnumber の値: 100\n*ptr の値: 100

*ptr = 100 しただけなのに、numberの値も100に変わっています。同じメモリを指しているから当然なんですが、初めて見るとちょっと不思議ですよね。

ポインタの記号まとめ

* が宣言時と使用時で意味が変わるのがハマりポイントです。

記号意味使用例
* (宣言時)「これはポインタ変数です」int *ptr;
* (使用時)デリファレンス（参照先の値を取得）*ptr = 100;
&アドレスを取得&number
宣言と使用の違い\n\nint *ptr = &number;   ← 宣言時の * は「ポインタ型」を示す\n     ↓\n*ptr = 100;           ← 使用時の * は「参照先にアクセス」を示す
💡 Webエンジニア向けメモ
「ポインタ」って難しそうに聞こえますが、実はJavaScriptやRubyでも似た概念はあります。 オブジェクトを変数に代入すると、値のコピーではなく「参照」が渡される、あれです。 C言語のポインタは、その参照を明示的に操作できるというだけの話なんです。

メモリの動的確保（malloc / free）

スタックとヒープ

ここまで見てきた変数は、すべてスタック領域に確保されていました。スタック領域の変数は、関数が終了すると自動的に解放されます。

一方、ヒープ領域は、プログラマが明示的に確保・解放するメモリです。

┌─────────────────────────────────────────────────────────────┐\n│                                                             │\n│   スタック領域                    ヒープ領域                 │\n│   ─────────────                  ─────────────              │\n│                                                             │\n│   ✅ 自動で確保・解放              ⚠️  手動で確保・解放       │\n│   ✅ 高速                         ⚠️  やや低速               │\n│   ❌ サイズはコンパイル時に決定     ✅ サイズを実行時に決定可能 │\n│   ❌ 関数内でのみ有効              ✅ 関数をまたいで使える     │\n│                                                             │\n│   用途: ローカル変数               用途: 可変長データ、        │\n│        関数の引数                      長期間保持するデータ   │\n│                                                             │\n└─────────────────────────────────────────────────────────────┘

RubyやJavaScriptでは new するだけでヒープにオブジェクトが作られますが、C言語では自分で「これだけのメモリをください！」とOSにお願いする必要があります。それが malloc() です。

malloc と free

ファイル名: malloc_basic.c

#include <stdio.h>\n#include <stdlib.h>  // malloc, free に必要\n\nint main() {\n    printf(\"=== 動的メモリ確保 ===\\n\\n\");\n    \n    // 整数1つ分のメモリを確保\n    // ※C言語ではmallocの戻り値(void*)は暗黙的にキャストされるため、\n    //   キャストは省略可能です。ここでは意図を明示するために記載しています。\n    //  （C++ではキャストが必須です）\n    int *ptr = (int *)malloc(sizeof(int));\n    \n    // 確保できたか確認（重要！）\n    if (ptr == NULL) {\n        printf(\"メモリの確保に失敗しました\\n\");\n        return 1;\n    }\n    \n    printf(\"メモリを確保しました\\n\");\n    printf(\"確保したアドレス: %p\\n\", (void*)ptr);\n    printf(\"確保したサイズ: %zu バイト\\n\\n\", sizeof(int));\n    \n    // 確保したメモリに値を格納\n    *ptr = 12345;\n    printf(\"格納した値: %d\\n\\n\", *ptr);\n    \n    // メモリを解放\n    free(ptr);\n    printf(\"メモリを解放しました\\n\");\n    \n    // 解放後のポインタはNULLにするのが安全\n    ptr = NULL;\n    \n    return 0;\n}

実行結果

gcc -o malloc_basic malloc_basic.c\n./malloc_basic
=== 動的メモリ確保 ===\n\nメモリを確保しました\n確保したアドレス: 0x55a8b6c4a2a0\n確保したサイズ: 4 バイト\n\n格納した値: 12345\n\nメモリを解放しました

malloc → 使う → free の3ステップ。これがC言語のメモリ管理の基本です。free を忘れると大変なことになりますが、それは後ほど

配列を動的に確保する

スタック上の配列は int array[5]; のようにサイズをコンパイル時に決める必要がありますが、malloc を使えば実行時にサイズを決められます。

ファイル名: malloc_array.c

#include <stdio.h>\n#include <stdlib.h>\n\nint main() {\n    int n;\n    printf(\"配列の要素数を入力してください: \");\n    scanf(\"%d\", &n);\n    \n    // n個のint配列を動的に確保\n    int *array = (int *)malloc(sizeof(int) * n);\n    \n    if (array == NULL) {\n        printf(\"メモリの確保に失敗しました\\n\");\n        return 1;\n    }\n    \n    printf(\"\\n%d個のint型配列を確保しました\\n\", n);\n    printf(\"確保したサイズ: %zu バイト\\n\", sizeof(int) * n);\n    printf(\"先頭アドレス: %p\\n\\n\", (void*)array);\n    \n    // 配列に値を格納\n    for (int i = 0; i < n; i++) {\n        array[i] = i * 10;\n    }\n    \n    // 配列の内容とアドレスを表示\n    printf(\"インデックス | 値   | アドレス\\n\");\n    printf(\"-------------|------|------------------\\n\");\n    for (int i = 0; i < n; i++) {\n        printf(\"    %d        | %3d  | %p\\n\", i, array[i], (void*)&array[i]);\n    }\n    \n    // メモリを解放\n    free(array);\n    array = NULL;\n    \n    printf(\"\\nメモリを解放しました\\n\");\n    \n    return 0;\n}

同様に実行すると？

実行結果

配列の要素数を入力してください: 5\n\n5個のint型配列を確保しました\n確保したサイズ: 20 バイト\n先頭アドレス: 0x55a8b6c4a2a0\n\nインデックス | 値   | アドレス\n-------------|------|------------------\n    0        |   0  | 0x55a8b6c4a2a0\n    1        |  10  | 0x55a8b6c4a2a4\n    2        |  20  | 0x55a8b6c4a2a8\n    3        |  30  | 0x55a8b6c4a2ac\n    4        |  40  | 0x55a8b6c4a2b0\n\nメモリを解放しました

アドレスが4バイトずつ増えているのがわかりますか？ これは int 型が4バイトだからです。メモリ上にきれいに並んでいるのが見えると、配列の正体がよくわかりますね。

💡 Webエンジニア向けメモ
GoやRustでは make([]int, n) や Vec::with_capacity(n) のように、 動的にサイズを指定して配列やスライスを作ることがよくあります。 裏側では似たようなヒープへのメモリ確保が行われています。

メモリリークを体験する

メモリリークとは？

メモリリークとは、確保したメモリを解放し忘れることで、使えるメモリが徐々に減っていく現象です。Webアプリの運用でよくある「なぜかメモリ使用量が右肩上がりで、定期的に再起動しないといけない」の原因、だいたいコレです。

ファイル名: memory_leak.c

#include <stdio.h>\n#include <stdlib.h>\n\nvoid bad_function() {\n    // メモリを確保するが、解放しない（これがメモリリーク！）\n    int *ptr = (int *)malloc(sizeof(int) * 1000);\n    if (ptr == NULL) return;\n    *ptr = 42;\n    // free(ptr); ← これがない！\n}\n\nvoid good_function() {\n    int *ptr = (int *)malloc(sizeof(int) * 1000);\n    if (ptr == NULL) return;\n    *ptr = 42;\n    free(ptr);  // ちゃんと解放\n}\n\nint main() {\n    printf(\"=== メモリリークのデモ ===\\n\\n\");\n    \n    printf(\"bad_function を1000回呼び出します...\\n\");\n    for (int i = 0; i < 1000; i++) {\n        bad_function();\n    }\n    printf(\"完了（約4,000,000バイトがリークしています）\\n\\n\");\n    \n    printf(\"good_function を1000回呼び出します...\\n\");\n    for (int i = 0; i < 1000; i++) {\n        good_function();\n    }\n    printf(\"完了（メモリリークなし）\\n\");\n    \n    return 0;\n}

bad_function は1回呼ぶたびに sizeof(int) * 1000 = 4,000バイト をリークします。1,000回呼ぶと約4,000,000バイト（約3.8MB）の漏れです。たった数行の free の書き忘れで、これだけのメモリが無駄になるんですね。

Valgrindでメモリリークを検出

C言語にはメモリリークを検出する定番ツール Valgrind があります。Linuxでは、以下で確認できます！

# Valgrindのインストール（Ubuntu）\nsudo apt install valgrind\n\n# コンパイル（デバッグ情報付き）\ngcc -g -o memory_leak memory_leak.c\n\n# Valgrindで実行\nvalgrind --leak-check=full ./memory_leak

検出結果

==12345== LEAK SUMMARY:\n==12345==    definitely lost: 4,000,000 bytes in 1,000 blocks\n==12345==    indirectly lost: 0 bytes in 0 blocks\n==12345==      possibly lost: 0 bytes in 0 blocks\n==12345==    still reachable: 0 bytes in 0 blocks\n==12345==         suppressed: 0 bytes in 0 blocks

definitely lost: 4,000,000 bytes — バッチリ検出されました！ こんなふうに、C言語ではメモリの問題を直接確認できます。

💡 Webエンジニア向けメモ
Node.jsでも同様のメモリリークは起こります。例えば、グローバル変数に配列を追加し続けたり、イベントリスナーを解除し忘れたり、クロージャで大きなオブジェクトを参照し続けたり。原理は同じで、「使わなくなったメモリが解放されない」ことが問題です。
Node.jsの場合は --inspect フラグをつけて起動し、Chrome DevToolsの「Memory」タブでHeap Snapshotを取ると、Valgrindのようにリークを調査できます。Goなら pprof が同様のツールになります。

スタックとヒープの違いを実感する

ダングリングポインタの危険

最後に、スタックとヒープの違いが生む典型的なバグを見てみましょう。

ダングリングポインタとは、すでに無効になったメモリを指すポインタのことです。「存在しない住所が書かれたメモ」みたいなものですね。

ファイル名: dangling.c

#include <stdio.h>\n#include <stdlib.h>\n\n// ダメな例：スタック上の変数のアドレスを返す\nint* bad_get_number() {\n    int local = 42;\n    return &local;  // ⚠️ 関数終了後、localは無効になる\n}\n\n// 良い例：ヒープ上にメモリを確保して返す\nint* good_get_number() {\n    int *ptr = (int *)malloc(sizeof(int));\n    if (ptr == NULL) return NULL;\n    *ptr = 42;\n    return ptr;  // ✅ ヒープ上なので関数終了後も有効\n}\n\nint main() {\n    printf(\"=== ダングリングポインタのデモ ===\\n\\n\");\n    \n    printf(\"【危険】スタック上の変数を返す場合:\\n\");\n    int *bad = bad_get_number();\n    printf(\"アドレス: %p\\n\", (void*)bad);\n    // ⚠️ この行は未定義動作です！何が表示されるかわかりません\n    // コンパイラの最適化レベルによって挙動が変わります\n    printf(\"値（未定義動作！）: %d\\n\\n\", *bad);\n    \n    printf(\"【安全】ヒープ上のメモリを返す場合:\\n\");\n    int *good = good_get_number();\n    if (good != NULL) {\n        printf(\"アドレス: %p\\n\", (void*)good);\n        printf(\"値: %d\\n\", *good);\n        free(good);  // 使い終わったら解放\n    }\n    \n    return 0;\n}

コンパイル時の警告

# 最適化なしでコンパイル（未定義動作の挙動を確認するため）\ngcc -Wall -O0 -o dangling dangling.c
dangling.c: In function 'bad_get_number':\ndangling.c:7:12: warning: function returns address of local variable [-Wreturn-local-addr]\n    7 |     return &local;\n      |            ^~~~~~

コンパイラが警告してくれますね！ -Wall オプションをつけてコンパイルすると、こうした危険なコードを事前にキャッチできます。

この例がまさに「スタック vs ヒープ」の違いです。スタック上の変数（local）は関数を抜けた瞬間に無効になりますが、ヒープ上のメモリ（malloc で確保したもの）は free するまで有効。だからこそ、ヒープに確保して返すのが正しいパターンなんです。ただし、前述のメモリリークのように、freeを忘れないようにしないといけません！

💡 Webエンジニア向けメモ
GoやRustでは、この種のバグはコンパイラが防いでくれます。 Goでは「エスケープ解析」によって、関数外に渡される変数は自動的にヒープに配置されます。 go build -gcflags=\"-m\" で確認できるので、興味のある方はぜひ試してみてください。 Rustではさらに厳密で、所有権とライフタイムの仕組みによって、ダングリングポインタの発生をコンパイル時に完全に防いでいます。

まとめ

今回学んだことを整理しましょう。

┌─────────────────────────────────────────────────────────────────┐\n│                        今回のまとめ                             │\n├─────────────────────────────────────────────────────────────────┤\n│                                                                 │\n│  1. メモリにはアドレスがある                                     │\n│     → & でアドレスを取得、%p で表示                              │\n│                                                                 │\n│  2. ポインタ = アドレスを格納する変数                            │\n│     → int *ptr = &number;                                       │\n│     → *ptr でポインタが指す値にアクセス                          │\n│                                                                 │\n│  3. 動的メモリ確保                                               │\n│     → malloc() で確保、free() で解放                             │\n│     → 解放を忘れるとメモリリーク                                 │\n│                                                                 │\n│  4. スタック vs ヒープ                                           │\n│     → スタック：自動管理、関数内で有効                           │\n│     → ヒープ：手動管理、プログラム全体で有効                     │\n│                                                                 │\n└─────────────────────────────────────────────────────────────────┘

Web系っぽい言語との対応

C言語で学んだ概念は、普段使っている言語にも対応しています。

C言語Web系っぽい言語での対応
malloc()new Object() / オブジェクト生成
free()GC（ガベージコレクション）が自動で行う
ポインタ参照（Reference）
スタックプリミティブ型の値（※言語による）
ヒープオブジェクト / 配列（※言語による）

※ スタックとヒープの割り当ては言語や実装によって異なります。例えばGoではエスケープ解析によって、見た目はローカル変数でもヒープに配置されることがあります。上記はJavaでの一般的なイメージとして参考にしてください。

前回のリンクの話と今回のメモリの話で、だいぶコンピュータの「裏側」が見えてきたのではないでしょうか？ この知識があると、Dockerのリソース制限とかOOMKilledとか、「あ、あれのことね」とピンとくるようになりますよ！

たぶん！

こちらからは以上です。

","url":"https://ghost.tech.anti-pattern.co.jp/imasarali-jie-suru-sutateitukurinku-to-dainamitukurinku-webapurikesiyonenzinianotamenodi-reiyaru-men-sirizu-sono1/","canonical_url":null,"uuid":"cf1eb7b4-97b2-48b1-bd1f-52c311a96dc8","page":null,"codeinjection_foot":null,"codeinjection_head":null,"codeinjection_styles":null,"comment_id":"69c3346171fa390001b3661c","reading_time":9}},"pageContext":{"slug":"imasarali-jie-suru-sutateitukurinku-to-dainamitukurinku-webapurikesiyonenzinianotamenodi-reiyaru-men-sirizu-sono1"}}, "staticQueryHashes": ["176528973","2358152166","2561578252","2731221146","4145280475"]}