ThreadLocal, además de almacenamiento local con el intercambio de variables, ThreadLocal para asegurar que no se produzcan las condiciones de competencia. No entiendo ???
TODO: ThreadLocal como un montón de artículos, tiene que mirar a lo que es el uso, lo que es el principio, y cuál es la relación JVM
ThreadLocal variables con el fin de poder tener su propio en el hilo actual, no resuelve el problema y no puede resolver los problemas de sincronización, para compartir recursos
ThreadLocal entender
TODO: Acabado los siguientes párrafos (citado de diferentes lugares, la expresión puede ser muy confuso)
En circunstancias normales, estamos creando una variable puede ser cualquier un hilo para acceder y modificar. El uso de variables ThreadLocal sólo puede ser creada por el acceso hilo actual, otros hilos no se puede acceder y modificar.
objeto ThreadLocal contiene el mismo, hay diferentes copias en diferente Thread (en realidad diferentes instancias). Por ejemplo: para los ThreadLocal<String>fines que es diferente diferentes tipos de retención de cuerda de rosca de las variables.
ThreadLocal proporciona instancias de hilo local. Se diferencia de las variables comunes que cada hilo utilizará la variable de inicialización de una instancia completamente separada de copias. las variables ThreadLocal suelen ser private staticmodificados (política). Al final de un hilo, todas las instancias de ThreadLocal relativa de copia que utiliza puede ser reciclado.
ThreadLocal proporcionar un hilo de variable local, cada hilo puede ser operado por el conjunto variable local () y get (), pero no será conflictos y variables locales otros hilos para lograr hilo aislamiento de datos. Eso es rellenar las variables ThreadLocal pertenecen a la hebra actual, otros hilos en la variable se aísla.
- ThreadLocal Ejemplos de adecuados cada uno requiere su propio hilo y la instancia a utilizar en múltiples métodos , es decir, espaciador variable entre hilos y compartidos entre método escenas o una clase de
- Por ejemplo Rosca cada copia de la copia sólo puede ser utilizado por el subproceso actual, hilo otra inaccesible.
- ThreadLocal no resuelve multi-hilo compartidos variables del problema , no resuelve el problema de la sincronización
- Dado que ningún intercambio de información, no hay ningún problema natural de la competencia, asegurando de este modo la pérdida de rendimiento en algunos casos, el hilo de seguridad, y evitar algunos de los casos a considerar la seguridad de rosca deben estar sincronizados para llevar
- ⭐️⭐️⭐️⭐️ menudo se
private staticmodificado ( estrategia ), que todos estos objetos (el tiempo que se define en este hilo) pueden manipular el cambio de cara.- estática es seguro de rosca, por lo que diferentes instancias de la misma clase es una clase diferentes hilos de diferentes instancias
- Con un hilo SIMILARES a diferentes instancias de la clase comparten la misma instancia
- En el montón en lugar de la pila ( TODO: cómo entender )
principio ThreadLocal
TODO: ThreadLocalMap, la comprensión InheritableThreadLocal, y acabado de los siguientes cinco puntos
- Pase cada uno mantiene una referencia al ThreadLocalMap
- ThreadLocalMap es de clase interna ThreadLocal, la entrada para el almacenamiento
- Al llamar al método set ThreadLocal (), el valor se establece realmente a ThreadLocalMap, llave ThreadLocal es un objeto, el objeto se pasa en el valor de
- Cuando se llama al método get ThreadLocal (), de hecho, para obtener el valor ThreadLocalMap, objetos clave es ThreadLocal
- ThreadLocal sí no se almacena el valor, es sólo como una clave para permitir que el hilo se pone valor a partir de ThreadLocalMap.
(No aplicación JDK) (pensando) instancia hilo mapeo de mantenimiento ThreadLocal
Dado que cada hilo tiene su propio acceso a la variable ThreadLocal de una copia instancia "local". Una posible solución es mantener un mapa ThreadLocal, es el hilo clave, su valor en la instancia de hilo. Obtener el hilo a través del esquema de ThreadLocal () para obtener ejemplo, sólo es necesario para introducir un hilo, se puede encontrar la instancia correspondiente del mapa. El esquema se muestra a continuación:
El programa puede cumplir con los requisitos mencionados anteriormente cada hilo una copia de seguridad independiente. Cada nuevo hilo para acceder a la ThreadLocal, es necesario agregar un mapa a un mapa, y al final de cada hilo, debe borrar el mapa. Aquí hay dos problemas:
- Aumentar el hilo e hilo requerido para escribir Mapa descenso, por lo que la necesidad de garantizar que el mapa compatibles con el proceso, por lo tanto, más o menos cerraduras necesidad de garantizar la seguridad de la rosca
- Al final de la rosca, la necesidad de garantizar que todas las visitas de TI ThreadLocal se eliminan los mapas correspondientes, que pueden causar una pérdida de memoria.
(⭐️⭐️⭐️ la implementación JDK ) Tema instancia y mantener el mapeo ThreadLocal
En la solución anterior, aparecerá el icono de problemas de bloqueo debido a múltiples subprocesos tienen acceso a la misma mapa. Si el mapa mantenida por hilo, de manera que cada hilo para acceder sólo a su propio mapa, a continuación, escribir un problema multi-roscado, no hay necesidad de bloqueo no existe. El esquema se muestra a continuación:
A pesar de que el programa hace problema no bloqueo, sino porque después de cada hilo para acceder a una variable ThreadLocal mantendrá la asignación de los ejemplos de variables y específicas ThreadLocal en su propio mapa, si no eliminar estas referencias (mapas), éstos no pueden ser reciclados ThreadLocal esto puede causar una pérdida de memoria, pero JDK para resolver este problema a través de una serie de métodos ( TODO: cómo evitar pérdidas de memoria temporal JDK no elaborado )
ciclo de vida ThreadLocal
TODO: preguntas cara rallado ThreadLocal! ! ! El interior del lugar habló sobre el reciclaje
escenarios de aplicación ThreadLocal
Como se describió anteriormente, ThreadLocal aplicable a los dos escenarios siguientes (de hecho se puede atribuir a la primera hipótesis)
- Cada hilo requiere su propia instancia independiente
- También se puede construir de una instancia independiente en el interior del hilo, pero se encuentran ThreadLocal esta necesidad en una forma muy conveniente.
- Ejemplos necesidades para ser compartidos en múltiples métodos, pero no quieren ser multi-hilo compartido
- Por referencia también se pueden administrar en forma de método de inter implementado, pero menos ThreadLocal acoplamiento de códigos, y para lograr una más elegante.
⭐️⭐️⭐️⭐️ aplicación práctica ejemplo , tales como:
- aplicaciones Java Web sesiones, cada hilo tiene su propia instancia de sesión por separado, muchos lugares que operar Sesión
- En Android, clase Looper es el uso de las características de ThreadLocal
- Singleton y aplicar una única información de contexto hilo almacenada en un solo hilo, y similares, tales como ID de transacción
- Lograr thread-safe, objetos que no son compatibles con el proceso se convertirá en thread-safe después de su uso ThreadLocal, ya que cada hilo tiene una instancia de la correspondiente
- Algunos portador de datos hilo relacionada, para evitar de ida y vuelta en el método para pasar parámetros
- base de datos de gestión de conexión, a continuación, cada hilo es equivalente a una transacción
- ThreadLocal para alcanzar la corriente de las operaciones de rosca están usando la misma conexión, para asegurar que la transacción
- Gestión de conexiones de hibernación también utiliza la misma técnica
- TODO: la programación Java concurrente: análisis ThreadLocal profundidad de este artículo tiene un dos métodos discutidos para comparar la base de datos es todavía posible
TODO: ThreadLocalMap, InheritableThreadLocal 的 理解