Java: ¿Sincronización en primitivas?

Question

En nuestro sistema, tenemos un método que va a hacer un trabajo cuando se llama con un cierto ID:

public void doWork(long id) { /* ... */ } 

Ahora, este trabajo se puede hacer al mismo tiempo para diferentes identificadores, pero si el método se llama con el mismo ID por 2 hilos, un hilo debe bloquearse hasta que se termine.

La solución más simple sería tener un mapa que se correlacione desde la ID larga con algún objeto arbitrario que podamos bloquear. Un problema que preveo con esto es que podemos tener toneladas de identificaciones en el sistema y este mapa seguirá creciendo todos los días.

Idealmente, creo que necesitamos un sistema en el que cada hilo busque un objeto de bloqueo, bloquee cuando sea posible, haga el trabajo y luego indique que hemos terminado con el bloqueo. Si está claro que nadie más está utilizando este bloqueo en particular, retírelo con seguridad del mapa de bloqueo para evitar la pérdida de memoria.

Imagino que este debe ser un escenario bastante común, así que espero que exista una solución existente. Alguien sabe de alguno?

Answer 1

Inventé una cosa así para mí hace algún tiempo. Lo llamo bloqueo de clase de equivalencia, es decir, se bloquea en todas las cosas que son iguales a lo dado. Puede obtenerlo from my github, y usarlo sujeto a la licencia de Apache 2, si lo desea, ¡o simplemente leerlo y olvidarlo!

Answer 2

¿No sería suficiente utilizar un SynchronizedHashMap o Collections.synchronizedMap (Map m) del paquete java.util.concurrent en lugar de un HashMap simple donde las llamadas para recuperar e insertar no están sincronizadas?

algo como:

Map<Long,Object> myMap = new HashMap<Long,Object>(); 
Map<Long,Object> mySyncedMap=Collections.synchronizedMap(myMap); 

Answer 3

yo diría que ya se encuentra bastante lejos de tener una solución. Haga un LockManager que de forma perezosa y de referencia-cuenta-administra esos bloqueos para usted. Luego usarlo en doWork:

public void doWork(long id) { 
    LockObject lock = lockManager.GetMonitor(id); 
    try { 
     synchronized(lock) { 
      // ... 
     } 
    } finally { 
     lock.Release(); 
    } 
} 

Answer 4

optimización prematura es la raíz del mal

Prueba con un mapa (sincronizado).

Tal vez si crece demasiado grande, puede borrar su contenido a intervalos regulares.

Answer 5

Sugiero que utilice las utilidades de java.util.concurrent, especialmente la clase AtomicLong. Ver related javadoc

Answer 6

Para empezar:

1. No puede bloquear en una primitiva y
2. no se bloquean en un largo a menos que esté cuidado de cómo se les construye. Se garantiza que los valores largos creados por autoboxing o Long.valueOf() en un cierto rango sean los mismos en toda la JVM, lo que significa que otros hilos podrían estar bloqueados en el mismo objeto Largo exacto y dándole una diafonía. Esto puede ser un error de concurrencia sutil (similar al bloqueo en cadenas internados).

Estamos hablando de una configuración de bloqueo de trama. Un extremo del continuo es un único bloqueo gigante para todos los identificadores, que será fácil y seguro pero no simultáneo. El otro extremo es un candado por identificación que es fácil (hasta cierto punto) y seguro y muy concurrente, pero puede requerir una gran cantidad de "objetos bloqueables" en la memoria (si aún no los tiene). En algún lugar en el medio está la idea de crear un bloqueo para una serie de identificadores: esto le permite ajustar la concurrencia en función de su entorno y tomar decisiones acerca de las compensaciones entre la memoria y la concurrencia.

ConcurrentHashMap se puede utilizar para lograr esto, ya que CHM se compone internamente de segmentos (submapas) y hay un bloqueo por segmento. Esto le da concurrencia igual al número de segmentos (que por defecto es 16 pero es configurable).

Hay un montón de otras soluciones posibles para particionar su espacio de ID y crear conjuntos de bloqueos, pero tiene razón al ser sensible a los problemas de limpieza y pérdida de memoria; cuidar de eso mientras se mantiene la concurrencia es complicado. Tendrá que utilizar algún tipo de referencia contando cada candado y gestionar el desalojo de los candados viejos con cuidado para evitar el desalojo de un candado que está en proceso de ser bloqueado. Si utiliza esta ruta, use ReentrantLock o ReentrantReadWriteLock (y no sincronizado en objetos) ya que le permite administrar explícitamente el bloqueo como un objeto y utilizar los métodos adicionales disponibles en él.

También hay algunas cosas sobre esto y un ejemplo de StripedMap en Java Concurrency in Practice sección 11.4.3.

Answer 7

Puede intentar lo siguiente poco 'truco'

String str = UNIQUE_METHOD_PREFIX + Long.toString(id); 
synchornized(str.intern()) { .. } 

que es 100% garantizado para devolver la misma instancia.

El UNIQUE_METHOD_PREFIX, puede ser una constante codificada, o pueden obtenerse usando:

StackTraceElement ste = Thread.currentThread().getStackTrace()[0]; 
String uniquePrefix = ste.getDeclaringClass() + ":" +ste.getMethodName(); 

que garantizará que el bloqueo ocurre sólo en este método precisa. Eso es para evitar interbloqueos.

Answer 8

Se puede crear una lista o un conjunto de identificadores de activos y el uso de esperar y notificar:

List<Long> working; 
public void doWork(long id) { 
synchronized(working) 
{ 
    while(working.contains(id)) 
    { 
     working.wait(); 
    } 
    working.add(id)//lock 
} 
//do something 
synchronized(working) 
{ 
    working.remove(id);//unlock 
    working.notifyAll(); 
} 
} 

Problemas resueltos:

• Solamente los hilos con la misma ID de esperar, todos los demás son concurrentes
• Sin memoria Se filtrarán los "bloqueos" (Largo) al desbloquear
• Funciona con autoboxing

problemas allí:

• mientras/notifyAll puede causar pérdida de rendimiento con alto número de hilos
• No réentrant

Answer 9

Aquí es donde me gustaría utilizar un mapa canonicalizing, que tiene su long ingrese y devuelve un objeto canónico Long que luego puede usar para sincronizar. He escrito sobre mapas de canonización here; simplemente reemplace String por Long (y para hacer su vida más fácil, deje que tome un long como parámetro).

Una vez que tenga el mapa canonicalizing, que iba a escribir el código de bloqueo vigilado así:

Long lockObject = canonMap.get(id); 
synchronized (lockObject) 
{ 
    // stuff 
} 

El mapa canonicalizing se aseguraría de que el mismo lockObject es devuelto por el mismo ID. Cuando no hay referencias activas al lockObject, serán elegibles para la recolección de basura, por lo que no se llenará la memoria de objetos innecesarios.

Answer 10

Puede intentar algo con un ReentrantLock, de modo que tenga un Map<Long,Lock>. Ahora después de lock.release() Puede probar lock.hasQueuedThreads(). Si eso devuelve falso, puedes eliminarlo del mapa.