El uso de InheritableThreadLocal y el análisis de código fuente más simple y fácil de entender

El uso básico y el código fuente de ThreadLocal

Los puntos de conocimiento sobre ThreadLocal necesitan leer otro blog:
ThreadLocal desde el uso simple y el código fuente

Uso básico de InheritableThreadLocal

Después de entender ThreadLocal, veamos el siguiente ejemplo: encontrará
inserte la descripción de la imagen aquí
un inconveniente de ThreadLocal: los hilos principales y secundarios no pueden compartir datos.
Entonces, modifiquemos el ejemplo: use InheritableThreadLocal para resolver este problema a la perfección.
inserte la descripción de la imagen aquí

Análisis del código fuente:

Aquí, intente detenerse y pensar:
(1) ¿Cómo permite que el subproceso secundario obtenga los parámetros establecidos por el subproceso principal?
(2) ¿Dónde se coloca? ¿Cómo sacarlo?
Tienes que mirar estas dos preguntas para entender mejor

1: ¿Cómo decirlo?

Aquí debemos prestar mucha atención a distinguir el subproceso creado por el subproceso padre, cuál es el padre y cuál es el hijo.El
primer paso es decirles a todos directamente dónde se almacena el valor del parámetro:
inserte la descripción de la imagen aquí
aquí se puede entender simplemente que el la ubicación es diferente, pero todos sabemos que ThreadLocal Value se almacena en el Thread correspondiente, por lo que lo realmente importante depende de cómo establecer estos dos valores en la parte de creación de inicialización de Thread

Comencemos con la inicialización del hilo:
inserte la descripción de la imagen aquí
inserte la descripción de la imagen aquí
inserte la descripción de la imagen aquí

⚠️ Tenga en cuenta que es muy importante inicializar el valor predeterminado verdadero aquí, y este paso se evaluará en el siguiente paso

inserte la descripción de la imagen aquí
Un poco más abajo, hay otra pieza de lógica:
inserte la descripción de la imagen aquí
Juicio: si se establecen los ThreadLocals heredados del subproceso principal actual, a través del método createInheritedMap, devuelva un ThreadLocalMap y guárdelo en la clase de subproceso secundario que se está creando actualmente. ¿este? Porque de esta manera, el valor de heritageThreadLocals del hilo padre que está creando el hilo hijo se puede asignar al valor de heritageThreadLocals del hilo hijo que se está creando. En esta ronda, es necesario distinguir quién es el creador actual y quién está creando. Continúe para ver
el método createInheritedMap:
inserte la descripción de la imagen aquí
se encuentra que este método crea un nuevo ThreadLocalMap y lo devuelve. El código fuente dice que el mapa devuelto está asociado con el subproceso principal.

¿Cómo conseguirlo?

Esto es relativamente simple, heredableThreadLocals reescribe un método:
inserte la descripción de la imagen aquí

Lo que hace que regrese no es t.threadLocal, sino t.inheritableThreadLocals, y este método getMap es precisamente para obtener el método ThreadLocalMap del hilo correspondiente, luego obtener el valor del mapa y luego regresar, hasta ahora termina todo el espectáculo.
inserte la descripción de la imagen aquí
inserte la descripción de la imagen aquí

Hoyo usado con pileta de rosca ⚠️

De acuerdo con el análisis del código fuente anterior, no es difícil para nosotros sacar una conclusión: debe ser un subproceso secundario inicializado para heredar la variable heritageThreadLocals del subproceso principal, entonces si es un grupo de subprocesos, porque es la razón de subprocesos de multiplexación, no hay inicio, por lo que, naturalmente, no hay El método de reasignación conducirá a la inconsistencia entre los parámetros obtenidos del subproceso secundario y los parámetros introducidos en InheritableThreadLocal por el subproceso principal

Supongo que te gusta

Origin blog.csdn.net/whiteBearClimb/article/details/123063900
Recomendado
Clasificación