Unsafe: removing the monitorEnter/monitorExit/tryMonitorEnter methods

David Holmes david.holmes at oracle.com
Tue Mar 4 03:51:52 UTC 2014

On 3/03/2014 10:57 PM, David M. Lloyd wrote:
> On 02/27/2014 06:38 AM, David Holmes wrote:
>> On 27/02/2014 9:12 PM, Stephen Colebourne wrote:
>>> On 26 February 2014 20:54, Martin Buchholz <martinrb at google.com> wrote:
>>>> It does seem that being able to tell whether a java object monitor is
>>>> currently locked is useful for debugging and monitoring - there
>>>> should be a
>>>> way to do that.
>>> Perhaps it would be useful to be able to expose a java object monitor
>>> as an instance of Lock?
>>> Lock lk = Lock.ofMonitor(object)
>>> if (lk.tryLock()) {
>>>    ...
>>> }
>>> Such a method feels like it would be a useful missing link between
>>> synchronized and locks.
>> I don't think this is workable. Exposing a monitor as Lock would allow
>> you to break the guarantees/requirements involving balanced-locking for
>> monitors.
> The JNI APIs also allow this, do they not?



"Native code must not use MonitorExit to exit a monitor entered through 
a synchronized method or a monitorenter Java virtual machine instruction."

The above isn't enforced as with most JNI usage rules.



More information about the core-libs-dev mailing list