多级评论区后端异步刷新需用线程状态机杜绝并发死锁：定义Idle、Pending、Executing、Completed/Failed四态，通过CAS原子跃迁替代锁，严格校验状态流转，拦截越权跳变并熔断超时任务。
多级评论区的后端异步刷新模块中，并发多路死锁不是靠“检测到再处理”，而是要从状态流转源头杜绝——核心在于用线程状态机（Thread State Machine）对每个刷新请求建模，把“是否允许进入临界操作”变成可判定、可拦截的确定性状态跃迁。
明确状态边界：定义四个关键线程状态
不依赖全局锁或超时重试，而是为每个评论刷新上下文（如 comment_id + user_id + action_type）绑定一个轻量状态机实例：
- Idle：初始态，无任何刷新任务挂起，可安全接收新请求
- Pending：已入队但未执行，处于异步调度等待中；此时拒绝同键重复提交
- Executing：正在执行 DB 查询/缓存更新/子评论拉取等耗时操作；此状态下所有同键新请求直接拦截并返回 425 Too Early
- Completed / Failed：终态，自动清理资源；若失败且含幂等标识，可转入 Pending 重试，否则永久拒绝
用原子状态跃迁替代锁竞争
避免使用 synchronized 或 lock 造成线程阻塞。改用 CAS（Compare-And-Swap）语义做状态推进：
- Java 可用
AtomicInteger编码状态值，配合compareAndSet(old, new) - Python 可借助
threading.local()+dict配合setdefault做线程局部状态快照，主流程用 Redis 的SETNX+ 过期时间实现分布式状态注册 - 每次刷新请求到来时，先尝试从 Idle → Pending；仅当成功才真正分发任务；失败即说明已有同键请求在途，直接拦截
拦截恶意并发的关键判定逻辑
所谓“恶性”并非指高并发本身，而是指违反状态契约的越权跃迁。需在入口处强制校验：
- 禁止
Pending → Executing跳变（必须经由调度器主动触发） - 禁止
Executing → Pending回退（防止重入） - 同一 key 在
Executing态持续超 3s，自动标记为疑似死锁，触发熔断：清空本地状态 + 向监控上报 + 返回降级数据（如缓存快照） - 对连续 3 次被拦截的客户端 IP，临时加入速率限制名单（非封禁，是延时响应）
与异步刷新链路自然融合
状态机不独立存在，而是嵌入现有异步流程：
- 刷新任务封装为
RefreshTask，构造时携带状态机引用 - Executor 执行前校验状态是否为
Pending，是则置为Executing；执行结束无论成败，最终置为Completed或Failed - 前端轮询或 WebSocket 推送的“刷新完成”事件，只在
Completed态下发出，避免 UI 层收到中间态脏数据
