“类Object（及其子类）的每个实例都拥有一个锁，该锁在进入synchronized方法时获得，并在退出时自动释放”
这是否意味着我们创建的任何对象实例在内部默认都有一个“锁”（作为字段实现）？
我对这个“锁”概念感到困惑，我想知道它在内部实际上做了什么。
谁能指导我到一些可以找到更多信息的地方？
问问题
11641 次
3 回答
24
与往常一样，JLS 提供了答案 (17.1)：
这些方法中最基本的是同步，它是使用监视器实现的。Java 中的每个对象都与一个监视器相关联，线程可以锁定或解锁监视器。一次只有一个线程可以锁定监视器。任何其他试图锁定该监视器的线程都会被阻塞，直到它们能够获得对该监视器的锁定。一个线程 t 可能会多次锁定一个特定的监视器；每次解锁都会反转一次锁定操作的效果。
所以，不，lock不像是一个字段Object（正如您通过简单地查看Object 的源代码所看到的那样）。相反，每个Object都与一个“监视器”相关联，并且正是这个监视器被锁定或解锁。
我只是想指出一个进一步的参考资料，其中详细说明了“Java 是如何做到的”，以确保它不会被忽视。这位于@selig 在下面发现的 C++ 代码的注释中，我鼓励所有对下面内容的支持来回答他的问题。您可以在此处提供的链接中查看完整的源代码。
126 // -----------------------------------------------------------------------------
127 // Theory of operations -- Monitors lists, thread residency, etc:
128 //
129 // * A thread acquires ownership of a monitor by successfully
130 // CAS()ing the _owner field from null to non-null.
131 //
132 // * Invariant: A thread appears on at most one monitor list --
133 // cxq, EntryList or WaitSet -- at any one time.
134 //
135 // * Contending threads "push" themselves onto the cxq with CAS
136 // and then spin/park.
137 //
138 // * After a contending thread eventually acquires the lock it must
139 // dequeue itself from either the EntryList or the cxq.
140 //
141 // * The exiting thread identifies and unparks an "heir presumptive"
142 // tentative successor thread on the EntryList. Critically, the
143 // exiting thread doesn't unlink the successor thread from the EntryList.
144 // After having been unparked, the wakee will recontend for ownership of
145 // the monitor. The successor (wakee) will either acquire the lock or
146 // re-park itself.
147 //
148 // Succession is provided for by a policy of competitive handoff.
149 // The exiting thread does _not_ grant or pass ownership to the
150 // successor thread. (This is also referred to as "handoff" succession").
151 // Instead the exiting thread releases ownership and possibly wakes
152 // a successor, so the successor can (re)compete for ownership of the lock.
153 // If the EntryList is empty but the cxq is populated the exiting
154 // thread will drain the cxq into the EntryList. It does so by
155 // by detaching the cxq (installing null with CAS) and folding
156 // the threads from the cxq into the EntryList. The EntryList is
157 // doubly linked, while the cxq is singly linked because of the
158 // CAS-based "push" used to enqueue recently arrived threads (RATs).
159 //
160 // * Concurrency invariants:
161 //
162 // -- only the monitor owner may access or mutate the EntryList.
163 // The mutex property of the monitor itself protects the EntryList
164 // from concurrent interference.
165 // -- Only the monitor owner may detach the cxq.
166 //
167 // * The monitor entry list operations avoid locks, but strictly speaking
168 // they're not lock-free. Enter is lock-free, exit is not.
169 // See http://j2se.east/~dice/PERSIST/040825-LockFreeQueues.html
170 //
171 // * The cxq can have multiple concurrent "pushers" but only one concurrent
172 // detaching thread. This mechanism is immune from the ABA corruption.
173 // More precisely, the CAS-based "push" onto cxq is ABA-oblivious.
174 //
175 // * Taken together, the cxq and the EntryList constitute or form a
176 // single logical queue of threads stalled trying to acquire the lock.
177 // We use two distinct lists to improve the odds of a constant-time
178 // dequeue operation after acquisition (in the ::enter() epilog) and
179 // to reduce heat on the list ends. (c.f. Michael Scott's "2Q" algorithm).
180 // A key desideratum is to minimize queue & monitor metadata manipulation
181 // that occurs while holding the monitor lock -- that is, we want to
182 // minimize monitor lock holds times. Note that even a small amount of
183 // fixed spinning will greatly reduce the # of enqueue-dequeue operations
184 // on EntryList|cxq. That is, spinning relieves contention on the "inner"
185 // locks and monitor metadata.
186 //
187 // Cxq points to the the set of Recently Arrived Threads attempting entry.
188 // Because we push threads onto _cxq with CAS, the RATs must take the form of
189 // a singly-linked LIFO. We drain _cxq into EntryList at unlock-time when
190 // the unlocking thread notices that EntryList is null but _cxq is != null.
191 //
192 // The EntryList is ordered by the prevailing queue discipline and
193 // can be organized in any convenient fashion, such as a doubly-linked list or
194 // a circular doubly-linked list. Critically, we want insert and delete operations
195 // to operate in constant-time. If we need a priority queue then something akin
196 // to Solaris' sleepq would work nicely. Viz.,
197 // http://agg.eng/ws/on10_nightly/source/usr/src/uts/common/os/sleepq.c.
198 // Queue discipline is enforced at ::exit() time, when the unlocking thread
199 // drains the cxq into the EntryList, and orders or reorders the threads on the
200 // EntryList accordingly.
201 //
202 // Barring "lock barging", this mechanism provides fair cyclic ordering,
203 // somewhat similar to an elevator-scan.
204 //
205 // * The monitor synchronization subsystem avoids the use of native
206 // synchronization primitives except for the narrow platform-specific
207 // park-unpark abstraction. See the comments in os_solaris.cpp regarding
208 // the semantics of park-unpark. Put another way, this monitor implementation
209 // depends only on atomic operations and park-unpark. The monitor subsystem
210 // manages all RUNNING->BLOCKED and BLOCKED->READY transitions while the
211 // underlying OS manages the READY<->RUN transitions.
212 //
213 // * Waiting threads reside on the WaitSet list -- wait() puts
214 // the caller onto the WaitSet.
215 //
216 // * notify() or notifyAll() simply transfers threads from the WaitSet to
217 // either the EntryList or cxq. Subsequent exit() operations will
218 // unpark the notifyee. Unparking a notifee in notify() is inefficient -
219 // it's likely the notifyee would simply impale itself on the lock held
220 // by the notifier.
221 //
222 // * An interesting alternative is to encode cxq as (List,LockByte) where
223 // the LockByte is 0 iff the monitor is owned. _owner is simply an auxiliary
224 // variable, like _recursions, in the scheme. The threads or Events that form
225 // the list would have to be aligned in 256-byte addresses. A thread would
226 // try to acquire the lock or enqueue itself with CAS, but exiting threads
227 // could use a 1-0 protocol and simply STB to set the LockByte to 0.
228 // Note that is is *not* word-tearing, but it does presume that full-word
229 // CAS operations are coherent with intermix with STB operations. That's true
230 // on most common processors.
231 //
232 // * See also http://blogs.sun.com/dave
233
234
235 // -----------------------------------------------------------------------------
于 2013-06-28T15:47:05.517 回答
22
另一个答案描述了语言定义所说的，而不是“内部发生的”。
Java 中的每个对象都有一个两个单词的对象头。标记词和类指针。第一个字（标记字）用于存储锁定信息和缓存哈希码。第二个字是指向存储该对象的静态信息（包括方法代码）的 klass 对象的指针。
HotSpot JVM 有一些花哨的锁定东西，包括瘦锁和偏向锁定，这基本上意味着如果你从不锁定一个对象，或者如果你从来没有任何争用，那么你将永远不会创建一个监视器对象（这是存储额外锁定信息的东西）。
监视器对象有一个条目集。如果对象已被锁定，则当您锁定该对象时，您的线程将被添加到条目集中。当您解锁对象时，您会唤醒条目集中的一个线程。
并发是一个非常复杂的领域，显然还有很多细节。
更新
于 2013-06-28T16:42:55.330 回答
-3
Lock是Java并发的内部概念。您可以通过同步或外部锁获得它。要了解更多信息，请参阅：http ://docs.oracle.com/javase/tutorial/essential/concurrency/newlocks.html
于 2013-06-28T15:48:39.943 回答