https://blog.csdn.net/qunqunstyle99/article/details/94717256
Una cosa a tener en cuenta aquí es:
Sabemos que al usar ThreadLocal, primero debemos renovarlo, de la siguiente manera:
public static void main(String[] args) throws InterruptedException {
ThreadLocal<String> threadLocal= new ThreadLocal();
tl1(threadLocal);
Thread.sleep(1000);
tl2(threadLocal);
}
public static void tl1(ThreadLocal<String> threadLocal){
threadLocal.set("xx");
}
public static void tl2(ThreadLocal<String> threadLocal){
System.out.println(threadLocal.get());
}
De hecho, después de guardarlo y sacarlo de otro lugar, existe esta fuerte referencia a nuevo
, por lo que dentro de este rango de tiempo, ThreadLocal no será reciclado.
Cuando usamos el código, después de eliminar la referencia fuerte:
threadLocal = null;
Cuando ocurre GC, el objeto apuntado por threadLocal será reciclado, incluso si la referencia débil en el hilo apunta al nuevo obj, es inútil
Sin embargo, del escenario real, hemos eliminado la referencia fuerte nosotros mismos, y no debe haber forma de llamar al método get para obtener el valor más tarde.
De hecho, no hay pérdida de datos comerciales.
Sin embargo, si escribimos el código threadLocal = null;, se producirá una pérdida de memoria
cuando el GC quite nuestro nuevo objeto ThreadLocal, pero su valor no se ha quitado
, por lo tanto, conduce a una pérdida de memoria.
Por lo tanto, cuando no necesitamos este ThreadLocal, debemos liberar activamente el recurso, llamar al método
remove y eliminarlo de la memoria del hilo.
Por supuesto, si el hilo en sí termina, la variable ThreadLocal dentro del hilo también puede ser clara.