java线程中的“Monitor”

Question

I have read different things in different blogs about monitors. So I'm a bit confused now.

As much as I understand, monitor is a somebody who would make sure that only one thread is executing the code in the critical section. So is it like if we have 3 synchronized methods/blocks then we would have 3 monitors to make sure that only one thread is in the critical section?

If the above is true then why it is said that in Java every object has a monitor associated with it? It should be every synchronized block is associated with a monitor.

Answer 1

What is a monitor?

A monitor is something a thread can grab and hold, preventing all other threads from grabbing that same monitor and forcing them to wait until the monitor is released. This is what a synchronized block does.

Where do these monitors come from in the first place?

The answer is: from any Java object. When you write:

Object foo = new Object();
synchronized (foo) {
  System.out.println("Hello world.");
}

...what this means is: the current thread will first grab the monitor associated with the object stored in variable foo and hold it while it prints "Hello world", then releases it.

Why does every Java object have a monitor associated with it?

There is no technical reason for it to be that way. It was a design decision made in the early versions of Java and it's too late to change now (even though it is confusing at first and it does cause problems if people aren't careful).

Answer 2

When using synchronized with blocks, you specify an object to lock on. In that case, the monitor of that object is used for locking.

When using synchronized with methods, you don't specify an object to lock on, and instead this object is implied. Again, the monitor of this is used for locking.

So, objects have monitors, and synchronized methods/blocks do not have their own monitors, but instead they use the monitors of specific objects.

Answer 3

In the context of Java programming, the monitor is the intrinsic lock (where intrinsic means "built-in") on a Java object. For a thread to enter any synchronized instance method on an object it must first acquire the intrinsic lock on that object. For a thread to enter any synchronized static method on a class it must first acquire the intrinsic lock on that class.

This is how monitor is defined in the Java tutorial :

Synchronization is built around an internal entity known as the intrinsic lock or monitor lock. (The API specification often refers to this entity simply as a "monitor.")

So "monitor" in Java is a synonym for "intrinsic lock".

There is a good reason that the monitor belongs to an object, and not to an individual block: the monitor is there to protect the state of the object. Objects should be designed to be cohesive , making it likely that instance variables will end up being referenced by multiple methods; the safe thing to do, in order to guarantee that the object is always in a consistent state, is to allow only one synchronized method on that object to execute at a time.

The term "monitor" comes from Concurrent Pascal , although the meaning of it seems significantly different. See Per Brinch Hansen's paper "Java's Insecure Parallelism" , which argues that Java doesn't actually implement monitors:

Gosling (1996, p. 399) claims that Java uses monitors to synchronize threads. Unfortunately, a closer inspection reveals that Java does not support a monitor concept:

• Unless they are declared as synchronized, Java class methods are unsynchronized.

• Unless they are declared as private, Java class variables are public (within a package)

Another quote from the same paper:

The failure to give an adequate meaning to thread interaction is a very deep flaw of Java that vitiates the conceptual integrity of the monitor concept.

I try to avoid the term "monitor", preferring "intrinsic lock" as more exact. But "monitor" appears in the JLS and can't be avoided.