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 (and "condition variables" that allow threads to wait for or send notifications to other threads that the condition is fulfilled), 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 Lock instance.)
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.
The Java Virtual Machine uses monitors to support multithreading. Monitors achieve this through two concepts - Mutual exclusion while running the threads (here is where 'locking' comes into picture) and coordination as a means of inter thread communication (here is where object's wait and notify methods come into picture).
Reading the following part from "Inside JVM" will clear this doubt, is it very nicely explained over here (Chapter 20, Thread synchronization) -
Even though it is late to answer this question, I thought to just add in-case it is useful.
Here is a synchronized block of Java code inside an unsynchronized Java method
public void add(int value){
synchronized(this){
this.count += value;
}
}
In the example "this" is used, which is the instance the add method is called on.
A synchronized instance method uses the object it belongs to as monitor object.
=> Only one thread can execute inside a Java code block synchronized on the same monitor object.
A thread in the Java virtual machine requests a lock when it arrives
at the beginning of a monitor region. In Java, there are two kinds of
monitor regions: synchronized statements and synchronized methods.
Monitor
A monitor is like a building that contains one special room that can
be occupied by only one thread at a time. The room usually contains
some data. From the time a thread enters this room to the time it
leaves, it has exclusive access to any data in the room. Entering the
monitor building is called "entering the monitor." Entering the
special room inside the building is called "acquiring the monitor."
Occupying the room is called "owning the monitor," and leaving the
room is called "releasing the monitor." Leaving the entire building is
called "exiting the monitor."
In addition to being associated with a bit of data, a monitor is
associated with one or more bits of code, which in this book will be
called monitor regions.
As mentioned earlier, the language provides two built-in ways to
identify monitor regions in your programs: synchronized statements and
synchronized methods. These two mechanisms, which implement the mutual
exclusion aspect of synchronization, are supported by the Java virtual
machine's instruction set.
Lock
To implement the mutual exclusion capability of monitors, the Java
virtual machine associates a lock (sometimes called a mutex) with each
object and class. A lock is like a privilege that only one thread can
"own" at any one time.
A single thread is allowed to lock the same object multiple times. For
each object, the Java virtual machine maintains a count of the number
of times the object has been locked. An unlocked object has a count of
zero. When a thread acquires the lock for the first time, the count is
again incremented to one. Each time the thread acquires a lock on the
same object, the count is again incremented.