What's the meaning for object's monitor in java? Why use this word?

up vote10down votefavorite 3

When reading articles about java thread, I often notice the expression: "current thread is the owner of this object's monitor.". I catch the meaning: the thread gets the right to operate on the object. But I am puzzled why use the phrase "the object's monitor" instend of "the object's lock"? In brief, I don't konw the meaning of word 'monitor' The question may be strange and simple. But wish anybody can help to solve it. 3ks java multithreading monitor share|improve this question edited Mar 24 '12 at 3:25 AHungerArtist 3,30042359 asked Mar 24 '12 at 2:23 jiafu 8601521

add comment

3 Answers

activeoldestvotes

up vote5down voteaccepted

but I am puzzled why use word "the object's monitor" instend of "the object's lock"? See ulmangt's answer for links that explain the term "monitor" as used in this context. Why use the term "monitor" rather than "lock"? Well strictly speaking, the terms do mean different things ... especially if you use them in the way that they were originally intended to be used. A "lock" is something with acquire and release primitives that maintain certain lock properties; e.g. exclusive use or single writer / multiple reader. A "monitor" is a mechanism that ensures that only one thread can be executing a given section (or sections) of code at any given time. This can be implemented using a lock, but it is more than just a lock. Indeed, in the Java case, the actual lock used by a monitor is not directly accessible. (You just can't say "Object.lock()" to prevent other threads from acquiring it ... like you can with a Java Lockinstance.) In short, if one were to be pedantic "monitor" is actually a better term than "lock" for characterizing what Java is providing. But in practice, both terms are used almost interchangeably. share|improve this answer answered Mar 24 '12 at 3:02 Stephen C 222k10147391

1   very datailed.many thanks to you. –  jiafu Mar 24 '12 at 3:31 I have another question. Every object has self's lock info in housekeerp field in heap data. what's its use for?–  jiafu Mar 24 '12 at 3:33 @jiafu - It is necessary because that's the way the the Java language is specified. But in practice, the overhead is typically LESS THAN 1 WORD ... unless the object's lock is actually used. –  Stephen C Mar 24 '12 at 4:17 "housekeeping" information, such as recording an object's class, ID and status flags such as whether the object is currently reachable, currently synchronization-locked etc. –  jiafu Mar 24 '12 at 6:06 @jiafu - nitpick there is no "is currently reachable" flag. The flag you are thinking of is the "mark" bit used by the GC. It does not explicitly mean that the object is reachable. Rather it means that the GC hasencountered the object. It is only valid during garbage collection, and even then it only may mean that the GC has decided that the object may be reachable. (Things get rather complicated with advanced GC algorithms.)–  Stephen C Apr 18 at 11:01  add comment

up vote6down vote	A monitor is simply a term for an object whose methods can be safely used in a multithreaded environment. There's a great Wikipedia article on Monitors: http://en.wikipedia.org/wiki/Monitor_(synchronization) If you scroll down, it's even got a section explicitly about Java. share|improve this answer answered Mar 24 '12 at 2:35 ulmangt 2,804619
	add comment

Java uses object as monitor, isn't that object too heavy weight?

up vote1down votefavorite 1

I read this in Java language Spec 17.1: "Each object in Java is associated with a monitor, which a thread can lock or unlock." Why necessarily? Doesn't that make java object too heavy weight? I've no idea why a Object like, say, a string, should be naturally a monitor! EDIT: I think it over and yes, Java has a keyword synchronized, because EVERY object could have a synchronized method, so it's necessary to associate EVERY object a Monitor. But still this seems not a very good solution, usually you need more that one mutex for one class, except for that pojo classes that's really very simple. java multithreading share|improve this question edited Sep 20 '10 at 3:09 asked Sep 20 '10 at 2:58 tactoth 247114

2   Just because every object is associated with a monitor in the language spec doesn't mean that the monitor exists until it is used. I would expect that most runtimes would not create a monitor for an object until it is the subject of a synchronized block/method. –  Gabe Sep 20 '10 at 3:18 but how? when a class is loaded search through all its methods to see if it use synchronized(this)? – tactoth Sep 20 '10 at 3:24 add comment

5 Answers

activeoldestvotes

up vote2down voteaccepted

Your fundamental problem is in assuming that every object has some sort of Monitor built into it, waiting for it to be used by some code. In reality, most objects are never used as a monitor, so the monitors don't have to be created until they are used. Rather than implementing this feature as every object having a private Monitor monitor field, think of it as being implemented as the JVM having a global HashMap. A possible implementation is this: Whenever a synchronized block is entered, the JVM looks up the synchronized object in the map (monitors). If it finds it, it gets the monitor to use. If it doesn't find it, it enters a critical section dedicated to the map. It then looks up the object again because another thread may have created it between the previous check and entering the critical section. If it's still not there, it creates the monitor for the synchronized object and leaves the critical section. share|improve this answer answered Sep 20 '10 at 4:03 Gabe 45.6k449105