【面试】Java并发编程

ThreadLocal

ThreadLocal 为什么会导致内存泄漏

hreadLocalMap使用ThreadLocal的弱引用作为key，如果一个ThreadLocal不存在外部强引用时，Key(ThreadLocal)势必会被GC回收，这样就会导致ThreadLocalMap中key为null， 而value还存在着强引用，只有thead线程退出以后,value的强引用链条才会断掉。

但如果当前线程再迟迟不结束的话，这些key为null的Entry的value就会一直存在一条强引用链：
Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value
永远无法回收，造成内存泄漏。

https://zhuanlan.zhihu.com/p/102571059

为什么ThreadLocalMap中的Entry的key要声明为WeakReference？

在线程池中，一个线程会不断的从队列中拿去任务执行（不发生异常的话），这个线程是会一直存活的，换句话说他的ThreadLocalMap一直都在。
如果此时ThreadLocal作为run方法里的局部变量，且ThreadLocalMap的key不声明为弱引用（则为硬引用）。run方法跑完，threadLocal被回收，但是线程不会结束（因为是线程池的线程），ThreadLocalMap不会被回收，对应上一步的生成的Entry还是保留在ThreadLocalMap的数组中，只要Thread不死（ThreadLocalMap就还在），GC就无法回收那个Entry(key,value)，然后key不为null，已经没办法判断是不是回收的了。
还是讨论ThreadLocal作为run方法里的局部变量，且ThreadLocalMap的key声明为弱引用。run方法跑完，threadLocal被回收，但是线程不会结束（因为是线程池的线程），ThreadLocalMap不会被回收，对应上一步的生成的Entry还是保留在ThreadLocalMap的数组中。等待某次GC后，Entry的key被回收，变成Entry(null,value)，在remove源码中，有对key==null的Entry进行value=null的help GC的操作。在某次调用remove还能再补救一下，相比为硬引用，已经没办法补救了，已经识别不出来哪些是正在需要GC的了。
总结来说，在ThreadLocal为局部变量的时候，不声明为WeekReference，忘记remove了，然后ThreadLocal被回收后，再也没办法确认ThreadLocalMap这个认为是用完的Entry（key，value）节点是不是可以GC了。而弱引用的Entry的key，某次GC后，无用的Entry都被标记为（null， value），此时就能识别出来是泄露的内存。

ThreadLocal 的存储结构

如何处理哈希冲突

如何处理哈希冲突： 链地址法， hash地址冲突后依次向后遍历出一个空闲位置

ThreadLocalMap如何扩容

如何实现父子线程的通信

并发的三大特性

• 原子性：
• 有序性：
• 可见性：

线程池