Best ways to write a method that updates two objects in a multithreaded java environment?

Suppose we have a class called AccountService that 开发者_开发百科manages the state of accounts.

AccountService is defined as

interface AccountService{
 public void debit(account);
 public void credit(account);
 public void transfer(Account account, Account account1);

}

Given this definition, what is the best way to implement transfer() so that you can guarantee that transfer is an atomic operation.

I'm interested in answers that reference Java 1.4 code as well as answers that might use resources from java.util.concurrent in Java 5

Synchronize on both Account objects and do the transfer. Make sure you always synchronize in the same order. In order to do so, make the Accounts implement Comparable, sort the two accounts, and synchronize in that order.

If you don't order the accounts, you run the possibility of deadlock if one thread transfers from A to B and another transfers from B to A.

This exact example is discussed on page 207 of Java Concurrency in Practice, a critical book for anybody doing multi-threaded Java development. The example code is available from the publisher's website:

• Dynamic lock-ordering deadlock. (bad)
• Inducing a lock ordering to avoid deadlock.

A classic example very well explained here - http://www.javaworld.com/javaworld/jw-10-2001/jw-1012-deadlock.html?page=4

You probably need to have a full transactions support (if it's a real application of course).

The difficulty of solution hardly depends on your environment. Describe your system in detail and we'll try to help you (what kind of application? does it use web-server? which web-server? what is used to store data? and so on)

If you can guarantee that all accesses are made through the transfer method, then probably the easiest approach is just to make transfer a synchronized method. This will be thread-safe because this guarantees that only one thread will be running the transfer method at any one time.

If other methods may also access the AccountService, then you might decide to have them all use a single global lock. An easy way of doing this is to surround all code that accesses the AccountService in a synchronized (X) {...} block where X is some shared / singleton object instance (that could be the AccountService instance itself). This will be thread safe because only one thread will be accessing the AccountService at any one time, even if they are in different methods.

If that still isn't sufficient, then you'll need to use more sophisticated locking approaches. One common approach would be to lock the accounts individually before you modify them... but then you must be very careful to take the locks in a consistent order (e.g. by account ID) otherwise you will run into deadlocks.

Finally if AccountService is a remote service then you are into distributed locking territory.... unless you have a PhD in computer science and years of research budget to burn you should probably avoid going there.

Couldn't you avoid having to synchronize using an AtomicReference<Double> for the account balance, along with get() and set()?