I don't see how recursion would help, but I'll take your word on the no
deadlock bit.

Do you mean "able to be used in recursive algorithms" maybe?  I think
that might be re-entrant or something.

The concurrency model of Java is specified very loosely.  There are
certain pairs of operations that may occur in which it may be inferred
that one operation happened before the other.  For example, if two
operations happen in the same thread, then it may be inferred that there
is an order to the operations (the same order in which they appear in
the code).  Also, if threads get and release a monitor via synchronized
blocks, then this allows you to validly conclude that one thread
released the synchronized block before the other thread got it.  There
are a few more.  These pairs of operations are listed in the language
specification.  Outside of these pairs of operations, though, the
implementation is free to act as if operations happened in any order
whatsoever, regardless of what the order actually is.  The result is
that if threads never do certain things, then the implementation may act
as if one thread hasn't yet done the stuff that it's done, from the
perspective of the other thread.

So that's the formal reason.  However, there is another question.  Why
is it specified that way?  It's specified that way to give flexibility
to the implementation.  Implementations have to deal with complexity
that you couldn't dream of sometimes.  Many CPUs will feel free to
change the order in which they execute various instructions of your
code, unless they are explicitly told not to... and telling them not to
may result in severe performance costs due to pipeline stalls.  The JVM
might even be running on a distributed network, where it's very
expensive to go check if some other thread has modified an object, and
you'd rather put it off until you absolutely need to do so.  Not to
mention that future technologies will have even greater challenges.  I
actually see it as quite likely that future multiprocessing CPU
architectures will be more like distributed applications, in which it's
more expensive to access memory that's "close" to the CPU than memory
that's far away.  That leads to more scalable designs, if you can figure
out the compilation challenges of managing how to put things closer to
their respective CPUs in memory.  The JVM concurrency model is written
as loosely as possible to let you write correct code by applying
synchronization primitives, but otherwise give the implementation as
much flexibility as possible in handling these kinds of issues.

So that's why.  If you don't understand, though, the rule of thumb is
still pretty simple.  Don't assume that you'll see changes made in a
different thread unless you enter a synchronized block for a montior
that was held by the other thread when the changes were made.  Don't
assume that other threads can see your changes unless you enter a
synchronized block when you make them (and the other threads grab the
same monitor before reading).

Atomicity is a different question.  The JVM does guarantee that all
attempts to read an int will return an actual value, and not some half-
way in between thing.  However, say that thread 1 writes to an int
variable, and then thread 2 reads that same variable.  Thread two will
get *either* the value before thread 1 wrote to it, *or* the value
after, but there's no way to tell which unless there's some synchronized
block (or some other way to prove a sequence that's acceptable in the
JLS concurrency model) involved.

Yes, it will.  Things are more complicated than you are assuming,
because there is no global order for operations in the program.  Things
can happen in different orders depending on the observer.  Almost like
special relativity...

[This is in addition to what Chris Smith has already explained]

Consider this:

   privant int value;

   public int getValue() { return value; }

   public void aMethod()
   {
       while (true)
           doSomethingWith(getValue());
   }

Since getValue() is not synchronised, and uses no sychronisation blocks, the
compiler (which really means JITer) is perfectly within its right to first
inline the method call, as if the original Java source was:

   public void aMethod()
   {
       while (true)
           doSomethingWith(value);
   }

and then to "notice" that value does not change during the loop, and to
optimise the field access into a local variable access:

   public void aMethod()
   {
       int __xyz123 = value;
       while (true)
           doSomethingWith(__xyz123);
   }

So, in another thread /does/ change value, the loop will never "see" the new
value.

Synchronisation acts not only to control the (potentially very loose) coupling
between the state of RAM seen by different CPUs, but also to inform the
optimiser of the limits to what it is allowed to assume.

   -- chris