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

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 */
   }

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

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.