"Каждый экземпляр класса Object (и его подклассы) имеет блокировку, которая получается при входе в синхронизированный метод и автоматически освобождается при выходе "
Означает ли это, что любой экземпляр объекта, который мы создаем внутренне, имеет "блокировку" по умолчанию (реализован как поле)?
Я запутался в этой концепции "блокировки", я хочу знать, что на самом деле делает внутренне.
Может ли кто-нибудь направить меня к кому-нибудь, где найти дополнительную информацию?
Как всегда, JLS предоставляет ответ (17.1):
Самым основным из этих методов является синхронизация, которая реализуется с использованием мониторов. Каждый объект в Java связан с монитором, который поток может блокировать или разблокировать. Только один поток за раз может удерживать блокировку на мониторе. Любые другие потоки, пытающиеся заблокировать этот монитор, блокируются, пока они не смогут получить блокировку на этом мониторе. Нить t может блокировать определенный монитор несколько раз; каждая разблокировка отменяет действие одной операции блокировки.
Итак, no, lock не похоже на поле в Object (как вы можете видеть, просто глядя на Исходный код объекта). Скорее, каждый Object связан с "монитором", и именно этот монитор заблокирован или разблокирован.
Я просто хотел указать дополнительную ссылку, в которой подробно описывается "как Java", чтобы убедиться, что она не упускается из виду. Это расположено в комментариях кода С++, который @selig обнаружил ниже, и я призываю все upvotes для контента ниже подойти к его ответу. Вы можете просмотреть полный исходный код в предоставленной там ссылке.
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 "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 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 true
230 // on most common processors.
231 //
232 // * See also http://blogs.sun.com/dave
233
234
235 // -----------------------------------------------------------------------------
Другой ответ описывает то, что говорит определение языка, но не то, что "происходит внутренне".
Каждый объект в Java имеет заголовок с двумя словами. Слово метки и указатель класса. Первое слово (слово метки) используется для хранения информации о блокировке и кэширования хэш-кода. Второе слово - это указатель на объект класса, хранящий статическую информацию (включая код метода) для этого объекта.
В JSM HotSpot есть несколько причудливых запирающих элементов, включая тонкие блокировки и смещенную блокировку, что в основном означает, что если вы никогда не блокируете объект или если у вас никогда не было споров, вы никогда не создадите объект монитора (это то, что хранит дополнительную информацию о блокировке).
Объект монитора имеет набор записей. Когда вы блокируете этот объект, если объект уже заблокирован, ваш поток добавляется к набору записей. Когда вы разблокируете объект, вы пробуждаете поток в наборе записей.
Concurrency - очень сложное поле, и, очевидно, гораздо больше деталей.
UPDATE
Обозначается заголовок объекта здесь и сведения о том, что происходит с монитором объекта, т.е. наборы ожидания можно найти в этот код openjdk.
Lock - внутренняя концепция Java Concurrency. Вы можете получить его через синхронизацию или блокировку Externatl. Чтобы узнать больше, смотрите: http://docs.oracle.com/javase/tutorial/essential/concurrency/newlocks.html