Digamos que tengo el siguiente campo dentro de una clase:
ConcurrentHashMap<SomeClass, Set<SomeOtherClass>> myMap = new ConcurrentHashMap<SomeClass, Set<SomeOtherClass>>();Una instancia de esta clase se comparte entre muchos subprocesos.
Si quiero agregar o eliminar un elemento de un conjunto asociado con una clave, podría hacer:
Set<SomeOtherClass> setVal = myMap.get(someKeyValue); setVal.add(new SomeOtherClass()); La operación get es atómica, por lo tanto segura para subprocesos. Sin embargo, no hay garantía de que, entre las instrucciones get y add , algún otro subproceso no modifique la estructura interfiriendo con la ejecución del primero.
¿Cuál sería la mejor manera de hacer atómica toda la operación?
Esto es lo que se me ocurrió, pero no creo que sea muy eficiente (o que haga el mejor uso de las estructuras de Java):
Tengo un campo ReentrantLock, por lo que mi clase se ve así:
class A { ReentrantLock lock = new ReentrantLock(); ConcurrentHashMap<SomeClass, Set<SomeOtherClass>> myMap = new ConcurrentHashMap<SomeClass, Set<SomeOtherClass>>(); }Entonces la llamada al método se parece a esto:
lock.lock(); Set<SomeOtherClass> setVal = myMap.get(someKeyValue); synchronized(setVal) { lock.unlock(); setVal.add(new SomeOtherClass()); } La idea es que soltemos el bloqueo una vez que nos hayamos asegurado de que nadie más accederá al conjunto que estamos tratando de modificar. Sin embargo, no creo que esto esté haciendo el mejor uso de ConcurrentMap o que tenga mucho sentido tener un bloqueo, una estructura concurrente y un bloque synchronized para lograr una operación.
¿Hay una mejor manera de hacer esto?
ConcurrentHashMap garantiza que toda la invocación del método de compute (o computeIfAbsent o computeIfPresent ) se realiza atómicamente. Entonces, por ejemplo, podrías hacer algo como esto:
myMap.compute(someKeyValue, (k, v) -> {v.add(new SomeOtherClass()); return v;}); Nota:
El uso de compute es similar al fragmento original que supone que somKeyValue está presente en el mapa. Sin embargo, usar computeIfPresent es probablemente más seguro.