Here are a couple:
- Only update the user interface from one thread
- Use synchronization features as little as possible
- Try to avoid calling functions that might be modified from synchronized
blocks (calling api functions that are welldefined and do not have any
synchronized blocks are ok)

Niels Dybdahl

Not really. You have to know what you are doing. You have to understand
threads, and you have to know what is going on in your source code (the
different flows of control and their interdependencies, critical
sections of code, access patterns to data, etc.).

Rules of thumb don't work very well with threading. Such rules basically
mean "usually it works out if you do XYZ". However, something "usually
working out" is not good enough when it comes to multi threading. The
cases when it suddenly doesn't work out on that particular machine of
that important customers in the middle of the night or at that important
demo are the ones that hurt and are the ones which are extremely
difficult to debug. The 1 out of 1000 failure which is almost impossible
to reproduce in the lab.

/Thomas

Know what you're doing.
Prove that your program cannot deadlock. (Note that a simple solution to
this is to ensure that a thread can only take out one lock at a time)

Alun Harford

Read some theory of concurrent programming. You can find the same in
any general purpose OS book.

Use the Sun concurrent classes rather that doing synchronsation logic
with primitives. See http://mindprod.com/jgloss/queue.html

the main one is always acquire resources in the same order.

First off, it is important that you know what you application is doing
with respect to threads. Adding a few synchronized keywords randomly may
stop the odd problem, but it is not a viable solution.

Don't synchronise at all.

The easy, yet high performance solution. A number of approaches: Require
that everything is run in one thread (thread hostile, like Swing).
Require that the client take care of synchronisation/single threading
(thread agnostic). Make your objects immutable (technically you require
1.5 and need to declare fields final).

Keep synchronised blocks as small as possible.

Generally copy out what you need, then let go of the lock. Avoid calling
all but the most well understood functions from within the block. In
particular do not call callback methods while holding a lock.

Synchronise in a particular order

If you must nest synchronisations, make sure acquire the locks in a
particular order. This may be on the basis of type or another property
of the objects.

There are some tricky situations. For instance binary operators.

Consider StringBuffer.append(StringBuffer). It would probably be a bug
on the part of the client code in this case, but you can deadlock with
StringBuffers attempting to append to each other. a.append(b) in one
thread, and b.append(a) in another.

A general approach is to use a global lock. Synchronize to a static
around all binary operations, then synchronize onto operands in whatever
order. Obviously this can cause hideous problems in code that makes
extensive use of threads. To be avoided for server applications.

    private static class Lock { } // Make thread dumps more readable.
    private static final Object GLOBAL_LOCK = new Lock();
    public StringBuffer append(StringBuffer text) {
        if (text == null) return appendNull();
        synchronized (GLOBAL_LOCK) {
            synchronized (this) {
                 synchronized (text) {
                      super.append(text);
                 }
            }
        }
        return this;
    }

Another approach for StringBuffer.append is to copy out the contents.
This is the copy-out advice from above. So:

    public StringBuffer append(StringBuffer text) {
        // toString is done under lock.
        String str = text==null ? NULL_STRING : text.toString();
        synchronized (this) {
            super.append(str);
        }
        return this;
    }

A third approach is to attempt to order the locking. 99.999% of the time
Object.hashCode (i.e. System.identityHashCode) will give different
values for a pair of Objects. In the unlikely event of a tie, we can use
a fallback technique.

    public StringBuffer append(StringBuffer text) {
        if (text == null) return appendNull();
        int thisHash = this.hashCode();
        int textHash = text.hashCode();
        final StringBuffer firstLock;
        final StringBuffer secondLock;
        if (thisHash < textHash) {
            firstLock = this;
            secondLock = text;
        } else if (thisHash > textHash) {
            secondLock = this;
            firstLock = text;
        } else {
            assert thisHash == textHash;
            // Damn - cop out.
            return append(text.toString());
        }
        synchronized (firstLock) {
            synchronized (secondLock) {
                super.append(text);
            }
        }
        return this;
    }

Tom Hawtin