Synchronize on objects held in non-final variables?

Question

[This thread|http://forums.sun.com/thread.jspa?messageID=10775877#10775877] and post got me thinking:
linuxisbest.eric wrote:
I have noticed in my textbook that it creates a String in two ways:
String a = new String("Hello");and
String a = "Hello";Which one should I use? Is there any practical difference?
YoungWinston wrote:Pick door number two linux ... unless you plan on synchronizing on it, that is.
WinstonIs it best practice to only synchronize on objects held in final variables?
Edited by: Encephalopathic on Jul 26, 2009 5:46 AM

Answer 1

gnat wrote:
Is it best practice to only synchronize on objects held in final variables?
Above [best practices|http://en.wikipedia.org/wiki/Best_practices] apply to cases when lock is not intended to change.
I think that there could be cases when lock is actually intended to change and therefore shouldn't be final. Here's an example of caching code I've seen recently:
private final ConcurrentMap<Integer, Object> pendings
= new ConcurrentHashMap<Integer, Object>();
public Object loadEntity(int entityId) {
Object lock = new Object(); // shouldn't be final, see below
Object prev = pendings.putIfAbsent(entityId, lock);
if(prev != null) {
// without using prev lock, there would be a chance
//  for concurrent threads to perform redundant invocation
//  of retrieveEntityFromSomewhereSlowly for same entityId
lock = prev;
Object res;
synchronized (lock) {
res = getEntityFromCacheQuickly(entityId);
if (res == null) {
// cache miss - retrieve entity slowly:
res = retrieveEntityFromSomewhereSlowly(entityId);
pendings.remove(entityId);
gnat,
Huh? Please could you try to talk me through that code... At first glance, I don't follow it... I think it's still got "unprotected race conditions", but after reading it through several times (in the course of trying to frame a post saying basically "I don't think that will work, and here's why" I now think I understand how it does work (almost all the time), but I'd just really really like some validation of my mis/understanding.
So... Here's how I think that works... please could you verify or repudiate my understanding.
package forums;
import java.util.Random;
import java.util.Map;
import java.util.HashMap;
import java.util.concurrent.ConcurrentMap;
import java.util.concurrent.ConcurrentHashMap;
class GnatsThreadsafeCache
  private static final Random random = new Random();
  // pending locks := entityId --> lock
  private final ConcurrentMap<Integer, Object> pendingLocks = new ConcurrentHashMap<Integer, Object>();
  // cache := entityId --> entity
  //          1        --> "1"
  private final Map<Integer, Object> cache = new HashMap<Integer, Object>();
  public Object loadEntity(int entityId) {
    Object lock = new Object(); // shouldn't be final, see below
    // putIfAbsent: If the specified key is not already associated with a value,
    //  associate it with the given value. Returns the previous value associated
    //  with the specified key, or null if there was no mapping for the key.
    Object previousLock = pendingLocks.putIfAbsent(entityId, lock);
    if(previousLock != null) {
      // without using previousLock lock, there would be a chance
      //  for concurrent threads to perform redundant invocation
      //  of retrieveEntityFromSomewhereSlowly for same entityId
      lock = previousLock;
    Object entity;
    synchronized (lock) {
      entity = getEntityFromCacheQuickly(entityId);
      if (entity == null) {
        // cache miss - retrieve entity slowly:
        entity = retrieveEntityFromSomewhereSlowly(entityId);
        addEntityToCache(entityId, entity);
    pendingLocks.remove(entityId);
    return entity;
  private Object getEntityFromCacheQuickly(int entityId) {
    DEBUG("> getEntityFromCacheQuickly("+entityId+")");
    Object entity = cache.get(entityId);
    DEBUG("< getEntityFromCacheQuickly returns "+entity);
    return entity;
  private Object retrieveEntityFromSomewhereSlowly(int entityId) {
    DEBUG("> retrieveEntityFromSomewhereSlowly("+entityId+")");
    try{Thread.sleep(random.nextInt(1000));}catch(InterruptedException e){System.err.println(e);}
    Object entity = Integer.toString(entityId);
    DEBUG("< retrieveEntityFromSomewhereSlowly returns "+entity);
    return entity;
  private void addEntityToCache(int entityId, Object entity) {
    DEBUG("| addEntityToCache("+entityId+", "+entity+")");
    cache.put(entityId, entity);
  public static void main(String[] args)
    final GnatsThreadsafeCache cache = new GnatsThreadsafeCache();
    for (int i=0; i<10; i++) {
      new Thread(
        new Runnable() {
          @Override
          public void run() {
            int i = random.nextInt(4);
            Object entity = cache.loadEntity(i);
            DEBUG("~ "+i+"-->"+entity);
      , "Thread"+i).start();
  private static void DEBUG(String message) {
    System.err.println(Thread.currentThread().getName()+": "+message);
}How it works:
1. create a new lock object.
2. check if entityId exists in the previousLock list... that's a ConcurrentMap so the putIfAbsent operation is atomic (i.e. syncronised on the previousLock object).
    ~  This operation is "garanteed fast"; ergo it involves no heavy "business object" creation/retrieval.
3. Now, if the entityId already exists in the previousLock list we syncronize on it, allowing one-thread-at-a-time to traverse "the crytical block" where we check if the-entity associated with the-given-entityId is allready cached, and retrieve it, otherwise create a new one (which will take an arbitrary "long time").
So what? Well I think it means that we've reduced contention to the individual entity level, as apposed to the "collection level"; as you would get if you just used a "standard" ConcurrentMap as the cache... which means that we've (probably) increased the throughput because each thread is blocked only upon those other threads which definately would stuff-them-up (waiting for the heavy "business object" creation routine to complete); as apposed to those that just might stuff them up (but won't because they're actually retrieving different entities).
In short: It's a way of blocking on distinct keys?
Is that correct?
Thanx in advance for your thoughts.
Cheers. Keith.
Edited by: corlettk on 1/08/2009 11:05 ~~ Removed extranious cache.get from retrieveEntityFromSomewhereSlowly.