简体   繁体   中英

Java Object as a monitor clarification

I used following resources to get to a summary of Java monitors,

http://www.informit.com/store/concurrent-programming-in-java-design-principles-and-9780201310092

http://www.artima.com/insidejvm/ed2/threadsynch.html

And following is the summary from my understanding in the context of Java ,

Monitor is an object that is awarded about Threads. That >means when saying in Java that all objects are monitors >that means each object has the trait of thread awareness.

Thread is an active object . And other objects are passive >but are aware about threads .Hence monitors! In other >words passive objects have been smartened.

Why call "monitor" , because it monitors itself ! From what ? >From active objects ie Threads

What awareness a monitor has?

a)It knows what thread currently access it.{owner}

b)It knows what threads are waiting on it till a special condition > is met.{wait set}

c)It knows who are in the queue to enter to it{entry set}

So how could a thread become an objects owner , it has to >acquire that object's lock !


1 Object IS a lock or HAS a lock ?

2 Above a,b,c are part of the state of an object or keep tracked by the JVM ( keep a record and associate it to the Object ID etc.)?

Each object in Java has a monitor associated with it. A monitor is a construct that is essentially equivalent to a reentrant lock; the same thread can enter a monitor multiple times, and the number of entries is counted and matched against the exits.

Your conclusions about "active" and "passive" objects don't make much sense. (I'm not saying they're wrong ; I'm saying I can't understand what you're trying to say.)

The semantics of monitors in the JVM is well-defined, but the implementation is not, and there are a number of ways that the monitor could be implemented. All of the items in your a/b/c are kept track of by the JVM in some way that the JVM author decides. Since most objects' monitors are never used, one strategy would be to have a table of monitors, separate from the heap, that contained a struct with the object's JVM ID, the thread currently inside the monitor, and the entry count.

  1. In Java parlance, people tend to say that each object has a monitor. The statement synchronized( anObject ) means acquire anObject's monitor .

  2. An object doesn't "know" about the threads that currently access it. At a point in time, an object might be active in multiple threads.

    From the language point of view , there is no way to list the threads that currently use an object (a), nor to list the threads that wait on it (b and c).

    From the JVM point of view , the JVM must internally be able to do b and c, but not really a.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM