Skip to content

Commit ad63424

Browse files
authored
Merge pull request #2892 from sharpener-YuFeng/patch-2
锁-StampedLock知识补充
2 parents 0b8f4de + d02e76c commit ad63424

1 file changed

Lines changed: 5 additions & 1 deletion

File tree

docs/java/concurrent/java-concurrent-questions-02.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1022,7 +1022,11 @@ long tryConvertToReadLock(long stamp){}
10221022
long tryConvertToOptimisticRead(long stamp){}
10231023
```
10241024

1025-
`StampedLock` 在获取锁的时候会返回一个 long 型的数据戳,该数据戳用于稍后的锁释放参数,如果返回的数据戳为 0 则表示锁获取失败。当前线程持有了锁再次获取锁还是会返回一个新的数据戳,这也是 `StampedLock` 不可重入的原因。
1025+
`StampedLock` 在获取锁的时候会返回一个 long 型的数据戳,该数据戳用于稍后的锁释放参数,如果返回的数据戳为 0 则表示锁获取失败。当前线程持有了锁再次获取锁时返回情况要看当前持有什么锁、再次申请什么锁,以及使用的是阻塞方法还是`try`方法:
1026+
- **当前线程持有写锁,再次获取写锁**:由于写锁是独占锁,第二次获取必须等待,但第一个写锁又要等待第二次调用返回后才能释放,于是当前线程把自己锁住了。结果就是一直阻塞,无法返回。
1027+
- **使用`tryWriteLock()`时,会返回0**:tryWriteLock()不会一直等待,它会立即尝试。当获取成功,则返回非0的stamp;获取失败,则返回0。
1028+
- **同一线程再次获取悲观读锁,会返回新的数据戳**:读锁是共享锁,读锁与读锁之间不冲突,所以正常返回数据戳。
1029+
真正的“可重入锁”会识别线程身份,虽然StampedLock这里同一个线程可以获取2次读锁,返回2个stamp,但StampedLock不记录锁的线程所有权。判断是否可重入,重点看独占写锁。StampedLock的写锁无法由同一个线程再次获取,所以它是不可重入的。
10261030

10271031
```java
10281032
// 写锁

0 commit comments

Comments
 (0)