2012-04-26 10 views

Respuesta

4

sólo tienen las variables/referencias locales a los métodos. O asegúrate de que las variables de instancia sean inmutables.

+0

¿No serían aceptables las variables de instancia inmutables? – duffymo

+0

@duffymo edited – NimChimpsky

+0

nice - corto y al grano. –

4

Puede hacer que su código sea seguro para subprocesos haciendo que todos los datos sean inmutables, si no hay mutabilidad, todo es seguro para subprocesos.

En segundo lugar, es posible que desee echar un vistazo a API simultánea de Java que tiene la disposición para proporcionar bloqueos de lectura/escritura que funcionan mejor en caso de que haya muchos lectores y algunos escritores. La palabra clave pura sincronizada también bloqueará a dos lectores.

7

En realidad, muchas maneras:

  1. Sin necesidad de sincronización en absoluto si usted no tiene estado mutable.
  2. No hay necesidad de sincronización si el estado mutable está limitado a un único hilo. Esto se puede hacer utilizando variables locales o java.lang.ThreadLocal.
  3. También puede usar sincronizadores incorporados. java.util.concurrent.locks.ReentrantLock tiene la misma funcionalidad que el bloqueo al que accede cuando usa los bloques y métodos synchronized, y es aún más poderoso.
+1

Prefiero (2), pero no estoy seguro de si es posible implementar mensajes sin utilizar la palabra clave 'sincronizada'. ¿Puedo hacer una cola productor-consumidor sin 'sincronizar'? –

+1

No importa - Puedo, usando java.util.concurrent.Semaphore. –

+1

@MartinJames Cualquiera de las clases simultáneas como colas e intercambiadores se puede utilizar sin sincronización. (Usan Lock en su lugar) The Disrupter admite mensajería sin bloqueos o sincronización. (Tengo una biblioteca que hace esto también) –

-2

¿Por qué lo necesitas?

Usando sólo la variable local/referencias no van a resolver la mayor parte de las necesidades de negocio complejos. Además, si la variable de instancia es inmutable, sus referencias aún se pueden cambiar por otros hilos.

Una opción es utilizar algo así como un SingleThreadModel, pero está muy desaconsejado y desaconsejado.

u también puede mirar a api concurrente como se sugirió anteriormente por Kal

+0

"si la variable de instancia es inmutable, sus referencias aún se pueden cambiar" no, no pueden – NimChimpsky

+0

¿puede explicar eso? Como lo veo es que si tengo una variable de instancias String s = "xyz", My thread1 puede cambiar la referencia a s = "abc"; y thread2 ahora obtendrá s = "abc" – Kshitij

+0

s es una referencia, ha cambiado, no es inmutable, necesitaría "s final string" – NimChimpsky

1

Para mantener la previsibilidad debe garantizar ya sea todo el acceso a los datos mutables se realiza de forma secuencial o manejar los problemas causados ​​por el acceso paralelo.

La protección más gruesa usa la palabra clave synchronized. Más allá de eso, hay al menos dos niveles de posibilidad, cada uno con sus beneficios.

Cerraduras/Semáforos

Estos pueden ser muy eficaces. Por ejemplo, si tiene una estructura que muchos subprocesos leen, pero que solo se actualiza en uno, es posible que encuentre útil un ReadWriteLock.

cerraduras pueden ser mucho más eficiente si se elige la cerradura para que coincida con el algoritmo.

Atomics

El uso de AtomicReference por ejemplo, puede proporcionar a menudo bloquear por completo la funcionalidad gratuita. Esto generalmente puede proporcionar grandes beneficios.

El razonamiento detrás de atomics es permitirles fallar, pero decirles que fallaron de una manera que usted puede manejarlo.

Por ejemplo, si desea cambiar un valor, puede leerlo y luego escribir su nuevo valor siempre que siga siendo el valor anterior. Esto se llama "comparar y establecer" o cas y generalmente se puede implementar en hardware, por lo que es extremadamente eficiente. Todo lo que necesita es algo así como:

long old = atomic.get(); 
while (!atomic.cas(old, old+1)) { 
    // The value changed between my get and the cas. Get it again. 
    old = atomic.get(); 
} 

Tenga en cuenta, sin embargo, que la previsibilidad no siempre es un requisito.

Cuestiones relacionadas