銀行家演算法（banker's algorithm）
/ DYKE-struh (Dijkstra) /
想像一位現金有限的銀行家，已向好幾位客戶承諾了信用額度。每位客戶都說出自己可能借到的上限。銀行家一筆一筆地放款，但在兌現任何提款前，她會在心裡檢查：「如果我把這筆放出去，我還能不能藉由小心地收回再放貸，一個接一個地滿足每位客戶的全額上限而永不見底？」只有答案為是時她才付款。銀行家演算法由艾茲赫爾·戴克斯特拉（Edsger Dijkstra）提出，正是把這套推理用在電腦配置資源上。
它使用四個資料結構（把資源想成錢）：可用量（Available，每種類型的空閒實例）、最大需求（Max，每個行程宣告它可能需要的上限）、已配置（Allocation，每個行程目前持有的量）、需求量（Need = Max 減 Allocation，每個行程還可能索取的量）。當行程請求資源時，演算法分兩部分。先做一個快速合法性檢查：請求不得超過該行程的 Need 或可用量池。接著它「假裝」批准請求，並執行安全檢查：能否找到一種順序，使每個行程的 Need 都能由可用量加上較早完成的行程所釋放的量來滿足？若存在安全序列，就正式批准；若不存在，就回復並讓行程等待，即使資源在實體上是空閒的。
銀行家演算法是死結避免的教科書化身，但要對它的限制誠實：它在真實的通用作業系統中很少使用。它要求每個行程事先宣告其 Max（通常未知）、假設行程與資源類型的集合固定，且對每一筆請求都要跑安全檢查——對 m 種資源類型與 n 個行程而言，其工作量約為 m 乘以 n 的平方。結果正確而優雅，但對行程來來去去、需求難以預測的系統而言太僵化也太昂貴，這就是為何多數作業系統寧可無視死結。
可用量 = 3。需求量：P0 = 5、P1 = 2、P2 = 7。安全檢查找到序列 P1（需 2，從 3 取）-> 完成、釋放，使可用量上升；接著 P0；再 P2——各 Need 依序皆獲滿足。所以目前狀態安全，合適的請求可獲批准。
安全檢查搜尋一種順序，使每個行程剩餘的 Need 都能被滿足。
儘管它是著名的避免演算法，通用作業系統卻幾乎不用它：事先宣告 Max 通常不可能、行程與資源集合被假設固定，且安全檢查要對每筆請求執行（約 m 乘以 n 的平方）。