死锁检测需在资源分配时主动检查有向图环路；C++需自建资源分配图模型，统一用Node抽象进程与资源，按ID范围区分，边方向须严格对应“申请→资源”或“资源→持有者”，再用DFS判环。
死锁检测不能靠“等它发生再处理”，必须在资源分配时主动检查图中是否存在环路；C++ 标准库不提供现成的资源分配图模型，得自己建模 + 用 DFS 或 Floyd 判环。
如何用邻接表表示资源分配图
资源分配图本质是有向图：进程节点指向它申请但未获得的资源，资源节点指向已持有它的进程。为统一处理，把进程和资源都抽象为 Node，用类型字段区分；边用 std::vector<std::vector<int>> 存邻接矩阵更直观（节点数通常不大），或用 std::vector<std::vector<size_t>> 存邻接表索引。
- 建议给每个进程分配 ID 0～P−1，每个资源分配 ID P～P+R−1，这样单个整数就能唯一标识所有节点
- 边
u → v表示“u 等待 v”（即 u 是进程、v 是资源，且 u 已申请 v）或“v 持有 u”（即 v 是资源、u 是进程，且 v 当前被 u 占用）——注意方向别反，否则环路语义错乱 - 初始化时，对每个已分配资源的
(process_id, resource_id)对，加一条边：resource_id → process_id（资源→持有者）；对每个等待资源的(process_id, resource_id)对，加一条边：process_id → resource_id（申请者→资源）
用 DFS 检测有向图中是否存在环路
DFS 判环比 Floyd 更轻量，适合实时检测；关键不是找具体环，而是快速返回“是否成环”。需维护三个状态数组：unvisited、visiting（当前 DFS 栈中）、visited（已确认无环）。
- 遇到
visiting[u] == true就说明从当前路径回到 u，构成环，立即返回true - 递归返回前设
visited[u] = true，避免重复遍历；visiting[u]只在进入/退出 DFS 时置true/false - 必须对每个
unvisited节点启动 DFS，因为图可能不连通；但不用对资源节点单独启动——只要建图正确，进程和资源都在同一张图里 - 示例片段：
bool has_cycle_dfs(int u) {<br> if (visiting[u]) return true;<br> if (visited[u]) return false;<br> visiting[u] = true;<br> for (int v : graph[u])<br> if (has_cycle_dfs(v)) return true;<br> visiting[u] = false;<br> visited[u] = true;<br> return false;<br>}
资源请求时触发检测的时机与开销控制
每次 request_resource(p, r) 都应构造临时图并判环；但若直接复用全局图结构，要注意并发安全——检测过程必须是只读的，且不能阻塞其他线程的分配操作。
立即学习“C++免费学习笔记（深入）”；
- 推荐做法：检测前快照当前分配/等待关系（用
std::shared_lock<std::shared_mutex>读取），构造一个只读的局部邻接表，再调 DFS；避免在检测中加互斥锁 - 若检测出环，不要自动回滚；应返回失败并由上层决定 kill 哪个进程（比如选等待时间最长的），否则会掩盖设计问题
- 性能敏感场景可加缓存：若两次请求间无任何分配/释放变更，跳过检测；用版本号或
std::atomic<size_t>记录图变更次数 - 注意：仅检测“当前请求加入后是否成环”，不是检查历史状态；所以边要包含新请求：
p → r必须加入图中再判环
真正难的不是写 DFS，而是保证图模型和边方向与真实资源流转严格一致；少加一条“资源→持有者”边，或多加一条“进程→资源”边，环就检不出来或者误报——建图逻辑必须和你的资源管理器的状态更新完全同步。
