2010-10-18 15 views
8

¿Cuál es el uso típico de ThreadLocal en Java? ¿Cuándo lo usa uno? No pude detalles de la solicitud de este artículo java docs.Usos de ThreadLocal

+2

posible duplicado de [¿Cuándo y cómo debo usar una variable ThreadLocal?] (Http://stackoverflow.com/questions/817856/when-and-how-should-i-use-a-threadlocal- variable) – YoK

Respuesta

4

Es para cuando desea utilizar objetos que no son seguros para subprocesos, pero no desea sincronizar el acceso a ellos (por motivos de rendimiento). Más o menos, crea un acceso para el objeto que necesita usar varias veces, de modo que se asegura de que cada subproceso que pueda llamar a ese acceso obtenga uno diferente, sin usar. Un uso muy típico es para usar SimpleDateFormat, que es una clase que si fuera segura para subprocesos, su instancia se declararía como estática, con el fin de reutilizar la misma instancia.

He aquí un buen artículo que describe que: Dr. Dobbs: Using Thread-Local Variables In Java

4

ejemplo quizá más ilustrativo puede ser bueno para usted:

method1(): ... method2(somedata) ... 
method2(somedata): ... method3(somedata) ... 
method3(somedata): ... method4(somedata) ... 
method4(somedata): ... do something with somedata ... 

Tales situaciones se producen, por ejemplo, en las arquitecturas de múltiples capas (IU llama a la fachada remoto, remoto fachada llama a capa de aplicación, capas de aplicación capa de dominio, capa de dominio persistencia capa, ...) Si esos métodos() pertenecen a diferentes clases no hay una buena manera de pasar tales datos excepto agregar el parámetro extra 'algunos datos' para la mayoría de los métodos en nuestra código, esto rompe, por ejemplo, el principio abierto-cerrado. La solución a este problema es ThreadLocal:

method1(): ... threadLocal.set(somedata); method2(); threadLocal.set(null); ... 
method2(): ... method3() ... 
method3(): ... method4() ... 
method4(): ... do something with threadLocal.get() ... 
5

yo diría que el uso más típico ThreadLocal es cuando se tiene algún objeto que tiene que ser accesible por todas partes durante un flujo y no desea pasar referencia a la presente objeto sobre todas las capas. Algo así como el patrón singleton pero por hilo.

Los ejemplos son conexión de base de datos, sesión de hibernación, etc. Se abren en algún lugar al comienzo de su flujo, se comprometen/cierran al final del flujo y se usan en todas partes durante el flujo.

0

Si su flujo está vinculado a un hilo, como se menciona en AlexR, puede crear un public final class C con una propiedad private static final ThreadLocal<T> p, agregar métodos de acceso. Luego puede usar p.set(), p.remove() y p.get() respectivamente a lo largo de su flujo.

public final class C { 
    private static final ThreadLocal<String> p = new ThreadLocal<String>(); 

    // initialize property at the begining of your thread (flow) 
    public static void set(final String s){ 
     p.set(s); 
    } 

    // use property during the thread's lifecycle 
    // for instance: C.get().equals(myString) 
    public static String get(){ 
     return p.get(); 
    } 

    // remember to remove property from the thread when you're done, specially if it came from a thread pool 
    public static void remove(){ 
     p.remove(); 
    } 
}