Question

Let’s say I have a HashMap declared as follows:

@GuardedBy("pendingRequests")
private final Map<UInt32, PendingRequest> pendingRequests = new HashMap<UInt32, PendingRequest>();

Access to the map is multi-threaded, and all access is guarded by synchronizing on this final instance of the map, e.g.:

synchronized (pendingRequests) {
    pendingRequests.put(reqId, request);
}

Is this enough? Should the map be created using Collections.synchronizedMap()? Should I be locking on a dedicated lock object instead of the map instance? Or maybe both?

External synchronization (in addition to possibly using Collections.synchronizedMap()) is needed in a couple areas where multiple calls on the map must be atomic.

Answer 1

Synchronizing on the map itself is essentially what the Map returned by Collection.synchronizedMap() would do. For your situation it is a reasonable approach, and there is not much to recommend using a separate lock object other than personal preference (or if you wish to have more fine grained control and use a ReentrantReadWriteLock to allow concurrent reading of the map).

E.g.

private Map<Integer,Object> myMap;
private ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

public void myReadMethod()
{
  rwl.readLock().lock();
  try
  {

    myMap.get(...);
    ...
  } finally
  {
    rwl.readLock().unlock();
  }
}

public void myWriteMethod()
{
  // may want / need to call rwl.readLock().unlock() here,
  // since if you are holding the readLock here already then
  // you cannot get the writeLock (so be careful on how your
  // methods lock/unlock and call each other).
  rwl.writeLock().lock();
  try
  {
    myMap.put(key1,item1);
    myMap.put(key2,item2);
  } finally
  {
    rwl.writeLock().unlock();
  }
}