Java中用ReentrantLock.tryLock()实现非阻塞轮询锁，核心是通过立即返回的tryLock()配合手动sleep或指数退避策略实现“忙等+退避”，避免线程挂起；需显式unlock、限制重试次数、控制等待间隔，并适用于短时持锁场景。
Java 中用 ReentrantLock.tryLock() 实现非阻塞轮询锁，核心是避免线程挂起，通过反复尝试获取锁并配合短时等待，达成“忙等 + 退避”的效果。关键不是无脑循环，而是控制重试频率、避免 CPU 空转、兼顾响应性与资源消耗。
理解 tryLock 的两种常用重载形式
tryLock() 本身不阻塞，立即返回 true（成功）或 false（失败）；tryLock(long timeout, TimeUnit unit) 则最多等待指定时间，期间可被中断。轮询场景下，通常组合使用前者 + 手动 sleep 或退避策略，而非依赖后者做长等待——因为后者本质仍是阻塞式等待，不符合“非阻塞轮询”本意。
基础轮询模式：固定间隔重试
适用于对延迟敏感、且锁持有时间较短的场景。需注意 sleep 时间不宜过短（如 1ms），否则易造成 CPU 毛刺；也不宜过长（如 100ms），否则响应变慢。
- 定义最大重试次数和每次重试前的休眠毫秒数（例如最多试 10 次，每次间隔 5ms）
- 在循环中调用
lock.tryLock()，成功则跳出循环执行业务逻辑 - 失败则
Thread.sleep(delay)，捕获InterruptedException并恢复中断状态 - 循环结束仍未获取到锁，可选择放弃、抛异常或降级处理
优化轮询：指数退避（Exponential Backoff）
当并发冲突频繁时，固定间隔容易导致大量线程同时重试，加剧竞争。指数退避让每次等待时间递增（如 1ms → 2ms → 4ms → 8ms…），降低碰撞概率，更友好。
立即学习“Java免费学习笔记（深入）”；
- 初始化基础延迟（如 1ms），每次失败后乘以系数（通常为 2）
- 设置最大延迟上限（如 16ms），防止单次等待过长
- 每次重试前生成一个微小随机偏移（如 ±10%），进一步打散重试时间点
- 仍需限制总重试次数，避免无限等待
实际使用注意事项
ReentrantLock 需显式释放，轮询中一旦获取成功，必须确保最终 unlock；建议用 try-finally 包裹业务逻辑。另外，tryLock 不遵循公平策略（除非构造时传入 true），高并发下可能产生饥饿，若业务强依赖公平性，需权衡是否适合轮询方式。
- 永远在
tryLock()返回true后才进入临界区，并在 finally 块中 unlock - 不要在持有锁期间调用可能阻塞的方法（如 I/O、wait），否则会拖慢整个轮询节奏
- 轮询锁更适合读多写少、锁粒度细、持有时间极短的场景；长时间持锁应优先考虑其他并发模型
