ThreadLocal的使用以及引发的一些java弱引用的扩展

 ThreadLocal通过get(),set()方法从当前线程的成员变量threadLocals(ThreaLocal.ThreadLocalMap)中获取变量值,threadLocals中是以键值对的形式存储,其中key是ThreadLocal对象,value是要存储的变量.

 当前线程的成员变量threadLocals只能当前线程访问,这样就能很好避免多线程的问题,用法:

public class JDBCUtils {
	private static ComboPooledDataSource ds = new ComboPooledDataSource();
	private static ThreadLocal<Connection> tl = new ThreadLocal<>();

	/**
	 * 从线程中获取连接
	 * 
	 * @return
	 * @throws SQLException
	 */
	public static Connection getConnection() throws SQLException {
		// 从线程中获取conneciton
		Connection conn = tl.get();
		if (conn == null) {
			conn = ds.getConnection();
			// 和当前线程绑定
			tl.set(conn);
		}
		return conn;
	}
}

 这样就可以防止多线程访问时的线程安全问题,

class ConnectionManager {
     
    private static Connection connect = null;
     
    public static Connection openConnection() {
        if(connect == null){
            connect = DriverManager.getConnection();
        }
        return connect;
    }
     
    public static void closeConnection() {
        if(connect!=null)
            connect.close();
    }
}

以上代码存在线程安全问题:

第一，这里面的2个方法都没有进行同步，很可能在openConnection方法中会多次创建connect；

第二，由于connect是共享变量，那么必然在调用connect的地方需要使用到同步来保障线程安全，因为很可能一个线程在使用connect进行数据库操作，而另外一个线程调用closeConnection关闭链接。

ThreadLocal的内存泄露问题:

java中引用关系图

 参考来源:https://www.cnblogs.com/xzwblog/p/7227509.html

如上图，ThreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal没有外部强引用引用他，那么系统gc的时候，这个ThreadLocal势必会被回收，这样一来，ThreadLocalMap中就会出现key为null的Entry，就没有办法访问这些key为null的Entry的value，如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：
Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value
永远无法回收，造成内存泄露。
　　
　　ThreadLocalMap设计时的对上面问题的对策：
ThreadLocalMap的getEntry函数的流程大概为：

 

 更多参考:

1. 首先从ThreadLocal的直接索引位置(通过ThreadLocal.threadLocalHashCode & (table.length-1)运算得到)获取Entry e，如果e不为null并且key相同则返回e；
2. 如果e为null或者key不一致则向下一个位置查询，如果下一个位置的key和当前需要查询的key相等，则返回对应的Entry。否则，如果key值为null，则擦除该位置的Entry，并继续向下一个位置查询。在这个过程中遇到的key为null的Entry都会被擦除，那么Entry内的value也就没有强引用链，自然会被回收。仔细研究代码可以发现，set操作也有类似的思想，将key为null的这些Entry都删除，防止内存泄露。
   　　但是光这样还是不够的，上面的设计思路依赖一个前提条件：要调用ThreadLocalMap的getEntry函数或者set函数。这当然是不可能任何情况都成立的，所以很多情况下需要使用者手动调用ThreadLocal的remove函数，手动删除不再需要的ThreadLocal，防止内存泄露。所以JDK建议将ThreadLocal变量定义成private static的，这样的话ThreadLocal的生命周期就更长，由于一直存在ThreadLocal的强引用，所以ThreadLocal也就不会被回收，也就能保证任何时候都能根据ThreadLocal的弱引用访问到Entry的value值，然后remove它，防止内存泄露。

 java弱引用:

        参考:https://www.cnblogs.com/zjj1996/p/9140385.html