基本情報 平成23年度 春期 問34：テクノロジ系に関する問題

答えは d です。

デッドロック＝「お見合い状態で動けない」こと。Aさんが「Bさんが持ってる本を待つ」と同時にBさんが「Aさんの本を待つ」状況では、2人とも永遠に動けません。データベースでも同じことが起きます。

👉 覚え方：「お互いに相手のロック資源を待つ＝デッドロック」。

ほかの選択肢：a 2相ロックの説明／b 普通の競合（片方が待つだけ）／c 排他ロックの説明。

なぜこれが正解か

正解は d。デッドロック（dead lock、デッド＝動けない、ロック＝鍵）とは、複数のトランザクションが互いに相手がロックしている資源を要求し、循環待ちが発生して全員が無期限に待ち続ける状態。

各選択肢の解説

• a：2相ロックプロトコルの説明。第1相で全ロック取得、第2相で解除する手順で直列化可能性を保証する技法。
• b：単なるロック競合の説明。片方が待つだけならデッドロックではない。
• c：排他ロック（exclusive lock）の説明で、デッドロックではない。

覚え方・ひっかけ注意

デッドロックの3条件＋循環待ち（Coffman条件）：①相互排他、②保持と待機、③横取り不可、④循環待ち。1つでも欠ければデッドロックは発生しない。検出後の解決はトランザクションをロールバック（犠牲化）するのが一般的。

理論的背景

デッドロックはCoffmanの4条件（相互排他・保持と待機・横取り不可・循環待ち）が同時成立した時に発生する。対策には ①予防（条件のいずれかを成立させない、例：ロック順序の統一）、②回避（バンカーズアルゴリズム等で安全状態を判定）、③検出と回復（待ちグラフでサイクル検出→トランザクションをアボート）、④無視（オストリッチアルゴリズム＝発生率が低ければ何もしない）がある。DBMSは通常③を採用し、待ちグラフ（Wait-For Graph）の周期検出でデッドロックを発見する。

実務での使われ方

MySQL InnoDB・PostgreSQL・Oracle・SQL Serverともデッドロック検出機構を内蔵し、検出時はコスト最小のトランザクションをロールバックして他を進行させる。アプリケーション側ではデッドロック例外（MySQLの1213エラー、PostgreSQLの40P01）を捕捉してリトライする実装が一般的。設計上の対策として「ロック順序を全アプリで統一」「ロック範囲を最小化」「短期ロック」「インデックス活用」が定石。

試験での位置づけ

基本情報・応用情報のデータベース分野で必出。2相ロック・直列化可能性・トランザクションのACID特性・分離レベル（Read Uncommitted/Read Committed/Repeatable Read/Serializable）と組合せて出題される。データベーススペシャリストではMVCC（多版同時実行制御）、楽観/悲観ロック、分散トランザクション（2相コミット）まで深掘りされる。

選択肢の発展補足

2相ロック（2PL: Two-Phase Locking）には厳格2PL（strict 2PL）（コミットまで全ロック保持）・保守的2PL（開始時に全ロック取得）等の変形がある。MVCC（PostgreSQL・OracleのRead Committed以上、MySQL InnoDB）はロックを使わず複数バージョンで読み込みを並列化するためデッドロック耐性が高い。分散システムではPaxos/Raft等の合意プロトコルや、マイクロサービスのSagaパターンで分散トランザクションを実現する。