java - 关于HotSpot中thin-locks实现中锁记录的使用

Question

在 HotSpot 上处理“thin-locks”时，我无法理解锁记录的生命周期是什么。

我的理解是:

When a thread T first attempts to acquire alock on object o, it triggers a "thin lock" creation -- a lock record is created on T's stack, on the current frame F, and a copy ofthe mark work (that will now be referred as a displaced header) plus a referenceto o is stored on F. Through a CAS operation o's header is madeto reference the lock record (and the last two bits are set to 00to mark this object as thin-locked!).

There are multiple reasons why the CAS operation could fail, though:

• Another thread was quicker to grab the lock, we'll need to turn this thin-lock into a full-blown monitor instead;
• The CAS failed but it can be seen that the reference to the lock record belongs to Ts stack, so we must be attempting to re-enterthe same lock, which is fine. In that case, the lock record of thecurrent stack-frame is kept null.

鉴于此，我有几个问题:

1. 为什么我们每次尝试进入锁时都会创建一个新的锁记录？为每个对象保留一个锁定记录不是更好吗？o？
2. 当离开同步块(synchronized block)时，我无法理解 VM 如何知道我们是否应该释放锁或者我们是否仍在从递归锁中“展开”。

任何人都可以阐明这一点吗？

引用资料

• https://blogs.oracle.com/dave/lets-say-youre-interested-in-using-hotspot-as-a-vehicle-for-synchronization-research
• https://wiki.openjdk.java.net/display/HotSpot/Synchronization
• http://www.diva-portal.org/smash/get/diva2:754541/FULLTEXT01.pdf
• https://www.oracle.com/technetwork/java/biasedlocking-oopsla2006-wp-149958.pdf

让我引用上一个链接中的一段话:

Whenever an object is lightweight locked by a monitorenter bytecode, alock record is either implicitly or explicitly allocated on the stackof the thread performing the lock acquisition operation. The lockrecord holds the original value of the object’s mark word and alsocontains metadata necessary to identify which object is locked. Duringlock acquisition, the mark word is copied into the lock record (such acopy is called a displaced mark word), and an atomic compare-and-swap(CAS) operation is performed to attempt to make the object’s mark wordpoint to the lock record. If the CAS succeeds, the current thread ownsthe lock. If it fails, because some other thread acquired the lock, aslow path is taken in which the lock is inflated, during whichoperation an OS mutex and condition variable are associated with theobject. During the inflation process, the object’s mark word isupdated with a CAS to point to a data structure containing pointers tothe mutex and condition variable. During an unlock operation, anattempt is made to CAS the mark word, which should still point to thelock record, with the displaced mark word stored in the lock record.If the CAS succeeds, there was no contention for the monitor andlightweight locking remains in effect. If it fails, the lock wascontended while it was held and a slow path is taken to properlyrelease the lock and notify other threads waiting to acquire the lock.Recursive locking is handled in a straightforward fashion. If duringlightweight lock acquisition it is determined that the current threadalready owns the lock by virtue of the object’s mark word pointinginto its stack, a zero is stored into the on-stack lock record ratherthan the current value of the object’s mark word. If zero is seen in alock record during an unlock operation, the object is known to berecursively locked by the current thread and no update of the object’smark word occurs. The number of such lock records implicitly recordsthe monitor recursion count. This is a significant property to thebest of our knowledge not attained by most other JVMs.

谢谢

Answer 1

Why would we create a new lock record each time we attempt to enter a lock? Wouldn't it be preferable to just keep a single lock record for each object o?

看来您错过了锁定记录的要点。锁定记录不是一些每个对象 实体，而是每个锁定站点。例如，如果一个方法有 3 个 synchronized block ，那么它的栈帧最多可能有 3 个锁定记录，无论是 3 个不同的锁定对象，还是同一个对象被递归锁定 3 次。

锁记录(实际上，它们在 HotSpot 源代码中并没有这样称呼；它们通常被称为“monitor”、“monitor slot”、“monitors block”等)有助于维护堆栈帧之间的映射及其锁定的显示器。特别是，当一个栈帧因为异常被移除时，所有的锁都需要自动释放。因此，可以将监视器槽视为类似于局部变量槽的东西，它可以保存对相同或不同对象的引用。与局部变量一样，监视器与给定的堆栈帧相关联。它们持有对锁定对象的引用，但它们本身并不是“锁”。

When leaving a synchronized block, I failed to understand how can the VM know whether we should release the lock or whether we're still "unwinding" from a recursive lock.

一个锁记录(一个监视器槽)包含两个东西:一个对锁定对象的引用和一个所谓的“置换头”。置换 header 是对象 header 的先前(未锁定)值，如果它是递归锁，则为零。

我上面解释过，如果我们对一个对象加锁3次，就会有3条加锁记录。只有第一个包含实际的非零位移 header ，其他两个将具有零。这意味着，前两条 monitorexit 指令将用零弹出锁定记录，意识到这是一个递归锁定，因此不会更新对象。当最后一个锁定记录被删除时，JVM 会在移位的 header 中看到一个非零值，并将其存储回真实的对象 header 中，从而将其标记为已解锁。