trylock()通过非阻塞获取锁并配合超时释放已持锁，打破“持有并等待”条件以避免死锁；必须在finally中手动unlock，超时值需依场景设定并避免同步重试，结合固定锁顺序效果更佳。

ReentrantLock 的 tryLock() 方法是避免死锁最直接有效的手段之一，它不阻塞线程，而是立即返回获取结果，把“等不等得到锁”这个决定权交还给业务逻辑。

tryLock 如何打破死锁的循环等待链

死锁常发生在多个线程以不同顺序争抢多把锁（比如 lockA 和 lockB）时。传统 lock() 会让线程在拿不到锁时无限挂起，一旦形成 AB-BA 依赖，就卡死。

tryLock() 的关键作用是：让线程主动放弃等待，而不是被动僵持。 它通过以下方式干预死锁发生过程：

• 线程尝试获取第一把锁成功后，再用 tryLock(timeout, unit) 去争第二把锁
• 若超时未拿到，就主动释放已持有的锁，退出临界区或走降级路径
• 这样就打破了“持有并等待”条件，也消除了循环等待的可能性

必须配合 finally 释放锁，否则照样泄漏

tryLock() 成功后，锁仍需手动释放——这点和 lock() 完全一致。如果只在 try 块里 unlock，异常抛出时就会跳过，导致锁永久占用。

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

正确写法唯一安全位置是 finally 块：

• 先调用 tryLock(100, TimeUnit.MILLISECONDS)，返回 true 才进入业务逻辑
• 无论业务是否抛异常、是否提前 return，都必须在 finally 中调用 unlock()
• 不能把 unlock() 放在 catch 或 else 分支里——没拿到锁时调用会抛 IllegalMonitorStateException

超时时间设置要兼顾业务与并发压力

超时不是越短越好，也不是越长越稳，需要结合场景权衡：

• Web 接口类操作建议 100–500ms；高频交易可压到 10–50ms
• 避免所有线程用相同超时值，否则容易集体失败重试，引发惊群效应
• 可加入随机偏移（如 80–120ms），或按重试次数递增（100ms → 200ms → 400ms）
• 超时后别盲目重试，应记录日志、触发告警，或切换缓存/默认值等容错策略

搭配固定锁顺序，双保险防死锁

单独用 tryLock() 能缓解死锁，但最稳妥的是和“统一加锁顺序”结合使用：

• 例如转账场景：始终先 lock id 小的账户，再 lock id 大的账户
• 在此基础上，第二把锁改用 tryLock(200, MILLISECONDS)
• 即使某次因调度原因两个线程几乎同时启动，也不会陷入互相等待，最多一个成功、一个降级
• 既守住结构性防线（顺序），又留出弹性空间（超时退让）

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南