Question

The JDK provides a set of thread-safe classes like ConcurrentHashMap, ConcurrentLinkedQueue and AtomicInteger.

Are these classes required to synchronize on this to implement their thread-safe behavior?

Provided that they do we can implement our own synchronized operations on these objects and mix them with the built-in ones?

In other words is it safe to do:

ConcurrentMap<Integer, Account> accounts 
    = new ConcurrentHashMap<Integer, Account>();

// Add an account atomically
synchronized(accounts) {
    if (!accounts.containsKey(id)) {
        Account account = new Account();
        accounts.put(id, account);
    }
}

And in another thread

// Access the object expecting it to synchronize(this){…} internally
accounts.get(id);

Note that the simple synchronized block above could probably be replaced by putIfAbsent() but I can see other cases where synchronizing on the object could be useful.

Answer 1

Are these classes required to
synchronize on this to implement their
thread-safe behavior.

No and, not only that, the various code inspection tools will warn you if you do try to use the object lock.

In the case of the put method above, note the javadoc:

A hash table supporting full
concurrency of retrievals and
adjustable expected concurrency for
updates. This class obeys the same
functional specification as Hashtable,
and includes versions of methods
corresponding to each method of
Hashtable. However, even though all
operations are thread-safe, retrieval
operations do not entail locking, and
there is not any support for locking
the entire table in a way that
prevents all access. This class is
fully interoperable with Hashtable in
programs that rely on its thread
safety but not on its synchronization
details.

This means that the options are thread safe and there isn’t a way to do what you’re trying to do above (lock the whole table). Furthermore, for the operations that you use (put and get), neither of them will require such locking.

I particularly like this quote from the javadoc from the values() method:

The view’s iterator is a “weakly
consistent” iterator that will never
throw ConcurrentModificationException,
and guarantees to traverse elements as
they existed upon construction of the
iterator, and may (but is not
guaranteed to) reflect any
modifications subsequent to
construction.

So, if you use this method, you’ll get a reasonable list: it will have the data as of the request time and might or might not have any later updates. The assurance that you won’t have to worry about the ConcurrentModificationExceptions is a huge one: you can write simple code without the synchronized block that you show above and know that things will just work.