Java强软弱虚引用和ThreadLocal工作原理（二）

r囧r小猫 2024-03-30 08:38 64阅读 0赞

## 1. 前言 ##

读本篇文章之前，请移步到上一篇文章[Java强软弱虚引用和ThreadLocal工作原理（一）\_broadview\_java的博客-CSDN博客][Java_ThreadLocal_broadview_java_-CSDN]

我们继续来讲一下java的强软弱引用在Android开发中的使用，并深入理解一下ThreadLocal的原理

## 2. 强软弱引用在Android开发中使用 ##

再次声明一下这几个概念：

**java中的引用**：你可以理解为类似于C C++中的指针。

在java中，**引用** 和 **对象** 是两个不同的概念，**引用是指向堆内存对象的指针。**

引用是存放在**虚拟机栈中**， 而对象是存放**堆内存中。**

#### **2.1 强引用** ####

强引用在Android开发中太常见了，某个Activity中 随便举个例子：

@Override
    protected void onCreate(Bundle savedInstanceState) {
          .......
          CheckBox mAllCheckbox = new CheckBox(this);
          .......
    }

mAllCheckbox作为强引用存放在栈中，而 new CheckBox(this)作为对象存放堆内存中。通过mAllCheckbox引用 可以对该对象进行操作。

#### 2.2 软引用 ####

如果一个对象具有软引用，只有当内存不足的时候，垃圾回收器才会回收此对象，在android开发中应用较多场景的就是图片缓存， 软引用可用来实现内存敏感的高速缓存。

![406b4b8f872e447cb9bbd5015cbae1e5.png][]

在源码工程中搜索一下 SoftReference 我们可以发现 联系人， 图库 模块都有用到软引用，都是与Bitmap相关的代码。

当程序第一次从网络加载图片后，就将其缓存到存储设备上，这样子下次使用这张图片时就不再从网络上获取，这样子既节约流量也提高应用的用户体验，往往还会把图片在内存中在缓存一份，这样当应用打算从网络上请求一张图片时，程序会先从内存中获取，如果内存中没有就从设备存储中获取，如果存储也没有，那就从网络上再重新下载。因为从内存中加载图片比从存储设备中加载图片要快。所以这样提高了应用加载图片的速度，上述的缓存策略不仅仅适用于图片，也适用于其他文件类型。

我们来看着这个例子：

//创建一个HashMap    key：图片路径    value: 软引用的Bitmap对象
        private Map<String,SoftReference> mSoftReferenceBitmap = new HashMap<>();
    
        public void addBitmap(String path) {
            //通过图片路径获取Bitmap对象
            Bitmap bitmap = BitmapFactory.decodeFile(path);
            //创建软引用的Bitmap对象
            SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap);
            // 添加softBitmap到Map中使其缓存
            mSoftReferenceBitmap.put(path, softBitmap);
        }
    
        public Bitmap getBitmap(String path) {
            // 从缓存中取软引用的Bitmap对象
            SoftReference<Bitmap> softBitmap = mSoftReferenceBitmap.get(path);
            // 判断是否存在软引用
            if (softBitmap == null) {
                return null;
            }
            // 取出Bitmap对象，如果由于内存不足Bitmap被回收，将取得空
            Bitmap bitmap = softBitmap.get();
            return bitmap;
        }

在softBitmap.get()中获取Bitmap的实例的强引用,在内存充足的情况下不会回收软引用对象,可以取出bitmap

内存不足时,softBitmap.get()不在返回bitamp直接返回null,软引用被回收了

因此在获取Bitmap的对象之前要判断softBitmap == null是否为空,负责将会出现空指针异常.

#### 2.3 弱引用 ####

在Android开发中，如果使用Handler不当，很容易造成Activity的内存泄露。

这样的代码比较常见：

public class MainActivity extends AppCompatActivity {
    
        //那么这样子写有啥问题呢？
        private Handler mHandler = new Handler(){
            @Override
            public void handleMessage(@NonNull Message msg) {
                super.handleMessage(msg);
            }
        };
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            ........
        }
    }

问题在于该Handler的实例采用了内部类的写法，它是MainActivity这个实例的内部类，在Java中，关于内部类有一个特点：非静态的内部类和匿名内部类都会隐式的持有一个外部类的引用。所以，该handler实例持有了MainActivity的一个引用。

**内存泄漏的根本原因在于生命周期长的对象持有了生命周期短的对象的引用。**

这种创建Handler的方式可能造成内存泄漏，由于mHandler是Handler的非静态匿名内部类的实例，所以它持有外部类Activity引用，我们知道消息队列是在一个Looper线程中不断轮询处理消息，那么当这个Activity退出时，消息队列还有未处理的消息或者正在处理的消息（任务还没有执行完毕，Activity就退出销毁），而消息队列中Message持有mHandler实例引用，mHander又持有Activity的引用，所以导致Activity的内存无法及时回收，引发内存泄漏；

解决方法如下： 使用静态内部类 + 弱引用 的方式

public class MainActivity extends AppCompatActivity {
        //把MainActivity对象传递进去
        private MyHandler mHandler = new MyHandler(this);
    
    
        private void loadData() {
            //do request
            Message message = Message.obtain();
            mHandler.sendMessage(message);
        }
    
        //使用静态内部类
        private static class MyHandler extends Handler {
            
            private WeakReference<Context> reference;
    
            public MyHandler(Context context) {
                //弱引用的 Activity 对象
                reference = new WeakReference<Context>(context);
            }
            @Override
            public void handleMessage(Message msg) {
                super.handleMessage(msg);
                //获取弱引用的实例对象，当activity没有被销毁的时候，接收消息处理任务
                //否则就不处理
                MainActivity mainActivity = (MainActivity) reference.get();
                if (mainActivity != null) {
                    //do something to update UI via mainActivity
                }
            }
        }
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
            loadData();
        }
    }

创建一个静态Handler内部类，然后对Handler持有的对象使用弱引用，这样在回收时也可以回收Handler持有的对象，这样虽然避免了Activity泄漏，不过Looper线程的消息队列中还是可能会有待处理的消息，所以我们在Activity的Destroy时或者Stop时应该移除消息队列中的消息。

@Override
    protected void onDestroy() {
        super.onDestroy();
        mHandler.removeCallbacksAndMessages(null);
    }

使用mHandler.removeCallbacksAndMessages(null);是移除消息队列中所有消息和所有的Runnable。当然也可以使用mHandler.removeCallbacks();或mHandler.removeMessages();来移除指定的Runnable和Message。

通过上面的例子，我们总结以下几点：

1. 非静态内存类有持有对外部类的引用，所以改为使用静态内部类；

2. 对Activity的引用改为弱引用，使得Activity可以被顺利回收释放；

3. Activity在Destroy的时候应该移除消息队列中的消息；

这是最完善的解决方案。

在源码中，我们也可以找到Handler引起Activity内存泄露优化方案，直接封装好了一个WeakHandler类

public abstract class WeakHandler<T> extends Handler {
        private final WeakReference<T> mRef;
    
        /**
         * Constructs a new  handler with a weak reference to the given referent using the provided
         * Looper instead of the default one.
         *
         * @param looper The looper, must not be null.
         * @param ref the referent to track
         */
        public WeakHandler(@NonNull Looper looper, T ref) {
            super(looper);
            mRef = new WeakReference<>(ref);
        }
    
        /**
         * Constructs a new handler with a weak reference to the given referent.
         *
         * @param ref the referent to track
         */
        public WeakHandler(T ref) {
            mRef = new WeakReference<>(ref);
        }
    
        /**
         * Calls {@link #handleMessage(Message, Object)} if the WeakReference is not cleared.
         */
        @Override
        public final void handleMessage(Message msg) {
            T referent = mRef.get();
            if (referent == null) {
                return;
            }
            handleMessage(msg, referent);
        }
    
        /**
         * Subclasses must implement this to receive messages.
         *
         * <p>If the WeakReference is cleared this method will no longer be called.
         *
         * @param msg      the message to handle
         * @param referent the referent. Guaranteed to be non null.
         */
        protected abstract void handleMessage(Message msg, @NonNull T referent);
    }

在Activity中的引用代码如下：

public abstract class SetupActivity extends Activity {
    
        .........
    
        private static class SetupActivityHandler extends WeakHandler<SetupActivity> {
            SetupActivityHandler(SetupActivity activity) {
                // Should run on main thread because onAc3SupportChanged will be called on main thread.
                super(Looper.getMainLooper(), activity);
            }
    
            @Override
            protected void handleMessage(Message msg, @NonNull SetupActivity activity) 
            {
                if (msg.what == MSG_EXECUTE_ACTION) {
                    ((Runnable) msg.obj).run();
                }
            }
        }
        ........
    }

原理都是一样的，使用 静态内部类 + 弱引用 来避免造成内存泄露的问题。

## 3. ThreadLocal 探究 ##

#### 3.1 概念 ####

ThreadLocal直译过来就是线程本地的意思，实际上ThreadLocal是线程本地变量，每个线程独有，且不与其他线程变量冲突，和普通变量不同，它是与当前线程关联，每个线程都可以使用其get或set方法来访问自己的独立初始化变量副本，通常是 private static final。这就实现了线程隔离。

![edfa087950ab4facaac1571fc9474ec0.png][]注意Entry， 它的key是继承自WeakReference， 是弱引用类型，在 GC 时，key 有可能会被回收掉。

我们来看下它的4个方法：

1.public T get() \{\}

2. public void set(T value)\{\}

3. public void remove()\{\}

4. protected T initialVaule()\{\}

get()方法是用来获取ThreadLocal在当前线程中保存的变量副本， set()方法是设置当前线程中变量的副本。remove（）方法是移除当前线程中变量的副本， initialVaule是一个protected方法，一般在使用时进行重写，初始化值。

#### 3.2 set方法 ####

public void set(T value) {
            // 获取当前线程
            Thread t = Thread.currentThread();
            // 获取线程中的映射表
            ThreadLocalMap map = getMap(t);
            if (map != null)
                // 设置映射表的Key-Value，Key就是当前ThreadLocal对象
                map.set(this, value);
            else
                // 没有映射就创建新映射表
                createMap(t, value);
        }
    
      ThreadLocalMap getMap(Thread t) {
          // Thread内部维护的映射表对象
          return t.threadLocals;
      }
    
    
        /**
         * Create the map associated with a ThreadLocal. Overridden in
         * InheritableThreadLocal.
         *
         * @param t the current thread
         * @param firstValue value for the initial entry of the map
         */
        void createMap(Thread t, T firstValue) {
            t.threadLocals = new ThreadLocalMap(this, firstValue);
        }

getMap(Thread t) 获取当前线程的内部维护的映射表，ThreadLocalMap 是ThreadLocal中的一个静态内部类

#### 3.3 get方法 ####

get()方法的作用是从当前线程中取出“本地变量”，最终的结果是在当前线程的映射表中，以调用get()方法的ThreadLocal对象为Key，查询出对应的Value。

public T get() {
            // 获取当前线程
            Thread t = Thread.currentThread();
            // 获取线程中的映射表
            ThreadLocalMap map = getMap(t);
            if (map != null) {
                // 获取映射表中当前ThreadLocal对应的Value
                ThreadLocalMap.Entry e = map.getEntry(this);
                if (e != null)
                    return (T)e.value;
            }
            // 如果Map还未初始化或者Map中没有找到Key，则设置一个初始值
            return setInitialValue();
        }
        private T setInitialValue() {
           // 获取初始值，这个方法通常由ThreadLocal的泛型实例化类去实现
           T value = initialValue();
           Thread t = Thread.currentThread();
           ThreadLocalMap map = getMap(t);
           if (map != null)
               map.set(this, value);
           else
               createMap(t, value);
           return value;
       }

#### 3.4 remove方法 ####

remove()方法的作用就是删除当前线程中的“本地变量”，最终的结果是在当前线程的映射表中，通过Key移除对应的Value。

public void remove() {
             // 获取线程中的映射表
             ThreadLocalMap m = getMap(Thread.currentThread());
             if (m != null)
                 //从映射表中删除键值
                 m.remove(this);
         }

this为key值，代表当前Threadlocal对象。

## 4. ThreadLocalMap源码分析 ##

先回答两个问题：

1.  什么是ThreadLocal？  
    ThreadLocal类顾名思义可以理解为线程本地变量。也就是说如果定义了一个ThreadLocal，每个线程往这个ThreadLocal中读写是线程隔离，互相之间不会影响的。它提供了一种将可变数据通过每个线程有自己的独立副本从而实现线程封闭的机制。
2.  它大致的实现思路是怎样的？  
    Thread类有一个类型为ThreadLocal.ThreadLocalMap的实例变量threadLocals，也就是说每个线程有一个自己的ThreadLocalMap。ThreadLocalMap有自己的独立实现，可以简单地将它的key视作ThreadLocal，value为代码中放入的值（实际上key并不是ThreadLocal本身，而是它的一个弱引用）。每个线程在往某个ThreadLocal里塞值的时候，都会往自己的ThreadLocalMap里存，读也是以某个ThreadLocal作为引用，在自己的map里找对应的key，从而实现了线程隔离。

ThreadLocalMap的源码实现，才是我们读ThreadLocal源码真正要领悟的

![6608d0bb493e2881ae17b187ce37be1b.png][]

ThreadLocalMap提供了一种为ThreadLocal定制的高效实现，并且自带一种基于弱引用的垃圾清理机制。  
下面从基本结构开始一点点解读。

#### 4.1 存储结构 ####

既然是个map（注意不要与java.util.map混为一谈，这里指的是概念上的map），当然得要有自己的key和value，上面回答的问题2中也已经提及，我们可以将其简单视作key为ThreadLocal，value为实际放入的值。之所以说是**简单视作**，因为实际上ThreadLocal中存放的是ThreadLocal的弱引用。我们来看看ThreadLocalMap里的节点是如何定义的。

static class Entry extends WeakReference<java.lang.ThreadLocal<?>> {
        // 往ThreadLocal里实际塞入的值
        Object value;
     
        Entry(java.lang.ThreadLocal<?> k, Object v) {
            super(k);
            value = v;
        }
    }

Entry便是ThreadLocalMap里定义的节点，它继承了WeakReference类，定义了一个类型为Object的value，用于存放塞到ThreadLocal里的值。

####  ####

#### 4.2 为什么要弱引用 ####

读到这里，如果不问不答为什么是这样的定义形式，为什么要用弱引用，等于没读懂源码。  
因为如果这里使用普通的key-value形式来定义存储结构，实质上就会造成节点的生命周期与线程强绑定，只要线程没有销毁，那么节点在GC分析中一直处于可达状态，没办法被回收，而程序本身也无法判断是否可以清理节点。弱引用是Java中四档引用的第三档，比软引用更加弱一些，如果一个对象没有强引用链可达，那么一般活不过下一次GC。当某个ThreadLocal已经没有强引用可达，则随着它被垃圾回收，在ThreadLocalMap里对应的Entry的键值会失效，这为ThreadLocalMap本身的垃圾清理提供了便利。

#### 4.3 类成员变量与相应方法 ####

/**
     * 初始容量，必须为2的幂
     */
    private static final int INITIAL_CAPACITY = 16;
     
    /**
     * Entry表，大小必须为2的幂
     */
    private Entry[] table;
     
    /**
     * 表里entry的个数
     */
    private int size = 0;
     
    /**
     * 重新分配表大小的阈值，默认为0
     */
    private int threshold;

可以看到，ThreadLocalMap维护了一个Entry表或者说Entry数组，并且要求表的大小必须为2的幂，同时记录表里面entry的个数以及下一次需要扩容的阈值。  
显然这里会产生一个问题，**为什么必须是2的幂？**很好，但是目前还无法回答，带着问题接着往下读。

/**
     * 设置resize阈值以维持最坏2/3的装载因子
     */
    private void setThreshold(int len) {
        threshold = len * 2 / 3;
    }
     
    /**
     * 环形意义的下一个索引
     */
    private static int nextIndex(int i, int len) {
        return ((i + 1 < len) ? i + 1 : 0);
    }
     
    /**
     * 环形意义的上一个索引
     */
    private static int prevIndex(int i, int len) {
        return ((i - 1 >= 0) ? i - 1 : len - 1);
    }

ThreadLocal需要维持一个最坏2/3的负载因子，对于负载因子相信应该不会陌生，在HashMap中就有这个概念。  
ThreadLocal有两个方法用于得到上一个/下一个索引，注意这里实际上是环形意义下的上一个与下一个。

**由于ThreadLocalMap使用线性探测法来解决散列冲突，所以实际上Entry\[\]数组在程序逻辑上是作为一个环形存在的。**  
关于开放寻址、线性探测等内容，可以参考网上资料或者TAOCP（《计算机程序设计艺术》）第三卷的6.4章节。

至此，我们已经可以大致勾勒出ThreadLocalMap的内部存储结构。下面是我绘制的示意图。虚线表示弱引用，实线表示强引用。

![d666d152e756a0134ca574407138dd7f.png][]

ThreadLocalMap维护了Entry环形数组，数组中元素Entry的逻辑上的key为某个ThreadLocal对象（实际上是指向该ThreadLocal对象的弱引用），value为代码中该线程往该ThreadLoacl变量实际塞入的值。

#### 4.4 构造函数 ####

好了，接下来再来看看ThreadLocalMap的一个构造函数

/**
     * 构造一个包含firstKey和firstValue的map。
     * ThreadLocalMap是惰性构造的，所以只有当至少要往里面放一个元素的时候才会构建它。
     */
    ThreadLocalMap(java.lang.ThreadLocal<?> firstKey, Object firstValue) {
        // 初始化table数组
        table = new Entry[INITIAL_CAPACITY];
        // 用firstKey的threadLocalHashCode与初始大小16取模得到哈希值
        int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
        // 初始化该节点
        table[i] = new Entry(firstKey, firstValue);
        // 设置节点表大小为1
        size = 1;
        // 设定扩容阈值
        setThreshold(INITIAL_CAPACITY);
    }

这个构造函数在set和get的时候都可能会被间接调用以初始化线程的ThreadLocalMap。

#### 4.5 哈希函数 ####

重点看一下上面构造函数中的`int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);`这一行代码。

ThreadLocal类中有一个被final修饰的类型为int的threadLocalHashCode，它在该ThreadLocal被构造的时候就会生成，相当于一个ThreadLocal的ID，而它的值来源于

/*
     * 生成hash code间隙为这个魔数，可以让生成出来的值或者说ThreadLocal的ID较为均匀地分布在2的幂大小的数组中。
     */
    private static final int HASH_INCREMENT = 0x61c88647;
     
    private static int nextHashCode() {
        return nextHashCode.getAndAdd(HASH_INCREMENT);
    }

可以看出，它是在上一个被构造出的ThreadLocal的ID/threadLocalHashCode的基础上加上一个魔数0x61c88647的。这个魔数的选取与斐波那契散列有关，0x61c88647对应的十进制为1640531527。斐波那契散列的乘数可以用(long) ((1L << 31) \* (Math.sqrt(5) - 1))可以得到2654435769，如果把这个值给转为带符号的int，则会得到-1640531527。换句话说  
`(1L << 32) - (long) ((1L << 31) * (Math.sqrt(5) - 1))`得到的结果就是1640531527也就是0x61c88647。通过理论与实践，当我们用0x61c88647作为魔数累加为每个ThreadLocal分配各自的ID也就是threadLocalHashCode再与2的幂取模，得到的结果分布很均匀。  
ThreadLocalMap使用的是**线性探测法**，均匀分布的好处在于很快就能探测到下一个临近的可用slot，从而保证效率。这就回答了上文抛出的为什么大小要为2的幂的问题。为了优化效率。

对于`& (INITIAL_CAPACITY - 1)`，相信有过算法竞赛经验或是阅读源码较多的程序员，一看就明白，对于2的幂作为模数取模，可以用&(2n-1)来替代%2n，位运算比取模效率高很多。至于为什么，因为对2^n取模，只要不是低n位对结果的贡献显然都是0，会影响结果的只能是低n位。

**可以说在ThreadLocalMap中，形如`key.threadLocalHashCode & (table.length - 1)`（其中key为一个ThreadLocal实例）这样的代码片段实质上就是在求一个ThreadLocal实例的哈希值，只是在源码实现中没有将其抽为一个公用函数。**

#### 4.6 getEntry方法 ####

这个方法会被ThreadLocal的get方法直接调用，用于获取map中某个ThreadLocal存放的值。

private Entry getEntry(ThreadLocal<?> key) {
        // 根据key这个ThreadLocal的ID来获取索引，也即哈希值
        int i = key.threadLocalHashCode & (table.length - 1);
        Entry e = table[i];
        // 对应的entry存在且未失效且弱引用指向的ThreadLocal就是key，则命中返回
        if (e != null && e.get() == key) {
            return e;
        } else {
            // 因为用的是线性探测，所以往后找还是有可能能够找到目标Entry的。
            return getEntryAfterMiss(key, i, e);
        }
    }
     
    /*
     * 调用getEntry未直接命中的时候调用此方法
     */
    private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
        Entry[] tab = table;
        int len = tab.length;
       
        
        // 基于线性探测法不断向后探测直到遇到空entry。
        while (e != null) {
            ThreadLocal<?> k = e.get();
            // 找到目标
            if (k == key) {
                return e;
            }
            if (k == null) {
                // 该entry对应的ThreadLocal已经被回收，调用expungeStaleEntry来清理无效的entry
                expungeStaleEntry(i);
            } else {
                // 环形意义下往后面走
                i = nextIndex(i, len);
            }
            e = tab[i];
        }
        return null;
    }
     
    /**
     * 这个函数是ThreadLocal中核心清理函数，它做的事情很简单：
     * 就是从staleSlot开始遍历，将无效（弱引用指向对象被回收）清理，即对应entry中的value置为null，将指向这个entry的table[i]置为null，直到扫到空entry。
     * 另外，在过程中还会对非空的entry作rehash。
     * 可以说这个函数的作用就是从staleSlot开始清理连续段中的slot（断开强引用，rehash slot等）
     */
    private int expungeStaleEntry(int staleSlot) {
        Entry[] tab = table;
        int len = tab.length;
     
        // 因为entry对应的ThreadLocal已经被回收，value设为null，显式断开强引用
        tab[staleSlot].value = null;
        // 显式设置该entry为null，以便垃圾回收
        tab[staleSlot] = null;
        size--;
     
        Entry e;
        int i;
        for (i = nextIndex(staleSlot, len); (e = tab[i]) != null; i = nextIndex(i, len)) {
            ThreadLocal<?> k = e.get();
            // 清理对应ThreadLocal已经被回收的entry
            if (k == null) {
                e.value = null;
                tab[i] = null;
                size--;
            } else {
                /*
                 * 对于还没有被回收的情况，需要做一次rehash。
                 * 
                 * 如果对应的ThreadLocal的ID对len取模出来的索引h不为当前位置i，
                 * 则从h向后线性探测到第一个空的slot，把当前的entry给挪过去。
                 */
                int h = k.threadLocalHashCode & (len - 1);
                if (h != i) {
                    tab[i] = null;
                    
                    /*
                     * 在原代码的这里有句注释值得一提，原注释如下：
                     *
                     * Unlike Knuth 6.4 Algorithm R, we must scan until
                     * null because multiple entries could have been stale.
                     *
                     * 这段话提及了Knuth高德纳的著作TAOCP（《计算机程序设计艺术》）的6.4章节（散列）
                     * 中的R算法。R算法描述了如何从使用线性探测的散列表中删除一个元素。
                     * R算法维护了一个上次删除元素的index，当在非空连续段中扫到某个entry的哈希值取模后的索引
                     * 还没有遍历到时，会将该entry挪到index那个位置，并更新当前位置为新的index，
                     * 继续向后扫描直到遇到空的entry。
                     *
                     * ThreadLocalMap因为使用了弱引用，所以其实每个slot的状态有三种也即
                     * 有效（value未回收），无效（value已回收），空（entry==null）。
                     * 正是因为ThreadLocalMap的entry有三种状态，所以不能完全套高德纳原书的R算法。
                     *
                     * 因为expungeStaleEntry函数在扫描过程中还会对无效slot清理将之转为空slot，
                     * 如果直接套用R算法，可能会出现具有相同哈希值的entry之间断开（中间有空entry）。
                     */
                    while (tab[h] != null) {
                        h = nextIndex(h, len);
                    }
                    tab[h] = e;
                }
            }
        }
        // 返回staleSlot之后第一个空的slot索引
        return i;
    }

我们来回顾一下从ThreadLocal读一个值可能遇到的情况：  
根据入参threadLocal的threadLocalHashCode对表容量取模得到index

1、如果index对应的slot就是要读的threadLocal，则直接返回结果

2、调用getEntryAfterMiss线性探测，过程中每碰到无效slot，调用expungeStaleEntry进行段清理；如果找到了key，则返回结果entry

3、没有找到key，返回null

#### 4.7 set方法 ####

private void set(ThreadLocal<?> key, Object value) {
     
        Entry[] tab = table;
        int len = tab.length;
        int i = key.threadLocalHashCode & (len - 1);
        // 线性探测
        for (Entry e = tab[i]; e != null; e = tab[i = nextIndex(i, len)]) {
            ThreadLocal<?> k = e.get();
            // 找到对应的entry
            if (k == key) {
                e.value = value;
                return;
            }
            // 替换失效的entry
            if (k == null) {
                replaceStaleEntry(key, value, i);
                return;
            }
        }
     
        tab[i] = new Entry(key, value);
        int sz = ++size;
        if (!cleanSomeSlots(i, sz) && sz >= threshold) {
            rehash();
        }
    }
     
    private void replaceStaleEntry(ThreadLocal<?> key, Object value,
                                   int staleSlot) {
        Entry[] tab = table;
        int len = tab.length;
        Entry e;
     
        // 向前扫描，查找最前的一个无效slot
        int slotToExpunge = staleSlot;
        for (int i = prevIndex(staleSlot, len);
             (e = tab[i]) != null;
             i = prevIndex(i, len)) {
            if (e.get() == null) {
                slotToExpunge = i;
            }
        }
     
        // 向后遍历table
        for (int i = nextIndex(staleSlot, len);
             (e = tab[i]) != null;
             i = nextIndex(i, len)) {
            ThreadLocal<?> k = e.get();
     
            // 找到了key，将其与无效的slot交换
            if (k == key) {
                // 更新对应slot的value值
                e.value = value;
     
                tab[i] = tab[staleSlot];
                tab[staleSlot] = e;
     
                /*
                 * 如果在整个扫描过程中（包括函数一开始的向前扫描与i之前的向后扫描）
                 * 找到了之前的无效slot则以那个位置作为清理的起点，
                 * 否则则以当前的i作为清理起点
                 */
                if (slotToExpunge == staleSlot) {
                    slotToExpunge = i;
                }
                // 从slotToExpunge开始做一次连续段的清理，再做一次启发式清理
                cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
                return;
            }
     
            // 如果当前的slot已经无效，并且向前扫描过程中没有无效slot，则更新slotToExpunge为当前位置
            if (k == null && slotToExpunge == staleSlot) {
                slotToExpunge = i;
            }
        }
     
        // 如果key在table中不存在，则在原地放一个即可
        tab[staleSlot].value = null;
        tab[staleSlot] = new Entry(key, value);
     
        // 在探测过程中如果发现任何无效slot，则做一次清理（连续段清理+启发式清理）
        if (slotToExpunge != staleSlot) {
            cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
        }
    }
     
    /**
     * 启发式地清理slot,
     * i对应entry是非无效（指向的ThreadLocal没被回收，或者entry本身为空）
     * n是用于控制控制扫描次数的
     * 正常情况下如果log n次扫描没有发现无效slot，函数就结束了
     * 但是如果发现了无效的slot，将n置为table的长度len，做一次连续段的清理
     * 再从下一个空的slot开始继续扫描
     * 
     * 这个函数有两处地方会被调用，一处是插入的时候可能会被调用，另外个是在替换无效slot的时候可能会被调用，
     * 区别是前者传入的n为元素个数，后者为table的容量
     */
    private boolean cleanSomeSlots(int i, int n) {
        boolean removed = false;
        Entry[] tab = table;
        int len = tab.length;
        do {
            // i在任何情况下自己都不会是一个无效slot，所以从下一个开始判断
            i = nextIndex(i, len);
            Entry e = tab[i];
            if (e != null && e.get() == null) {
                // 扩大扫描控制因子
                n = len;
                removed = true;
                // 清理一个连续段
                i = expungeStaleEntry(i);
            }
        } while ((n >>>= 1) != 0);
        return removed;
    }
     
     
    private void rehash() {
        // 做一次全量清理
        expungeStaleEntries();
     
        /*
         * 因为做了一次清理，所以size很可能会变小。
         * ThreadLocalMap这里的实现是调低阈值来判断是否需要扩容，
         * threshold默认为len*2/3，所以这里的threshold - threshold / 4相当于len/2
         */
        if (size >= threshold - threshold / 4) {
            resize();
        }
    }
     
    /*
     * 做一次全量清理
     */
    private void expungeStaleEntries() {
        Entry[] tab = table;
        int len = tab.length;
        for (int j = 0; j < len; j++) {
            Entry e = tab[j];
            if (e != null && e.get() == null) {
                /*
                 * 个人觉得这里可以取返回值，如果大于j的话取了用，这样也是可行的。
                 * 因为expungeStaleEntry执行过程中是把连续段内所有无效slot都清理了一遍了。
                 */
                expungeStaleEntry(j);
            }
        }
    }
     
    /**
     * 扩容，因为需要保证table的容量len为2的幂，所以扩容即扩大2倍
     */
    private void resize() {
        Entry[] oldTab = table;
        int oldLen = oldTab.length;
        int newLen = oldLen * 2;
        Entry[] newTab = new Entry[newLen];
        int count = 0;
     
        for (int j = 0; j < oldLen; ++j) {
            Entry e = oldTab[j];
            if (e != null) {
                ThreadLocal<?> k = e.get();
                if (k == null) {
                    e.value = null; 
                } else {
                    // 线性探测来存放Entry
                    int h = k.threadLocalHashCode & (newLen - 1);
                    while (newTab[h] != null) {
                        h = nextIndex(h, newLen);
                    }
                    newTab[h] = e;
                    count++;
                }
            }
        }
     
        setThreshold(newLen);
        size = count;
        table = newTab;
    }

我们来回顾一下ThreadLocal的set方法可能会有的情况

*  探测过程中slot都不无效，并且顺利找到key所在的slot，直接替换即可
 *  探测过程中发现有无效slot，调用replaceStaleEntry，效果是最终一定会把key和value放在这个slot，并且会尽可能清理无效slot
    
     *  在replaceStaleEntry过程中，如果找到了key，则做一个swap把它放到那个无效slot中，value置为新值
     *  在replaceStaleEntry过程中，没有找到key，直接在无效slot原地放entry
 *  探测没有发现key，则在连续段末尾的后一个空位置放上entry，这也是线性探测法的一部分。放完后，做一次启发式清理，如果没清理出去key，并且当前table大小已经超过阈值了，则做一次rehash，rehash函数会调用一次全量清理slot方法也即expungeStaleEntries，如果完了之后table大小超过了threshold - threshold / 4，则进行扩容2倍

#### 4.8 remove方法 ####

/**
     * 从map中删除ThreadLocal
     */
    private void remove(ThreadLocal<?> key) {
        Entry[] tab = table;
        int len = tab.length;
        int i = key.threadLocalHashCode & (len - 1);
        for (Entry e = tab[i];
             e != null;
             e = tab[i = nextIndex(i, len)]) {
            if (e.get() == key) {
                // 显式断开弱引用
                e.clear();
                // 进行段清理
                expungeStaleEntry(i);
                return;
            }
        }
    }

remove方法相对于getEntry和set方法比较简单，直接在table中找key，如果找到了，把弱引用断了做一次段清理。

## 5. ThreadLocal与内存泄漏 ##

关于ThreadLocal是否会引起内存泄漏也是一个比较有争议性的问题，其实就是要看对内存泄漏的准确定义是什么。  
认为ThreadLocal会引起内存泄漏的说法是因为如果一个ThreadLocal对象被回收了，我们往里面放的value对于**【当前线程->当前线程的threadLocals(ThreadLocal.ThreadLocalMap对象）->Entry数组->某个entry.value】**这样一条强引用链是可达的，因此value不会被回收。

认为ThreadLocal不会引起内存泄漏的说法是因为ThreadLocal.ThreadLocalMap源码实现中自带一套自我清理的机制。

当我们仔细读过ThreadLocalMap的源码，我们可以推断，如果在使用的ThreadLocal的过程中，显式地进行remove是个很好的编码习惯，这样是不会引起内存泄漏。

## 6. 参考文章 ##

文章链接：[ThreadLocal源码解读 - 活在夢裡 - 博客园][ThreadLocal_ - _ -]

##  ##

[Java_ThreadLocal_broadview_java_-CSDN]: https://blog.csdn.net/u012514113/article/details/127976854?spm=1001.2014.3001.5502
[406b4b8f872e447cb9bbd5015cbae1e5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/448a4183527b4d0ebacba5c89225169c.png
[edfa087950ab4facaac1571fc9474ec0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/c8fdb4a0927f4c588e0af92aa0e28947.png
[6608d0bb493e2881ae17b187ce37be1b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/e71a8591d7894944899bd3837b507bea.png
[d666d152e756a0134ca574407138dd7f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/bf4c0c5e99874ce7888bae0870c28cf2.png
[ThreadLocal_ - _ -]: https://www.cnblogs.com/micrari/p/6790229.html