CPU は1回に1仕事しかできない
でも私たちは毎日、何十ものアプリを「同時に」使っている。この矛盾をどう解いているのかが、このページの主題である。
もし順番待ちだったら…
- ―音楽アプリが 5秒 CPU を使う
- ―その間、ブラウザは 5秒間フリーズ
- ―LINE も 10秒間止まる
これは使い物にならない
スケジューリングの解決策
- ―CPU 時間を「タイムスライス」（1〜10ms）に分割する
- ―各アプリに順番に時間を配る
- ―切り替えが速すぎて「同時」に見える
これが「時分割（Time-sharing）」である
映画は実は1秒間に24枚の静止画を連続表示しているだけ。CPUスケジューリングも同じ原理で、 アプリの切り替えが1秒間に何百回も起きるから「全部同時に動いている」ように錯覚する。 この切り替えの仕組みを OS の スケジューラ が担っている。
プロセスの5つの状態
(Ready)
(Running)
(Exit)
(Waiting)
スケジューラは「準備完了」キューから次に実行するプロセスを選ぶ
3つのスケジューリングアルゴリズム
「次に誰を選ぶか」の方針が、そのままアルゴリズムの違いになる。
FCFS
First Come, First Served
到着順に1つずつ処理。シンプルであるが、長いプロセスが来ると後続が全員待たされる（護送船団問題）。
ラウンドロビン (RR)
Round Robin
全プロセスに均等な「タイムスライス（量子）」を順番に配る。現代のOSの基本。応答性が高い。
優先度スケジューリング
Priority Scheduling
各プロセスに優先度を設定。高優先度が先に実行される。低優先度プロセスが無期限に待つ「飢餓」問題あり。
| アルゴリズム | 応答時間 | スループット | 飢餓 | 主な用途 |
|---|---|---|---|---|
| FCFS | 悪い | 普通 | なし | バッチ処理 |
| ラウンドロビン | 良い | 良い | なし | 対話型OS（基本） |
| 優先度 | 条件付 | 条件付 | あり | リアルタイムOS |
スケジューリング シミュレータ
プロセスを足したりアルゴリズムを切り替えたりして、ガントチャートと統計がどう変わるかを見てください。同じプロセス群でも、方針が変われば待ち時間はまったく違う値になる。
アルゴリズム選択
プロセス一覧
CPU コア ― 今何を実行中？
ガントチャート
各行 = プロセス、各列 = 時刻パフォーマンス統計
現代 OS のスケジューラ
実際の OS は、ここまで見た3つよりはるかに複雑な方式を使っている。
Linux — CFS
Completely Fair Scheduler。仮想実行時間（vruntime）を追跡し、 最も「仮想時間が少ない」プロセスを次に選ぶ赤黒木ベースのアルゴリズム。 「完全に公平」な CPU 時間配分を目指す。
Windows — MLFQ
Multi-Level Feedback Queue。複数の優先度キューを持ち、 CPU をたくさん使うプロセスは自動的に低優先度に降格。 対話的（UIをよく触る）プロセスは高優先度に昇格。
macOS/iOS — GCD
Grand Central Dispatch。スレッドではなくキューベースの非同期処理。 QoS（Quality of Service）クラスで優先度を指定。 「UI は必ず最優先」が保証される。
リアルタイムOS
工場の制御システム・自動車のブレーキ制御など、「必ず〇ms以内に応答」を 保証しなければならない場面では、EDF（Earliest Deadline First）などのリアルタイム スケジューラが使われる。
現代の CPU は複数コアを持つ（例：M3 Pro は12コア）。OS はコア間の負荷分散も管理する。 同じプロセスをどのコアで動かすか、コアを跨いでプロセスを移動する際のキャッシュ効率、 さらに CPU の「大小コア」を使い分ける ヘテロジニアス設計 (Apple Silicon / Arm big.LITTLE) など、現代のスケジューリングは非常に複雑である。