synchronized : Java Glossary

synchronized
A crucial method that must not be executed by two threads simultaneously. Note the American spelling, synchronized, that all Java terms use. A crucial block of code you don’t want two threads accessing simultaneously can be designed to allow only one thread through at a time, using:
synchronized ( someObject )
   {
   /* crucial code */
   }
You always need to specify some common Object upon which the locks for all the threads can wait. However, the attribute synchronized is not applied to the variable, but to the method or code block that accesses the Object. Further understand you cannot lock on a primitive variable such as an int, only an Object (or some subclass).

Only one thread at a time can own the lock for any given Object. Thus if more than one thread tries to enter a section of code for which the lock must be acquired then only one thread will get the lock and all other threads will block. Note however that a thread can still execute a non-synchronized method or block of code even if the Object is locked.

But that is not quite accurate either. According to David Holmes, a synchronized instance method locks the Object to which the method belongs, on entry to the method and unlocks it on exit (well, if it already owns the lock — methods are reentrant — it actually increases and decreases the lock count respectively). The lock keeps all synchronized methods out of the Object, not just other calls to that particular method. A statement:

synchronized( someObject )
   {
   /* crucial code */
   }
locks the Object someObject on entry to the statement and unlocks it on exit (or increases/decreases the count if its already owned). A synchronized instance method e.g.
synchronized doit()
   {
   /* crucial code */
   }
is
doit()
   {
   synchronized( this )
      {
      /* crucial code */
      }
   }

To protect access to static variables you must lock the class Object — which is what a synchronized static method does. Alternatively in any method you can obtain a lock on the class Object explicitly using

synchronized ( getClass() )
   {
   /* crucial code */
   }

When multiple threads are waiting to acquire the lock on an Object the order in which the lock is assigned to a waiting thread is not defined.

One simple application would be queue with multiple threads adding work to be done to it, and multiple threads removing packets of work to do from it. So long as you synchronised the get and put methods, all threads can share the same queue safely.

In many applications is safe to have many reader threads simultaneously accessing a data structure, but only one writer thread. If there is a writer thread active, then all other reader and writer threads must be blocked. Arranging this is somewhat trickier that locking the entire datastructure for every read/write.

You call the wait method, you must have a lock on the synchronising object. To use notify, you don’t. Almost never should you be fooling around with low level synchronisation tools like synchronized, volatile, wait and notify. They are extremely tricky to use correctly. Instead use the higher level tools in java.util.concurrent.

Learning More

Oracle’s Javadoc on java.util.concurrent package : available:
Oracle’s Javadoc on java.util.Queue class : available:
Oracle’s Javadoc on notify package : available:
Oracle’s Javadoc on wait package : available:

CMP homejump to top You can get the freshest copy of this page from: or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
http://mindprod.com/jgloss/synchronized.html J:\mindprod\jgloss\synchronized.html
logofeedback Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : feedback email If you want your message kept confidential, not considered for posting, please explicitly specify that.
mindprod.com IP:[65.110.21.43]
view BlogYour face IP:[38.107.179.214]
You are visitor number 225,526.