システム開発やデータベース運用の現場では「処理がデッドロックを起こしている」というログやエラーメッセージを見かけることがあります。
なぜ処理が止まってしまうのか、似たような言葉である競合状態やスタベーションとはどう違うのか、気になった方もいるのではないでしょうか。
デッドロックとは、ひとことで言えば、複数の処理が互いの持つリソースの解放を待ち合い、どちらも先に進めなくなる状態のことです。
この記事では、デッドロックの意味や発生の仕組み、具体例、競合状態・スタベーションとの違いについてわかりやすく解説します。
デッドロックとは
デッドロックとは、コンピュータシステムの中で複数の処理が互いに相手の持つリソースの解放を待ち合い、どちらも先に進めなくなってしまう状態のことです。
ここでいうリソースとは、データベースのテーブルやファイル、メモリ領域など、処理が使用する資源全般を指します。
日本語では「膠着状態」と表現されることもあり、プログラミングやシステム運用の現場で使われる専門用語です。
データベースの排他制御、オペレーティングシステムのプロセス管理、マルチスレッドのプログラムなど、複数の処理を並行して進める仕組みで起こりやすい現象です。
デッドロックが起こる仕組み
四つの条件が重なると発生する
デッドロックは、特定の条件がすべて重なったときに発生すると説明されることが多いです。
一つ目は、同じリソースを複数の処理が同時には使えないという条件です。
二つ目は、処理がすでに確保したリソースを手放さずに、別のリソースの空きを待ち続ける条件です。
三つ目は、処理の途中で確保したリソースを他の処理から横取りされない条件です。
四つ目は、複数の処理が輪のようにつながり、互いの持つリソースを待ち合う条件です。
この四つの条件が同時に成り立つ状態は「コフマン条件」と呼ばれることがあり、並行処理の分野で理論的な整理として知られています。
デッドロックが発生する具体例
代表的なのは、データベースのトランザクション処理で起こるデッドロックです。
たとえば、処理Aがテーブル甲をロックしてからテーブル乙のロックを待ち、同時に処理Bがテーブル乙をロックしてからテーブル甲のロックを待つ場合です。
この場合、処理Aと処理Bはどちらも相手がロックを解放するまで動けず、待ち続けることになります。
ECサイトのように、在庫情報と注文情報を同時に更新するシステムでは、更新の順序がばらつくとこうした状況が起こりやすくなります。
また、複数のスレッドが共有メモリや共有ファイルにアクセスするプログラムでも、似た構造のデッドロックが起こることがあります。
デッドロックが起きるとどうなる？
デッドロックが発生すると、関係する処理はどちらも応答を返さなくなり、見かけ上システムが固まったような状態になります。
利用者からすると、画面の操作が反応しなくなったり、処理が長時間終わらなかったりする形で現れます。
放置しても自然に解消されることは少なく、何らかの仕組みで強制的に処理を止める必要があります。
デッドロックの検出と解消方法
多くのデータベース管理システムには、デッドロックを自動的に検出する仕組みが組み込まれています。
検出されると、関係する処理のうちいずれか一方が選ばれ、処理内容を取り消すロールバックという形で強制的に中断されます。
中断された処理はエラーとして呼び出し元に通知され、必要であれば改めて処理をやり直す設計にしておきます。
オペレーティングシステムの層では、一定時間応答がない処理にタイムアウトを設定し、自動的に終了させる方法も使われます。
デッドロックを防ぐための対策
- 複数のリソースへアクセスする際は、システム全体で順序をそろえておく
- 一つの処理が複数のリソースを保持する時間を短くする
- ロックをかける範囲を必要最小限にとどめる
- 一定時間待っても解放されない場合に処理を中断するタイムアウトを設定する
- 発生状況を把握するため、ログを定期的に確認する
設計の段階でこれらの点を意識しておくことで、デッドロックの発生頻度を抑えられます。
完全に起こらないようにすることは難しいため、発生を前提にした復旧の仕組みを合わせて用意しておくことも大切です。
デッドロックと競合状態の違い
競合状態（レースコンディション）とは、複数の処理が同じデータへほぼ同時にアクセスし、実行される順序によって結果が変わってしまう問題のことです。
デッドロックとの大きな違いは、処理が完全に停止するかどうかという点です。
| 観点 | デッドロック | 競合状態 |
|---|---|---|
| 状態 | 関係する処理が止まって進まなくなる | 処理は進むが結果が不安定になる |
| 原因 | リソースの取得順序が噛み合わない | 処理の実行順序が保証されていない |
| 気づきやすさ | 処理が固まるため気づきやすい | 結果の不整合として現れるため気づきにくい |
どちらも並行処理に伴って起こる問題ですが、現れ方と対策の方向性が異なります。
デッドロックとスタベーションの違い
スタベーション（starvation）とは、特定の処理だけがいつまでもリソースを割り当てられず、実行の順番が回ってこない状態のことです。
デッドロックは関係する処理すべてが停止するのに対し、スタベーションでは他の処理は進んでいるのに一部の処理だけが取り残される点が異なります。
優先度の高い処理ばかりが先に実行される仕組みでは、優先度の低い処理がスタベーションに陥りやすくなります。
デッドロックを使った例文
- 夜間に実行するバッチ処理でデッドロックが発生し、翌朝まで処理が止まっていた
- 複数のテーブルを更新するプログラムでは、ロックの順序をそろえてデッドロックを避けるようにしている
- 本番環境のログを確認すると、同じ時間帯にデッドロックが繰り返し記録されていた
- 会議で双方が意見を譲らず、話し合いがデッドロック状態に陥ってしまった
最後の例のように、システムの用語としてだけでなく、交渉や話し合いが進まない状況を比喩的に表す際にも使われます。
デッドロックに関するよくある誤解
デッドロックはプログラムの不具合が原因で必ず起こるものだと誤解されることがありますが、正しく動くプログラムでも設計上の構造によって起こり得る現象です。
処理が重いサーバーだけで起こるという誤解もありますが、処理の負荷そのものよりも、リソースを確保する順序の方が原因として大きく関わります。
一度デッドロックが発生した処理は、同じ条件が重なれば再び起こる可能性があるため、発生箇所を特定して設計を見直すことが重要です。
まとめ
デッドロックとは、複数の処理が互いの持つリソースの解放を待ち合い、どちらも先に進めなくなる状態のことです。
発生には複数の条件が重なる必要があり、データベースの排他制御やマルチスレッドの処理など、並行して動く仕組みの中で起こりやすい現象です。
競合状態は処理が進みながら結果が不安定になる問題、スタベーションは一部の処理だけが取り残される問題という点で、デッドロックとは現れ方が異なります。
アクセス順序の統一や処理範囲の最小化といった対策を講じつつ、発生を前提にしたログの確認や復旧の仕組みを備えておくことが大切です。
コメント