今天来聊一聊ReentrantLock，这个玩意儿在面试里可是高频考点。咱们先说说为啥面试官总盯着它不放，不像synchronized那种一看就懂的，ReentrantLock里头门道多着呢。它能重入、能中断、管得公平还是不公平，这每一点都能把你好好考一考。 这东西到底强在哪？先说它的三个主要能耐：第一个是等待能中断，万一拿着锁的家伙老不放手，后面等着的线程直接撤退算了，别干等着。第二个是公平和非公平两种模式随便选，默认是非公平的速度快，但要是非要选公平的就得小心了，虽然排队守规矩了，但跑起来的速度可能就慢了点。第三个是一把锁能绑定好几个条件，直接调用newCondition()就行，不像synchronized那样还得在代码里套一层锁。 不过话说回来，这玩意儿也不是完美无缺。像synchronized那种写法简单不容易出错的优势还是挺明显的；再加上JVM底层的优化也厉害得很；还有JVM自己能记清楚谁拿着锁呢。这几点和ReentrantLock比起来还是有优势的。 咱们再从代码的角度看看里面是咋回事。ReentrantLock的底子是AQS（抽象队列同步器），里头有两个子类：FairSync和NonfairSync。FairSync就像排大队似的，大家按顺序来；NonfairSync就直接用CAS抢锁，谁抢到谁先得；这两个类都继承自Sync，而Sync其实就是个AQS的壳子。想搞明白排队、中断还有条件等待这些事啊，就得把AQS里的state、node、head、tail这些字段扒开了看看。 最后提醒大家一句：面试前把这三个功能点背熟；别人问性能差别时就把“公平锁会降低吞吐量”拿出来挡枪；要是让你写代码片段直接甩lock.newCondition()出来秀一把多条件绑定就行了。坚持多练练这些同步工具，offer自然就来了。