Implementation of "canonical" lock objects

I have a store of data objects and I wish to synchronize modifications that are related to one particular object at a time.

class DataStore {
    Map<ID, DataObject> objects = // ...
    // other indices and stuff...

    public final void doSomethingToObject(ID id) { /* ...  */ }
    public final void doSomethingElseToObject(ID id) { /* ... */ }
}

That is to say, I do not wish my data store to have a single lock since modifications to different data objects are completely orthogonal. Instead, I want to be able to take a lock that pertains to a single data object only.

Each data object has a unique id. One way is to create a map of ID => Lock and synchronize upon the one lock object associated with the id. Another way is to do something like:

synchronize(dataObject.getId().toString().intern()) {
    // ...
}

However, this seems like a memory leak -- the internalized strings may never be collected.

Yet another idea is to synchronize upon the data object itself; however, what if you have an operation where the data objec开发者_如何转开发t doesn't exist yet? For example, what will a method like addDataObject(DataObject) synchronize upon?

In summary, how can I write a function f(s), where s is a String, such that f(s)==f(t) if s.equals(t) in a memory-safe manner?

Add the lock directly to this DataObject, you could define it like this:

public class DataObject {
  private Lock lock = new ReentrantLock();

  public void lock() { this.lock.lock(); }
  public void unlock() { this.lock.unlock(); } 
  public void doWithAction( DataObjectAction action ) {
    this.lock();
    try {
      action.doWithLock( this ) :
    } finally {
      this.unlock();
    }
  }

  // other methods here

}

public interface DataObjectAction { void doWithLock( DataObject object ); }

And when using it, you could simply do it like this:

DataObject object = // something here
object.doWithAction( new DataObjectAction() {

  public void doWithLock( DataObject object ) {
    object.setProperty( "Setting the value inside a locked object" );
  }

} );

And there you have a single object locked for changes.

You could even make this a read-write lock if you also have read operations happening while writting.

For such case, I normally have 2 level of lock: First level as a reader-writer-lock, which make sure update to the map (add/delete) is properly synchronized by treating them as "write", and access to entries in map is considered as "read" on the map. Once accessed to the value, then synchronize on the value. Here is a little example:

class DataStore {
    Map<ID, DataObject> objMap = // ...
    ReadWritLock objMapLock = new ReentrantReadWriteLock();
    // other indices and stuff...
    public void addDataObject(DataObject obj) {
        objMapLock.writeLock().lock();
        try {
            // do what u need, u may synchronize on obj too, depends on situation
            objMap.put(obj.getId(), obj);
        } finally {
            objMapLock.writeLock().unlock();
        }
    }

    public final void doSomethingToObject(ID id) { 
        objMapLock.readLock().lock();
        try {
            DataObject dataObj = this.objMap.get(id);
            synchronized(dataObj) {
                // do what u need
            }
        } finally {
            objMapLock.readLock().unlock();
        }

    }
}

Everything should then be properly synchronized without sacrificing much concurrency

Yet another idea is to synchronize upon the data object itself; however, what if you have an operation where the data object doesn't exist yet? For example, what will a method like addDataObject(DataObject) synchronize upon?

Synchronizing on the object is probably viable.

If the object doesn't exist yet, then nothing else can see it. Provided that you can arrange that the object is fully initialized by its constructor, and that it is not published by the constructor before the constructor returns, then you don't need to synchronize it. Another approach is to partially initialize in the constructor, and then use synchronized methods to do the rest of the construction and the publication.