ThreadLocal源码探究 (JDK 1.8)

ThreadLocal类之前有了解过,看过一些文章,自以为对其理解得比较清楚了。偶然刷到了一道关于ThreadLocal内存泄漏的面试题,居然完全不知道是怎么回事,痛定思痛,发现了解问题的本质还是需要从源码看起。
ThreadLocal可以保存一些线程私有的数据,从而避免多线程环境下的数据共享问题。ThreadLocal存储数据的功能是通过ThreadLocalMap实现的,这是ThreadLocal的一个静态内部类。ThreadLocal源码加注释总共700多行,ThreadLocalMap就占据了接近400行,基本上理解了ThreadLocalMap也就理解了ThreadLocal。本文先简介ThreadLocalMap,然后从ThreadLocal的核心方法开始讲起,需要用到ThreadLocalMap的地方顺带一起介绍。

1.ThreadLocalMap简介

ThreadLocalMap本质上仍然是一个Map,具有普通Map的特点,则意味着ThreadLocalMap可以保存多个ThreadLocal:value的键值对,并且不同的ThreadLocal对象可能会产生冲突。当遇到hash冲突的时候,采用线性探测的方式来解决冲突,底层使用数组作为存储结构,它的主要字段如下:

  • INITIAL_CAPACITY:初始容量,默认是16
  • Entry[] table:存储键值对的数组,其大小是2的整数幂
  • size:数组内存储的元素个数
  • threshold:扩容阈值
    ThreadLocalMap底层数组保存的是Entry类型键值对,EntryThreadLocalMap的一个内部类,它是用来存储键值对的对象,值得关注的是Entry继承了WeakReference这个弱引用类,这意味着Entry的key引用的对象,在没有其他强引用的情况下,在下一次GC的时候就会被回收(注意:这里忽略了软引用,因为软引用是在即将因为内存不足而抛出异常的时候才会回收)。并且EntrykeyThreadLocal对象,通过其祖父类Reference的构造函数可以看到,key实际上是被保存在referent字段中,Entry对象的get方法也是从Reference继承过来的,直接返回该referent字段。
    static class Entry extends WeakReference<ThreadLocal<?>> {
        Object value;

        Entry(ThreadLocal<?> k, Object v) {
            super(k);
            value = v;
        }
    }
    
    //Entry的构造器调用了父类的构造,最终是通过Reference的构造器实现的
    Reference(T referent) {
        this(referent, null);
    }

    Reference(T referent, ReferenceQueue<? super T> queue) {
        this.referent = referent;
        this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
    }
    
    //Reference的get方法
    public T get() {
        return this.referent;
    }

在对Entry有了初步了解后,现在来思考一下为什么key要设计成弱引用呢?假设现在采有强引用来设计key,考虑如下代码:

    ThreadLocal<String> tl1 = new ThreadLocal<>();
    tl1.set("abc");
    tl1=null;

此时,相关的引用情况如下图:

tl1虽然不再引用堆上的ThreadLocal对象,但是线程的ThreadLocalMap里还保留着对该对象的强引用,要获取该对象就需要ThreadLocal对象作为key,但是这个key现在已经是null了。也就是说,此时已经没有任何办法能够访问到堆上的TheradLocal对象,但是由于还有强引用的存在,导致这个对象无法被GC回收。这种情况显然不是我们希望看到的,因此Entrykey不能被设计为强引用。设计成弱引用是合理的,一旦外界的强引用被取消,就应当允许key所引用的对象被回收。

2.ThreadLocal核心方法

  • get
    get方法用来获取存储在ThreadLocal中的元素,其源码如下:
    public T get() {
        Thread t = Thread.currentThread();
        //获取当前线程内部的ThreadLocalMap对象
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null) {
                @SuppressWarnings("unchecked")
                T result = (T)e.value;
                return result;
            }
        }
        //执行到这里的两种情况:1)map没初始化;2)map.getEntry返回null
        return setInitialValue();
    }
    
    //从这里可以看到,每个Thread示例内部都有一个ThreadLocalMap类型的字段,线程局部变量就存在这个Map中
    ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }

    //ThreadLocalMap的getEntry方法
    private Entry getEntry(ThreadLocal<?> key) {
        //计算key位于哪个桶
        int i = key.threadLocalHashCode & (table.length - 1);
        Entry e = table[i];
        if (e != null && e.get() == key)
            return e;
        //执行到这里的两种情况:1)e=null,即桶内没有存数据;2)桶内有数据,
        //但不是当前这个ThreadLocal对象的,说明产生了hash冲突,导致键值对被放到了其他位置
        else
            return getEntryAfterMiss(key, i, e);
    }

线程能够保存私有变量的原因就在于其成员变量threadLocals,每个线程都有这样的结构,互相不干扰。get方法的代码很简单,根据从线程内取到的ThreadLocalMap对象,如果ThreadLocalMap还没初始化,则先初始化;如果已完成初始化,调用其getEntry方法取元素,取不到的话,就会执行getEntryAfterMiss方法(ThreadLocal内部只在getEntry方法里调用了getEntryAfterMiss),先看看setInitialValue方法的逻辑:

    private T setInitialValue() {
        T value = initialValue();
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        //对应getEntry方法中的情况2:map已经初始化,但是对应的Entry为空的情,此时将键值对存入底层数组
        if (map != null)
            map.set(this, value);
        //对应getEntry方法中的情况1:map没初始化
        else
            createMap(t, value);
        return value;
    }
    
    //默认的initialValue返回null,而且该方法是protected,目的显然是让子类进行重写
    protected T initialValue() {
        return null;
    }

setInitialValue的逻辑很简单,假如map没有初始化,执行createMap方法进行初始化,否则将当前ThreadLocal对象和null构造成一个新的Entry放入数组内。接下来看一下createMap的初始化逻辑:

    //可以看到,初始化的过程就是对Thread内部变量threadLocals赋值的过程,用到了ThreadLocalMap的构造器
    void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }
    
    //
    ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) {
        //使用默认容量
        table = new Entry[INITIAL_CAPACITY];
        //计算位置,并初始化对应的桶
        int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
        table[i] = new Entry(firstKey, firstValue);
        size = 1;
        setThreshold(INITIAL_CAPACITY);
    }

    /**
     * Set the resize threshold to maintain at worst a 2/3 load factor.
     */
    //在对threshold初始化的时候使用了2/3作为系数
    private void setThreshold(int len) {
        threshold = len * 2 / 3;
    }

该方法通过ThreadLocalMap的构造器对内部数组进行初始化,并将对应的值添加到数组中。可以看到,ThreadLocalMap有容量的概念,但却没有办法指定其初始容量,在构造的时候使用固定值16作为初始容量。稍后在rehash()方法中将会看到,在判断是否需要扩容时,是以threshold*0.75作为标准。
接下来看看getEntryAfterMiss方法的源码:

    private Entry getEntryAfterMiss(ThreadLocal<?> key, int i, Entry e) {
        Entry[] tab = table;
        int len = tab.length;

        while (e != null) {
            ThreadLocal<?> k = e.get();
            //找到key就直接返回
            if (k == key)
                return e;
            //注意这里:当发现key=null时,说明其对应的ThreadLocal对象已被GC回收,
            //此时会通过expungeStaleEntry将一部分key为null的桶清空
            if (k == null)
                expungeStaleEntry(i);
            //走到这里说明存在hash冲突,当前桶被其他元素占了,使用nextIndex向后找一个位置
            else
                i = nextIndex(i, len);
            e = tab[i];
        }
        //如果e=null,在这里返回null
        return null;
    }
    
    /nextIndex的主要作用是:查找下一个桶,如果到达末尾,则从头开始
    private static int nextIndex(int i, int len) {
        return ((i + 1 < len) ? i + 1 : 0);
    }
    
    //这里顺带将prevIndex的代码也放上来,与nextIndex方向相反
    private static int prevIndex(int i, int len) {
        return ((i - 1 >= 0) ? i - 1 : len - 1);
    }

在桶内的key=null时,会调用expungeStaleEntry方法,从命名可以看出,这个方法主要功能是将ThreadLocalMapkey=null的部分元素清理掉,下面是对这个方法的讲解:

  • expungeStaleEntry
        private int expungeStaleEntry(int staleSlot) {
            Entry[] tab = table;
            int len = tab.length;

            // expunge entry at staleSlot
            //分别将Entry的键和值清空
            tab[staleSlot].value = null;
            tab[staleSlot] = null;
            //元素数量减1
            size--;

            // Rehash until we encounter null
            Entry e;
            int i;
            //从当前下标的下一个位置开始遍历,清空key=null的桶,并更新hash冲突的元素的位置
            //循环终止条件:顺序向后遍历时,找到一个非空的桶则循环终止,因此这里只是作了局部清理
            for (i = nextIndex(staleSlot, len);
                 (e = tab[i]) != null;
                 i = nextIndex(i, len)) {
                ThreadLocal<?> k = e.get();
                //如果key = null,则清空该桶
                if (k == null) {
                    e.value = null;
                    tab[i] = null;
                    size--;
                } else {
                    int h = k.threadLocalHashCode & (len - 1);
                    //h!=i说明当前元素是因为hash冲突,之前的桶被占了才放在了i这个桶内,
                    //那么就从其原来的位置h开始向后查找,找到第一个空桶,就把元素挪过去,
                    //目的是为了保证元素距离其正确位置最近,减少后续的查找成本
                    if (h != i) {
                        tab[i] = null;

                        // Unlike Knuth 6.4 Algorithm R, we must scan until
                        // null because multiple entries could have been stale.
                        while (tab[h] != null)
                            h = nextIndex(h, len);
                        tab[h] = e;
                    }
                }
            }
            //返回值是第一个为空的桶的下标
            return i;
        }

expungeStaleEntry方法的逻辑是:先将staleSlot这个桶置空,然后从下一个位置开始遍历数组元素,遇到keynull的桶直接清理,并将长度减1,遇到因为hash冲突而放在后面位置的元素,则从该元素本来的位置开始,向后找到第一个空桶,然后把元素移动到这个空桶。expungeStaleEntry的循环逻辑说明,在对失效元素进行清空时,不是清空所有失效的桶,而是从当前位置向后遍历,只要找到一个非空的桶,清理的过程就结束了。也就是说,这种清理只是部分清理,空桶后面的过期失效的桶无法得到清理。

  • set
    介绍完get方法后,现在再来看看set方法的实现逻辑:
    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        //map已创建则直接设值
        if (map != null)
            map.set(this, value);
        //map未创建,则创建map
        else
            createMap(t, value);
    }

来看看mapset方法是如何设值的:

    private void set(ThreadLocal<?> key, Object value) {

        // We don't use a fast path as with get() because it is at
        // least as common to use set() to create new entries as
        // it is to replace existing ones, in which case, a fast
        // path would fail more often than not.

        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();
            
            //如果当前ThreadLocal对应的有值,则更新
            if (k == key) {
                e.value = value;
                return;
            }
            
            //如果k=null,说明对应的ThreadLocal对象已被GC回收,执行replaceStaleEntry的逻辑
            if (k == null) {
                //这里是replaceStaleEntry方法的唯一调用点,注意该方法执行完之后,set方法就返回了
                replaceStaleEntry(key, value, i);
                return;
            }
        }
        //找到一个空位置,将值存进去
        tab[i] = new Entry(key, value);
        int sz = ++size;
        //如果调用cleanSomeSlots没有清理任何桶,并且达到了扩容阈值,就执行扩容逻辑
        if (!cleanSomeSlots(i, sz) && sz >= threshold)
            rehash();
    }

set的时候需要从对应的下标开始向后遍历,找到一个合适的位置将元素放进去,这里合适的位置是指:a)空桶;b)桶非空,但是key对应的ThreadLocal对象已被清理。在key已经被清理的情况下,会执行replaceStaleEntry方法的逻辑,接下来看看这个方法的代码:

    private void replaceStaleEntry(ThreadLocal<?> key, Object value, int staleSlot) {
        Entry[] tab = table;
        int len = tab.length;
        Entry e;

        // Back up to check for prior stale entry in current run.
        // We clean out whole runs at a time to avoid continual
        // incremental rehashing due to garbage collector freeing
        // up refs in bunches (i.e., whenever the collector runs).
        int slotToExpunge = staleSlot;
        //从staleSlot这个桶向前查找,遇到第一个空桶就停止
        for (int i = prevIndex(staleSlot, len);
             (e = tab[i]) != null;
             i = prevIndex(i, len))
             //如果桶内的key=null,说明该桶可以被回收,将slotToExpunge变量指向这个桶
            if (e.get() == null)
                slotToExpunge = i;

        // Find either the key or trailing null slot of run, whichever
        // occurs first
        //从当前桶向后遍历
        for (int i = nextIndex(staleSlot, len);
             (e = tab[i]) != null;
             i = nextIndex(i, len)) {
            ThreadLocal<?> k = e.get();

            // If we find key, then we need to swap it
            // with the stale entry to maintain hash table order.
            // The newly stale slot, or any other stale slot
            // encountered above it, can then be sent to expungeStaleEntry
            // to remove or rehash all of the other entries in run.
            // k== key,说明这个ThreadLocal已经存在,但是距离正确的位置太远,需要对其位置进行更正
            if (k == key) {
                //更新value值
                e.value = value;

                //交换两个桶内的元素,i位置的元素本来就应该在staleSlot位置,但是hash冲突导致该元素放到了后面的位置,
                //这里是把该元素换到正确位置。
                //注意,replaceStaleEntry的唯一调用点出现在set方法内,此时staleSlot对应的桶的key=null,
                //赋值语句 tab[i] = tab[staleSlot] 是将staleSlot位置上待清理的元素放在i位置,使得i位置变成过期元素。
                //个人推测这里不直接赋值tab[i]=null的原因是让下一次expungeStaleEntry能够多清理一些空桶,
                //如果这里设置为null的话,下一次清理到这个空位置就终止了
                tab[i] = tab[staleSlot];
                tab[staleSlot] = e;

                // Start expunge at preceding stale entry if it exists
                //下面的等式成立有两种情况:
                //1)staleSlot前一个桶就为空,此时上文中前向遍历的循环体会直接结束;
                //2)staleSlot前面的若干桶都不为空,且桶内的key!=null,即对应的ThreadLocal对象都没有被回收;
                //出现这两种情况的时候,都只能从i这个位置开始进行清理
                if (slotToExpunge == staleSlot)
                    slotToExpunge = i;
                cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
                return;
            }

            // If we didn't find stale entry on backward scan, the
            // first stale entry seen while scanning for key is the
            // first still present in the run.
            //k!=null的时候,不能清理i这个桶;slotToExpunge != staleSlot时,
            //说明在i这个位置之前就已经有需要清理的桶了,不能更新slotToExpunge这个指针的值
            if (k == null && slotToExpunge == staleSlot)
                slotToExpunge = i;
        }

        // If key not found, put new entry in stale slot
        //执行到这里说明,直到遇到空桶,都没有在数组中找到key,就把新的键值对放在staleSlot的位置。
        //需要注意的是,for循环到空桶就停止了,有可能当前这个threadlocal对象已经有键值对了,只是位置在这个空桶后面而已,
        //因此这段逻辑可能会使得同一个key在数组中出现多次。
        tab[staleSlot].value = null;
        tab[staleSlot] = new Entry(key, value);

        // If there are any other stale entries in run, expunge them
        //slotToExpunge != staleSlot说明在其他位置找到需要清理的键值对,那么就从对应的位置清理
        if (slotToExpunge != staleSlot)
            cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
    }

针对代码注释中的内容,有几点需要强调一下。首先replaceStaleEntry这个方法唯一的调用点就是ThreadLocalMapset方法内部,而且在调用replaceStaleEntry的时候,参数staleSlot对应的桶内的Entry对象的key=null。其次,replaceStaleEntry的逻辑是从staleSlot这个桶开始,先前向遍历,找到第一个空桶就停止遍历,期间如果发现某个桶内的key=null,就将slotToExpunge指针指向这个桶,表示下文要从这个桶开始进行过期键清理。前向遍历结束之后开始后向遍历,找到当前的ThreadLocal对象所在的桶,将其位置更新,调用清理方法之后代码返回,否则就一直向后找直到遇到空桶。另外,根据分析,for循环在遇到空桶就结束了,但是很可能对应的key就在空桶后面,replaceStaleEntry可能会造成同一个key在数据中出现多次,本文最后将证明,key是不可能出现多次的。

下面对replaceStaleEntry方法的执行流程进行梳理。
假设在方法执行时,ThreadLocalMap的存储结构如下所示:

首先前向遍历,遍历到LL位置结束,由于在L位置Entry.key=null,所以设置slotToExpunge=L

接下来开始向后遍历,遍历到R1位置时,虽然Entry.key=null,但是由于slotToExpunge的值已经被修改,不再对其进行赋值。代码接着遍历R2位置,在这里找到了key,因此将该位置的值与staleSlot位置进行交换,如下图:

之后执行expungeStaleEntry方法将LL位置清空,然后从L位置开始执行cleanSomeSlots的逻辑。
replaceStaleEntry方法内有两处用到了cleanSomeSlots方法,接下来对其进行介绍:

    //参数i是expungeStaleEntry()方法的返回值,是空桶的位置
    private boolean cleanSomeSlots(int i, int n) {
        boolean removed = false;
        Entry[] tab = table;
        int len = tab.length;
        //循环的逻辑是:从i的下一个位置开始找那些桶不空,但是桶内Entry对应的key=null的元素,
        //然后从这些元素开始向后进行清空。循环的过程中会跳过空桶或者桶内元素的key!=null的桶,
        //循环的次数由n的大小决定,每次将n减半,直到减为0循环结束。
        do {
            i = nextIndex(i, len);
            Entry e = tab[i];
            if (e != null && e.get() == null) {
                n = len;
                removed = true;
                //注意:expungeStaleEntry方法的返回值是第一个空桶的下标,循环的下一次会从这个下标的下一个位置开始遍历
                i = expungeStaleEntry(i);
            }
        } while ( (n >>>= 1) != 0);
        //如果清理了元素,则返回true,否则返回false
        return removed;
    }
  • rehash
    set方法内部最后几行,如果调用cleanSomeSlots没有清理任何桶,并且达到了扩容阈值,就执行扩容逻辑,这段逻辑在rehash方法中,来看看方法的实现逻辑:
    private void rehash() {
        //清理所有的过期桶
        expungeStaleEntries();

        // Use lower threshold for doubling to avoid hysteresis
        //清理过后剩余元素达到threshold的0.75才进行扩容,回忆一下ThreadLocalMap的初始化过程,
        //初始化时threshold=2/3*初始容量,这里在判断是否要扩容时,是以threshold*0.75为标准
        if (size >= threshold - threshold / 4)
            resize();
    }
    //这个方法会从头开始遍历整个数组,每遇到一个ThreadLocal对象被回收的桶,就调用expungeStaleEntry方法向后清理一部分桶
    //与上文讲到的其他清理方法不同,该方法会清理所有的过期数据
    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)
                expungeStaleEntry(j);
        }
    }
    
    //扩容逻辑
    private void resize() {
        Entry[] oldTab = table;
        int oldLen = oldTab.length;
        //注意这里并没有对newLen作限制,也就是说有超限的可能,但是一般肯定不会在线程内放这么多本地变量
        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; // Help the GC
                } else {
                    int h = k.threadLocalHashCode & (newLen - 1);
                    //找到空位置放入元素
                    while (newTab[h] != null)
                        h = nextIndex(h, newLen);
                    newTab[h] = e;
                    count++;
                }
            }
        }

        setThreshold(newLen);
        size = count;
        table = newTab;
    }
  • remove
    最后来看一下ThreadLocalremove方法,方法很简单,主要功能是将当前ThreadLocal对象对应的键值对从数组中删掉,底层逻辑仍然是通过ThreadLocalMapremove实现的:
     public void remove() {
         ThreadLocalMap m = getMap(Thread.currentThread());
         if (m != null)
             m.remove(this);
     }

     private void remove(ThreadLocal<?> key) {
        Entry[] tab = table;
        int len = tab.length;
        //计算key的位置
        int i = key.threadLocalHashCode & (len-1);
        //注意:for循环遇到空桶依然会结束,因此如果需要清理的ThreadLocal对应的键值对在空桶之后,就没法删除
        for (Entry e = tab[i];
             e != null;
             e = tab[i = nextIndex(i, len)]) {
            //如果找到key,则调用Reference类的clear方法,将referent置为null,然后从该位置开始向后清理一部分过期键值对
            if (e.get() == key) {
                e.clear();
                expungeStaleEntry(i);
                return;
            }
        }
    }
    
    //Reference类的clear方法
    public void clear() {
        this.referent = null;
    }

需要注意的是,for循环遇到空桶就结束了,有可能清理不掉对应的键值对。

3.内存泄漏问题

ThreadLocal的底层Entry数组的key是弱引用,意味着当ThreadLocal对象的所有强引用都被去除后,对应的ThreadLocal对象会被回收,此时Entrykey=null,但是value还维持着堆上数据的强引用,只要当前线程不退出,这个强引用会一直存在。为了尽可能缓解这个问题,ThreadLocalgetsetremove方法都会清除一批过期数据,但是从本文的分析可以看出,这种清理只是部分清理,仍然可能遗漏掉部分数据。因此这三个方法只能在一定程度上缓解内存泄漏的问题,并不能避免。另外,如果线程在较长时间内都没有执行上述方法,那过期的数据只会更多。那些在一段时间内都没被清理的过期value对象仍会继续占用内存空间,这些未被清理的对象就是内存泄漏的源头。当然,过期的数据会在线程退出后全部销毁,但是当使用了线程池之后,线程用完会重复利用,并不会被销毁,这种情况下内存泄漏问题就不得不考虑了。因此,好习惯是在ThreadLocal对象用完之后及时使用remove方法进行删除,从而避免内存泄漏问题。

4.疑问总结

  • set方法会不会造成同一个key出现多次呢?
    答案是不会。接下来就来详细讨论一下究竟replaceStaleEntry会不会造成同一个key出现多次的情况。假设重复多次的keyk1,其hash值对应的位置为i,在讲解之前,要明确以下两点:1)要使得k1重复多次,就必然会存在hash冲突,导致k1放到了靠后的位置(否则set方法就能够直接定位到k1了);2)ik1的实际位置i1之间要有空桶(将空桶位置记为j),否则按照上文的分析,代码逻辑也是能够最终定位到k1的。而j位置出现空桶的原因有以下三种:
    • 1)该位置本来就没有存放过键值对。这种情况要排除,因为如果j本来就是空的,k1应该会直接放在j位置。
    • 2)显式调用了remove方法
    • 3)显式将k1指向的ThreadLocal对象赋值为null,后文在进行方法调用的时候自动将j桶清空
      因此只需要考虑后面两种情况即可。如果是显式调用了remove方法清空了j桶,根据remove的逻辑,代码会将i1位置的键值对移动到j位置,后续在使用set方法对k1对应的值进行修改时,由于ij之间没有了空桶,可以定位到k1。因此显式调用remove是不会造成k1重复的。再来看看第三种情况,由于GC清理弱引用导致j位置变成了空桶,其他的方法在做清理时,底层都会调用expungeStaleEntry方法,而这个方法会将i1位置的键值对移动到j位置。综上分析,在ThreadLocalMap中不会出现同一个key出现多次的情况。

5.修改日志

  • 3.13验证同一个key不会在数组中出现多次。
posted @ 2020-03-06 19:58  纳兰小依  阅读(570)  评论(0编辑  收藏  举报