ReentrantLock 的 tryLock() 是非阻塞锁获取方式：无参版本瞬时判断，带超时版本在指定时间内尝试；仅获锁成功后才可 unlock()，且须置于 finally 块中；适用于快速失败、避免死锁和降级处理等场景。
ReentrantLock 的 tryLock() 是一种明确的非阻塞竞争策略：它不等待、不挂起线程，只在调用瞬间做一次原子判断——锁空闲则抢到并返回 true；否则立刻返回 false，把决策权完全交给上层业务逻辑。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
两种 tryLock 用法的本质区别
无参 tryLock() 是纯瞬时检查，零等待，适合“能抢就抢，抢不到就走”的场景；带超时的 tryLock(long, TimeUnit) 则是在指定总耗时内多次尝试（含短暂 park），但仍是可控等待，不是无限阻塞。注意：超时值为 0 等价于无参版本；单位写错（如把秒写成毫秒）会导致实际等待时间偏差 1000 倍。
必须严格配对 unlock()，且仅在获取成功后调用
- 只有
tryLock()返回true时，才持有锁，此时unlock()才合法 -
unlock()必须放在finally块中，确保异常也不漏释放 - 绝不能在未获取锁的情况下调用
unlock()，否则抛IllegalMonitorStateException
典型适用场景与设计要点
- 快速失败：比如高并发下单时，锁不可用直接返回“库存不足”，而非排队等待
- 避免死锁：多个资源按固定顺序 tryLock，某一步失败就释放已持锁并回退
- 降级处理：抢锁失败时读缓存、返回默认值或转异步任务
- 注意公平性影响：即使构造为公平锁，
tryLock()仍会绕过队列直接 CAS 尝试，可能“插队”成功
常见误用与规避方式
- 不要把
lock.lock()直接替换成if (!tryLock()) return;——语义从“必须串行”变成“尽力而为”，可能破坏数据一致性 - 避免高频轮询：
while(!lock.tryLock()) Thread.yield();会浪费 CPU，应改用带超时版本或引入退避策略 - 锁粒度要合理：若
tryLock()频繁失败，说明临界区过大或持有锁时间过长，需优化业务逻辑
