Hello 大家好，我是鸭血粉丝，试用期是每个刚入职的人都会经历的一段时间，时间不固定，少则一两月多则半年，具体的时间长短根据公司和个人表现不尽相同。而且试用期过后一般都会有一个转正答辩，这不阿粉最近就接到一个小伙伴的哭诉说转正答辩太难了，事情是这个样子的。

大家好，我是 ThreadLocal ，昨天阿粉说我动不动就内存泄漏，我蛮委屈的，我才没有冤枉他嘞，证据在这里： ThreadLocal 你怎么动不动就内存泄漏？

因为人家明明也考虑到了很多情况，做了很多事情，保证了如果没有 remove ，也有对 key 值为 null 时进行回收的处理操作

啥？你竟然不信？我 ThreadLocal 难道会骗你么

今天为了证明一下自己，我打算从组成的源码开始讲起，在 get ， set 方法中都有对 key 值为 null 时进行回收的处理操作，先来看 set 方法是怎么做的

set

下面是 set 方法的源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

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 不为空,说明 hash 冲突,需要向后查找
        e != null;
        // 从这里可以看出, ThreadLocalMap 采用的是开放地址法解决的 hash 冲突
        // 是最经典的 线性探测法 --> 我觉得之所以选择这种方法解决冲突时因为数据量不大
        e = tab[i = nextIndex(i, len)]) {
        ThreadLocal<?> k = e.get();

        // 要查找的 ThreadLocal 对象找到了,直接设置需要设置的值,然后 return
        if (k == key) {
            e.value = value;
            return;
        }

        // 如果 k 为 null ,说明有 value 没有及时回收,此时通过 replaceStaleEntry 进行处理
        // replaceStaleEntry 具体内容等下分析
        if (k == null) {
            replaceStaleEntry(key, value, i);
            return;
        }
    }

    // 如果 tab[i] == null ,则直接创建新的 entry 即可
    tab[i] = new Entry(key, value);
    int sz = ++size;
    // 在创建之后调用 cleanSomeSlots 方法检查是否有 value 值没有及时回收
    // 如果 sz >= threshold ,则需要扩容,重新 hash 即, rehash();
    if (!cleanSomeSlots(i, sz) && sz >= threshold)
        rehash();
}

通过源码可以看到，在 set 方法中，主要是通过 replaceStaleEntry 方法和 cleanSomeSlots 方法去做的检测和处理

接下来瞅瞅 replaceStaleEntry 都干了点儿啥

replaceStaleEntry

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

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

    // 从当前 staleSlot 位置开始向前遍历
    int slotToExpunge = staleSlot;
    for (int i = prevIndex(staleSlot, len);
        (e = tab[i]) != null;
        i = prevIndex(i, len))
        if (e.get() == null)
            // 当 e.get() == null 时, slotToExpunge 记录下此时的 i 值
            // 即 slotToExpunge 记录的是 staleSlot 左手边第一个空的 Entry
            slotToExpunge = i;

    // 接下来从当前 staleSlot 位置向后遍历
    // 这两个遍历是为了清理在左边遇到的第一个空的 entry 到右边的第一个空的 entry 之间所有过期的对象
    // 但是如果在向后遍历过程中,找到了需要设置值的 key ,就开始清理,不会再继续向下遍历
    for (int i = nextIndex(staleSlot, len);
        (e = tab[i]) != null;
        i = nextIndex(i, len)) {
        ThreadLocal<?> k = e.get();

        // 如果 k == key 说明在插入之前就已经有相同的 key 值存在,所以需要替换旧的值
        // 同时和前面过期的对象进行交换位置
        if (k == key) {
            e.value = value;

            tab[i] = tab[staleSlot];
            tab[staleSlot] = e;

            // 如果 slotToExpunge == staleSlot 说明向前遍历时没有找到过期的
            if (slotToExpunge == staleSlot)
                slotToExpunge = i;
            // 进行清理过期数据
            cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
            return;
        }

        // 如果在向后遍历时,没有找到 value 被回收的 Entry 对象
        // 且刚开始 staleSlot 的 key 为空,那么它本身就是需要设置 value 的 Entry 对象
        // 此时不涉及到清理
        if (k == null && slotToExpunge == staleSlot)
            slotToExpunge = i;
    }

    // 如果 key 在数组中找不到,那就好说了,直接创建一个新的就可以了
    tab[staleSlot].value = null;
    tab[staleSlot] = new Entry(key, value);

    // 如果 slotToExpunge != staleSlot 说明存在过期的对象,就需要进行清理
    if (slotToExpunge != staleSlot)
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
}

在 replaceStaleEntry 方法中,需要注意一下刚开始的两个 for 循环中内容（在这里再贴一下）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

if (e.get() == null)
    // 当 e.get() == null 时, slotToExpunge 记录下此时的 i 值
    // 即 slotToExpunge 记录的是 staleSlot 左手边第一个空的 Entry
    slotToExpunge = i;

if (k == key) {
    e.value = value;

    tab[i] = tab[staleSlot];
    tab[staleSlot] = e;
                                        
    // 如果 slotToExpunge == staleSlot 说明向前遍历时没有找到过期的
    if (slotToExpunge == staleSlot)
        slotToExpunge = i;
        // 进行清理过期数据
        cleanSomeSlots(expungeStaleEntry(slotToExpunge), len);
        return;
}

这两个 for 循环中的 if 到底是在做什么？

看第一个 if ，当 e.get() == null 时，此时将 i 的值给 slotToExpunge

第二个 if ，当 k ==key 时，此时将 i 给了 staleSlot 来进行交换

为什么要对 staleSlot 进行交换呢？画图说明一下

如下图，假设此时表长为 10 ，其中下标为 3 和 5 的 key 已经被回收（ key 被回收掉的就是 null ），因为采用的开放地址法，所以 15 mod 10 应该是 5 ，但是因为位置被占，所以在 6 的位置，同样 25 mod 10 也应该是 5 ，但是因为位置被占，下个位置也被占，所以就在第 7 号的位置上了

按照上面的分析，此时 slotToExpunge 值为 3 ， staleSlot 值为 5 ， i 为 6

假设，假设这个时候如果不进行交换，而是直接回收的话，此时位置为 5 的数据就被回收掉，然后接下来要插入一个 key 为 15 的数据，此时 15 mod 10 算出来是 5 ，正好这个时候位置为 5 的被回收完毕，这个位置就被空出来了，那么此时就会这样：

同样的 key 值竟然出现了两次？！

这肯定是不希望看到的结果，所以一定要进行数据交换

在上面代码中有一行代码 cleanSomeSlots(expungeStaleEntry(slotToExpunge), len); ，说明接下来的处理是交给了 expungeStaleEntry ，接下来去分析一下 expungeStaleEntry

expungeStaleEntry

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

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

    // expunge entry at staleSlot
    tab[staleSlot].value = null;
    tab[staleSlot] = null;
    size--;

    // Rehash until we encounter null
    Entry e;
    int i;
    for (i = nextIndex(staleSlot, len);
        (e = tab[i]) != null;
        i = nextIndex(i, len)) {
        ThreadLocal<?> k = e.get();
        // 如果 k == null ,说明 value 就应该被回收掉
        if (k == null) {
            // 此时直接将 e.value 置为 null 
            // 这样就将 thread -> threadLocalMap -> value 这条引用链给打破
            // 方便了 GC
            e.value = null;
            tab[i] = null;
            size--;
        } else {
            // 这个时候要重新 hash ,因为采用的是开放地址法,所以可以理解为就是将后面的元素向前移动
            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.
                while (tab[h] != null)
                    h = nextIndex(h, len);
                tab[h] = e;
            }
        }
    }
    return i;
}

因为是在 replaceStaleEntry 方法中调用的此方法，传进来的值是 staleSlot ，继续上图，经过 replaceStaleEntry 之后，它的数据结构是这样：

此时传进来的 staleSlot 值为 6 ，因为此时的 key 为 null ，所以接下来会走 e.value = null ，这一步结束之后，就成了：

接下来 i 为 7 ，此时的 key 不为 null ，那么就会重新 hash : int h = k.threadLocalHashCode & (len - 1); ，得到的 h 应该是 5 ，但是实际上 i 为 7 ，说明出现了 hash 冲突，就会继续向下走，最终的结果是这样：

可以看到，原来的 key 为 null ，值为 V5 的已经被回收掉了。我认为之所以回收掉之后，还要再次进行重新 hash ，就是为了防止 key 值重复插入情况的发生

假设 key 为 25 的并没有进行向前移动，也就是它还在位置 7 ，位置 6 是空的，再插入一个 key 为 25 ，经过 hash 应该在位置 5 ，但是有数据了，那就向下走，到了位置 6 ，诶，竟然是空的，赶紧插进去，这不就又造成了上面说到的问题，同样的一个 key 竟然出现了两次？！

而且经过 expungeStaleEntry 之后，将 key 为 null 的值，也设置为了 null ，这样就方便 GC

分析到这里应该就比较明确了，在 expungeStaleEntry 中，有些地方是帮助 GC 的，而通过源码能够发现， set 方法调用了该方法进行了 GC 处理， get 方法也有，不信你瞅瞅：

get

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

private Entry getEntry(ThreadLocal<?> key) {
    int i = key.threadLocalHashCode & (table.length - 1);
    Entry e = table[i];
    // 如果能够找到寻找的值,直接 return 即可
    if (e != null && e.get() == key)
        return e;
    else
        // 如果找不到,则调用 getEntryAfterMiss 方法去处理
        return getEntryAfterMiss(key, i, e);
}

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

    // 一直探测寻找下一个元素,直到找到的元素是要找的
    while (e != null) {
        ThreadLocal<?> k = e.get();
        if (k == key)
            return e;
        if (k == null)
            // 如果 k == null 说明有 value 没有及时回收
            // 调用 expungeStaleEntry 方法去处理,帮助 GC
            expungeStaleEntry(i);
        else
            i = nextIndex(i, len);
        e = tab[i];
    }
    return null;
}

get 和 set 方法都有进行帮助 GC ，所以正常情况下是不会有内存溢出的，但是如果创建了之后一直没有调用 get 或者 set 方法，还是有可能会内存溢出

所以最保险的方法就是，使用完之后就及时 remove 一下，加快垃圾回收，就完美的避免了垃圾回收

我 ThreadLocal 虽然没办法做到 100% 的解决内存泄漏问题，但是我能做到 80% 不也应该夸夸我嘛

如果说 ThreadLocal 的话，那肯定就会涉及到内存泄漏，为啥嘞

因为 吧啦吧啦 ~

ThreadLocal 解决了什么问题呢？

它是为了解决对象不能被多线程共享访问的问题，通过 threadLocal.set() 方法将对象实例保存在每个线程自己所拥有的 threadLocalMap 中，这样的话每个线程都使用自己的对象实例，彼此不会影响从而达到了隔离的作用，这样就解决了对象在被共享访问时带来的线程安全问题

啥意思呢？打个比方，现在公司所有人都要填写一个表格，但是只有一支笔，这个时候就只能上个人用完了之后，下个人才可以使用，为了保证”笔”这个资源的可用性，只需要保证在接下来每个人的获取顺序就可以了，这就是 lock 的作用，当这支笔被别人用的时候，我就加 lock ，你来了那就进入队列排队等待获取资源（非公平方式那就另外说了），这支笔用完之后就释放 lock ，然后按照顺序给下个人使用

但是完全可以一个人一支笔对不对，这样的话，你填写你的表格，我填写我的表格，咱俩谁都不耽搁谁。这就是 ThreadLocal 在做的事情，因为每个 Thread 都有一个副本，就不存在资源竞争，所以也就不需要加锁，这不就是拿空间去换了时间嘛

在开始之前，咱们先把 Thread， ThreadLocal， ThreadLocalMap 的关系捋一捋：

可以看到，在 Thread 中持有一个 ThreadLocalMap ， ThreadLocalMap 又是由 Entry 来组成的，在 Entry 里面有 ThreadLocal 和 value

ThreadLocal 为啥动不动就内存泄漏呢？

在这里先给个解释，后面咱们再详细分析：

首先是因为 ThreadLocal 是基于 ThreadLocalMap 实现的，其中 ThreadLocalMap 的 Entry 继承了 WeakReference ，而 Entry 对象中的 key 使用了 WeakReference 封装，也就是说， Entry 中的 key 是一个弱引用类型，对于弱引用来说，它只能存活到下次 GC 之前

如果此时一个线程调用了 ThreadLocalMap 的 set 设置变量，当前的 ThreadLocalMap 就会新增一条记录，但由于发生了一次垃圾回收，这样就会造成一个结果: key 值被回收掉了，但是 value 值还在内存中，而且如果线程一直存在的话，那么它的 value 值就会一直存在

这样被垃圾回收掉的 key 就会一直存在一条引用链: Thread -> ThreadLocalMap -> Entry -> Value :

就是因为这条引用链的存在，就会导致如果 Thread 还在运行，那么 Entry 不会被回收，进而 value 也不会被回收掉，但是 Entry 里面的 key 值已经被回收掉了

这只是一个线程，如果再来一个线程，又来一个线程…多了之后就会造成内存泄漏

知道是怎么造成内存泄漏之后，接下来要做的事情就好说了，不是因为 value 值没有被回收掉所以才会导致内存泄露的嘛

那使用完 key 值之后，将 value 值通过 remove 方法 remove 掉，这样的话内存中就不会有 value 值了，也就防止了内存泄漏嘛

ThreadLocal 是基于 ThreadLocalMap 实现的？

OK ，上面的内容讲完了，接下来一一来看

首先，你怎么知道 ThreadLocal 是基于 ThreadLocalMap 实现的呢？

从源码知道的~

在源码中能够看到下面这几行代码：

1
2
3
4
5
6
7
8
9
10
11
12
13

public class ThreadLocal<T> {
    static class ThreadLocalMap {
        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
    }
}

代码中说的很清楚了，在 ThreadLocal 内部维护着 ThreadLocalMap ，而它的 Entry 则继承自 WeakReference 的 ThreadLocal<?> ，其中 Entry 的 k 为 ThreadLocal ， v 为 Object ，在调用 super(k) 时就将 ThreadLocal 实例包装成了一个 WeakReference

强弱引用这块内容阿粉就直接放一个表格吧：

从表格中应该能够看出来，弱引用的对象只要发生垃圾收集事件，就会被回收

所以弱引用的存活时间也就是下次 GC 之前了

在这里阿粉就有个问题想问问了：为什么 ThreadLocal 采用弱引用，而不是强引用嘞？

在 ThreadLocalMap 上面有些注释，我在这里摘录一部分，或许可以从中窥探一二：

To help deal with very large and long-lived usages， the hash table entries use WeakReferences for keys

翻译一下就是:（虽然我英语不是很好

为了解决非常大且长期使用的问题，哈希表使用了弱引用的 key

假设，假设， ThreadLocal 使用的是强引用，会怎样呢？

如果是强引用的话，在表格中也能够看出来，被强引用关联的对象，永远都不会被垃圾回收器回收掉

如果引用的 ThreadLocal 对象被回收了，但是 ThreadLocalMap 还持有对 ThreadLocal 的强引用，如果没有 remove 的话， 在 GC 时进行可达性分析， ThreadLocal 依然可达，这样就不会对 ThreadLocal 进行回收，但是我们期望的是引用的 ThreadLocal 对象被回收，这样不就达不到目的了嘛

使用弱引用的话，虽然会出现内存泄漏的问题，但是在 ThreadLocal 生命周期里面，都有对 key 值为 null 时进行回收的处理操作

所以，使用弱引用的话，可以在 ThreadLocal 生命周期中尽可能保证不出现内存泄漏的问题

啥？在 ThreadLcoal 生命周期里面，都有对 key 值为 null 时进行回收的处理操作？有证据么？

那必须得有证据，毕竟阿粉可是个负责任的博主，不过阿粉考虑到这篇文章内容已经是比较多的了，所以下篇文章阿粉再带你进行源码分析好不好

乖~

阿粉最近刚刚入职了新公司，结果不曾想，差点就被公司开除，一个删除的操作，把表给粉碎的彻彻底底的，得亏了是在测试服务器上，虽然测试服务器，也算是有了备份，但是还是被领导diss了一波，那么我们在刚入职需要做些什么准备才能不会被公司疯狂的diss。

<–more–>

技术是第一生产力

都说程序员在公司混，全凭技术说话，不知道大家最近有没有看一个新闻，网易内部倡导用昵称代替“哥、姐、总”等称呼，大家对这个新闻有什么感想的呢？

在程序员里面，就分成了大佬-小弟，大佬肯定就是那种各种技术各种牛逼的人，而小弟肯定就是什么都不会，凡事都要去问大佬的人，一般嘴甜的都会叫个哥什么的，但是这种情况在程序员行业不足为奇，毕竟技术牛逼的都会让人佩服，而我们能做的就是把所有的之前能拿出来的水准一定麻溜的展示出来，不然你在公司会成为他们茶余饭后的小笑话。

尽快的熟悉业务

之前也有刚刚步入这个行业的初级程序员问过阿粉，说我现在入职之后，最开始需要干什么，阿粉给他提出的建议就是，抓紧熟悉业务，把公司的业务完整的拿下来，至少有个需求来了，你能分分钟知道在那些地方加功能，在哪里修改逻辑。

阿粉在刚开始入职的时候，曾经入职过一家公司，一个非常非常小的公司，开发加起来一共就6个人，招人的要求却很高，要求你前后端都得会，重点来了，一般刚入职的程序员很多都是从后端程序开始做的，对于前段的页面，CSS 什么的压根都不接触，忽然给你一个图片，说把这个做出来，那时候的阿粉瞬间蒙了，都不知道该怎么办了，花了一上午的时间，写了一个很low的页面，而中间有一个搞业务的顺嘴说了一句，你说着让你写个页面这么难么？阿粉的年轻让自己付出了惨重的代价，直接就提辞职了，顺便说了可能达不到公司的要求，第二天直接就走人了。

而从这次之后，阿粉明白了，去公司第一件事就是赶紧去熟悉公司的业务，而且面对那些特别小型的公司，还没有正规的开发流程的公司，真心去不得，去了会让自己身心及其压抑。

这种压抑你呆久了，会让自己感觉到倍感打击，所以阿粉这次在跳槽之后的第一件事就是把公司的项目跑起来，能看文档的就看文档，能问问题的就问问题，和我交接的那个人还行，还算不错，很多东西都给我交接的听明白的，阿粉也不再是当初的新人了，在第二天的时候，已经感觉自己能在公司的项目上修修改改了，毕竟看着写的比较头大的代码，有点忍不住想去给他改改。

情商也是非常非常重要的一件事

阿粉在入职之后还在想，为什么没有新员工的培训呢？毕竟现在的公司也不算是小公司了，在阿粉提出疑问的时候，阿粉的领导说的是，在入职一个月之后才会有员工培训，中间会让你学习一些公司的规章制度，然后在让给你灌输一些思想，这些东西在程序员眼中可能都是“垃圾”，但是这些东西，其实在你以后是非常需要的，在一个公司最容易混熟的是什么人，就是刚刚和你一起入职的新人，让你熟悉，并不是让你搞小团体。

你初来乍到，首先需要熟悉的是代码，但是在熟悉代码的同时，还有一件事也是需要你做得，那就是和产品沟通需求，你和产品沟通好了，那么需求明确了才能完整的开发。

不知道大家看过阿里巴巴网红美女产品经理又玄么？那个在台上被嘉宾怼得体无完肤，但是她在实际中却是实实在在的学霸，而且提出的要求也没有那种“根据心情，变换壁纸的，根据手机壳，变换壁纸的操作”。比如说，阿里全园区供26万阿里人使用的人脸门禁，阿里的网红级产品未来餐厅识别系统等这些都是她的杰作。

程序员眼中的产品经理：我们程序员忙着用技术添砖加瓦，啥技术都不懂的产品经理忙着给我们添堵，看我们哪儿都不好。

就算是忙着添堵，那我们也一定要和产品经理搞好关系，这对你未来的开发是非常有帮助，防止以后给你一句话就是一个需求的这种情况。

而怎么才能更好的融入团队？

眼里有活

先不说你之后在公司会有什么摸鱼的情况，但是在最开始融入团队的最好方法一定是给自己找活，功能做的又快又好，试问，什么样子的小领导不希望自己手下的人干活麻利。

有问题该怎么问？

阿粉认为，在刚开始入职的时候，千万不要有什么问题就对其他员工发出提问，不然这时候你会发现，用不了几天，就会有人diss你，这时候你需要做的是 ：

百度

Google

看文档

发出提问

为什么我会把发出提问放在最后边呢，因为刚开始的时候，千万不要什么问题都去提问，而是经过自己的思考和考虑之后，自己如果真的对业务上的问题解决不了的话，那么再去发文，我当初的推荐就是加班，而现在阿粉做的依旧是入职开始加班熟悉业务，不会的问题赶紧百度，发出提问的时候，很多都是业务上的问题，而不是技术上的问题，这时候，你就会发现，他们很多时候是很乐意和你沟通的，而你频繁的发出提问，那么就会让别人觉得，你这技术废物，是怎么被召进来的。

所以，问问题的时候是需要技巧的，而你学会把握这些技巧之后，你就会在入职之后就不会出现被公司其他的同时diss，而且也不会因为自己不适应公司被迫的离开刚入职的公司。

学会控制自己

为什么阿粉会在这里给大家说要学会控制自己呢？之前的案例已经说明了，如果你不控制自己，直接就按照自己的想法办事，遇到个不会的，也不加班，就开始和领导顶撞，那可能自己很快就会辞职。

当我们新入职一个公司的时候，对这个公司的环境和业务并不是特别熟悉的时候，我们在问完问题，老员工和领导给你提出建议的时候，虚心接受，而他们有时候也会给你分享一些工作中的经验，产生分歧的时候，尤其是技术，这块内容，最好虚心接受，不然你会发现你会被慢慢的疏远，就像下面。

而阿粉给大家的建议就这些了，你想不想换个公司呢？想的话就赶紧准备面试题把，关注公众号，回复面试题，即可获取精心准备的面试题一份呦。

最近几天一直在改造工程，采用雪花算法生成主键ID，突然踩到一个天坑，前端 JavaScript 在取 Long 型参数时，参数值有点不太对！

Hello 大家好，我是阿粉，前面的文章给大家介绍过 Nacos，用于服务注册发现和管理配置的开源组件，今天给大家分享另一个组件 Consul 也有相应的功能，我们一起来看一下吧！

阿粉第一次了解到io相关知识是在网上看面经的时候，平时只会写业务代码，面对bio，nio，多路复用器这些概念简直是一头雾水。

当阿粉尝试单独去学习这些名词，发现很难学懂，如果能有一篇文章串起来讲讲他们的关系，可能对初学者来说有一定的帮助，所以便有了下面这篇文章。

BIO

BIO即为阻塞IO的意思，通常我们讲BIO的时候都会和服务器模型配合着讲，在实际应用中讲会更好理解。大家看下面的代码，估计在大家初学java网络编程的时候用的都是这个模型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

public static void main(String[] args) throws Exception {
    //建立socket，socket是客户端和服务器沟通的桥梁
    ServerSocket server = new ServerSocket(9090,20);
    
    //通过死循环不断接收客户端请求
    while (true) {
        //线程会阻塞在这行的accep方法
        Socket client = server.accept(); 
        //创建新线程处理新客户端的逻辑
        new Thread(() -> {
                
            //client的读写逻辑

        }).start();
    }
}

只要没有客户端连接上服务器，accept方法就一直不能返回，这就是阻塞；对应的读写操作道理也一样，想要读取数据，必须等到有数据到达才能返回，这就是阻塞。

我们还可以站在阻塞的基础上思考一下，为什么服务器的模型要设计成来一个客户端就新建一个线程？

其实答案很简单，当来了一个客户端创建连接后，如果不给客户端新分配一个线程执行服务器逻辑，那么服务端将很难再和第二个客户端建立连接。

就算你把客户端连接用集合保存起来，通过单线程遍历集合的方式去执行服务器端逻辑也是不行的。因为如果某个客户端连接因为读写操作阻塞了，那么其他客户端将得不到执行。

NIO

如果说服务器只有很少的人用，那么上面那段bio的代码其实挺好的，但问题在于互联网蓬勃发展，随着服务器访问认数的增加，这样的服务器模型将会成为瓶颈。

我们以一种C10K的思想去看代上面这段服务器代码。如果我们客户端的连接数增加了10K倍，那么就意味着要创建10k个线程，单单创建线程就是一项不小的开销了，再加上线程之间要来回切换，单机服务器根本就扛不住这么大的连接数。

那既然瓶颈是出在线程上，我们就考虑能不能把服务器的模型变为单线程模型，思路其实和之前说的差不多，用集合保存每个连接的客户端，通过while循环来对每个连接进行操作。

之前我们说了这样的操作瓶颈在于accept客户端的时候会阻塞，以及进行读写操作的时候会阻塞，导致单线程执行效率低。为了突破这个瓶颈，操作系统发展出了nio，这里的nio指的是非阻塞io。

也就是说在accept客户端连接的时候，不需要阻塞，如果没有客户端连接就返回-1（java-NULL），在读写操作的时候，也不阻塞，有数据就读，没数据就直接返回，这样就解决了单线程服务器的瓶颈问题。示例代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public static void main(String[] args) throws Exception {
    //用于存储客户端的集合
    LinkedList<SocketChannel> clients = new LinkedList<>();
    //nio里概念改成了channel
    ServerSocketChannel ss = ServerSocketChannel.open();
    ss.bind(new InetSocketAddress(9090));
    //设置成非阻塞
    ss.configureBlocking(false);

    while (true) {
        //下面的accept方法不会阻塞
        SocketChannel client = ss.accept();

        if (client == null) {
            System.out.println("null.....");
            
        } else {
            //设置客户端操作也为非阻塞
            client.configureBlocking(false); 
            clients.add(client);
        }

        ByteBuffer buffer = ByteBuffer.allocateDirect(4096);

        //遍历已经链接进来的客户端能不能读写数据
        for (SocketChannel c : clients) {
            int num = c.read(buffer);
            if (num > 0) {
                //其他操作
            }
        }
    }
}

多路复用器

尽管上面的单线程NIO服务器模型比BIO的优良许多，但是仍然有一个大问题。在客户端与服务器建立连接后，后续会进行一系列的读写操作。虽然这些读写操作是非阻塞的，但是每调一次读写操作在操作系统层面都要进行一次用户态和内核态的切换，这个也是一项巨大的开销（读写等系统调用都是在内核态完成的）。

在上面的代码中每次循环遍历都进行读写操作，我们以读操作为例：大部分读操作都是在数据没有准备好的情况下进行读的，相当于执行了一次空操作。我们要想办法避免这种无效的读取操作，避免内核态和用户态之间的频繁切换。

补充： 客户端与服务器两端都是通过socket进行连接的，socket在linux操作系统中有对应的文件描述符，我们的读写操作都是以该文件描述符为单位进行操作的。

为了避免上述的无效读写，我们得想办法得知当前的文件描述符是否可读可写。如果逐个文件描述符去询问，那么效率就和直接进行读写操作差不多了，我们希望有一种方法能够一次性得知哪些文件描述符可读，哪些文件描述符可写，这，就操作系统后来发展出的多路复用器。

也就是说，多路复用器的核心功能就是告诉我们哪些文件描述符可读，哪些文件描述符可写。而多路复用器也分为几种，他们也经历了一个演化的过程。最初的多路复用器是select模型，它的模式是这样的：程序端每次把文件描述符集合交给select的系统调用，select遍历每个文件描述符后返回那些可以操作的文件描述符，然后程序对可以操作的文件描述符进行读写。

它的弊端是，一次传输的文件描述符集合有限，只能给出1024个文件描述符，poll在此基础上进行了改进，没有了文件描述符数量的限制。

但是select和poll在性能上还可以优化，它们共同的弊端在于：

1. 它们需要在内核中对所有传入的文件描述符进行遍历，这也是一项比较耗时的操作
2. （这点是否存在优化空间有待考证）每次要把文件描述符从用户态的内存搬运到内核态的内存，遍历完成后再搬回去，这个来回复制也是一项耗时的操纵。

后来操作系统加入了epoll这个多路复用器，彻底解决了这个问题：

epoll多路复用器的模型是这样的：

为了在发起系统调用的时候不遍历所有的文件描述符，epoll的优化在于：当数据到达网卡的时候，会触发中断，正常情况下cpu会把相应的数据复制到内存中，和相关的文件描述符进行绑定。epoll在这个基础之上做了延伸，epoll首先是在内核中维护了一个红黑树，以及一些链表结构，当数据到达网卡拷贝到内存时会把相应的文件描述符从红黑树中拷贝到链表中，这样链表存储的就是已经有数据到达的文件描述符，这样当程序调用epoll_wait的时候就能直接把能读的文件描述符返回给应用程序。

除了epoll_wait之外，epoll还有两个系统调用，分别是epoll_create和epoll_ctl，分别用于初始化epoll和把文件描述符添加到红黑树中。

以上就是多路复用器与常见io模型的关系了，网上常常有文章把多路复用器说成是nio的一部分，我觉得也是合理的，因为在具体编程的时候两个概念往往会融为一体。

后续

其实Java已经为我们把多路复用器用Selector类给封装起来了，我们完全可以基于Selector进行NIO服务器开发。但是我们自己写nio服务器可能不够严谨，Java届有一款优秀nio框架，名叫Netty，这部分内容我们留到下一次再讲啦。

在实际项目中，经常需要用到角色权限区分，以此来为不同的角色赋予不同的权利，分配不同的任务。比如，普通用户只能浏览；会员可以浏览和评论；超级会员可以浏览、评论和看视频课等；实际应用场景很多。毫不夸张的说，几乎每个完整的项目都会设计到权限管理。

因此，这篇文章，阿粉就带大家将 shiro 权限框架整合到 SpringBoot 中，以达到快速的实现权限管理的功能。

Hello 大家好，我是阿粉，今天给大家分享微服务环境下必须要使用的一个强大的组件 Nacos。自从使用了 Nacos，阿粉的服务再也没有担心过服务注册和发现以及配置管理混乱的问题了。

日常编程中，我们会经常会碰到对象属性复制的场景，就比如下面这样一个常见的三层 MVC 架构。

hello~各位读者好，我是鸭血粉丝（大家可以称呼我为「阿粉」）。今天，阿粉带着大家来了解一下 ReentrantLock 锁的非公平锁的实现原理

1.锁

java中,加锁的方式

1
2

1. synchronized，这个是 java 底层实现的,也就是 C 语言实现的。
 	2. lock，这个是 java.util.concurrent 包下面的，是 java语言实现的。

2.ReentrantLock

ReentrantLock 是 Lock 的一种实现，是一种可重入的公平或非公平锁。默认是非公平锁。

2.1 Lock的创建

首先看下锁的创建和使用代码：

1
2
3
4
5
6

//创建锁
Lock lock  = new ReentrantLock();
//加锁
lock.lock();
//释放锁
lock.unlock();

然后看下创建的是 ReentrantLock 的构造函数：

1
2
3

public ReentrantLock() {
    sync = new NonfairSync();
}

NonfairSync 就是非公平锁。所以 ReentrantLock 默认是非公平锁的实现

2.2 lock()

加锁的逻辑就比较复杂了，因为存在线程竞争。所以有两种情况，一种是竞争到锁的处理，一种是没有竞争到锁的处理。

首先我们还是来看下 lock() 方法，因为最终是非公平的实现，所以直接看 NonfairSync 里面的 lock 方法。

1
2
3
4
5
6

final void lock() {
    if (compareAndSetState(0, 1))
        setExclusiveOwnerThread(Thread.currentThread());
    else
        acquire(1);
}

2.3 没有获取到锁的逻辑 acquire()

直接上代码：

1
2
3
4
5

public final void acquire(int arg) {
    if (!tryAcquire(arg) &&
        acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
        selfInterrupt();
}

还是3个方法，阿粉一个一个的说。

1. tryAcquire(arg) ，还是先看代码在分析。

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

   final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; }

   a. 获取 state ，如果等于0，说明之前获得锁的线程已经释放了，那么这个线程就会再次去竞争锁，这就是非公平锁的体现，如果是公平锁，是没有这个判断的。

   b. 如果前一个获得锁的线程没有释放锁，那么就判断是否是同一个线程，是的话就会将 state 加 1。这个就是重入锁的体现。

   c. 如果都不满足,那么返回 false。

2. acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) ,再次获取锁没有成功,并且又不是可重入锁,那么就存入一个阻塞队列里面。里面还有一点逻辑，就不展开了，有兴趣可以自己看下。

3. selfInterrupt(); 这个是当前线程的中断标志，作用就是在线程在阻塞的是否，客户端通过调用了中断线程的方法 interrupt()，那么该线程被唤醒的时候，就会有响应的处理。具体要看这个线程 run 方法里面的代码逻辑。

2.4 unlock()

1
2
3
4
5
6
7
8
9
10
11
12

protected final boolean tryRelease(int releases) {
    int c = getState() - releases;
    if (Thread.currentThread() != getExclusiveOwnerThread())
        throw new IllegalMonitorStateException();
    boolean free = false;
    if (c == 0) {
        free = true;
        setExclusiveOwnerThread(null);
    }
    setState(c);
    return free;
}

释放锁的步骤

1. state - 1,如果大于0，说明释放的是重入锁，只需要修改 state 就行了
2. 如果等于0，说明要释放锁，释放锁首先需要把独占线程设置为null，再把state设置为0。

3 总结

Lock 锁的实现：

1. 互斥性：需要一个状态来判断是否竞争到锁： state 并且需要用 volatile修饰，保证线程之间的可见性。

2. 可重入性：Thread exclusiveOwnerThread 这个成员变量来记录当前获得锁的线程。

3. 公平或非公平：默认非公平，NonfairSync。

4. 没有竞争到锁的线程怎么办？放到队列中。

5. 没有竞争到锁的线程怎么释放CPU？park：阻塞线程释放CPU资源，这个操作在 acquireQueued()，阿粉没没有讲这个。

6. 最后来张流程图：

   

我相信各位读者朋友们，最近一定或多或少的听过投资这件事，阿粉也有些话想要和你唠唠，特别是关于基金定投这件事

互联网这个行业，忙起来的时候说是没有白天没有黑夜一点儿都不为过。没有时间去研读财报，没有时间去做分析，那么，最简单快捷的方法就是研究一下基金定投。

关于基金定投，阿粉还是有些经验的，今天来分享下（要自己挖自己的黑历史了

1， 对于投资，不要 all in

阿粉刚开始投资的时候，什么都不懂，把自己当时手里面的钱全都投进去了，想着反正自己也是一单身狗嘛，平时也没啥支出，干脆都投进去得了（说到这里我的眼角就湿了

结果后来因为一些事情需要用钱，我所有的钱又都在基金里面，那个时候我的基金还没盈利，没办法只能忍痛割肉，想着等回来再有钱了重新定投就行了。

结果，还没等阿粉重新开始定投，原来买的基金蹭蹭的开始涨！！！（我的眼角又开始湿了

当时就很后悔，那段时间阿粉就总是想，如果自己当时定投的时候，拿出一部分钱去做，虽然赚的会少点儿，但是起码我还能有得赚，不至于因为用钱不得不在赔的时候抛出。

自从那次教训之后，阿粉就学聪明了嘛，永远都给自己留条后路~

2， 如果想要定投，做好长期持有的准备

大家肯定都知道，做定投相对股票来说是比较容易赚钱的，但是就算如此也还是会有人赔钱。

阿粉觉得大概率就是这些人持有的时间太短（前提是，你持有的基金是优质基金）

基金不适合短期频繁操作，它适合长期持有。第一是因为基金在短期内是有涨幅的，也就是今天可能会跌，明天可能会涨，但是从长期来看，基金的整个趋势是上涨的，所以如果想要定投基金的话，一定要做好长期持有的准备，我觉得这个年限可以是 3 年。如果持有一个基金， 3 年它还没有盈利，那真的可以考虑要不要继续持有了。

第二是因为，基金如果在短期内卖出的话，会有比较高的卖出率，但是如果是长期持有，就没有卖出率这一说

做好长期持有的准备，还有一个潜台词就是，做基金定投的钱，在长期内是不能动的。

或者可以这样认为，做基金定投的钱，你就当你从来都没有过这笔钱就好了，如果在此基础上，你的生活还不受影响的话，那这个做投资的钱，就是适合你的（这样比喻，我可真是个机智的崽崽

3， 别管别人怎样，要保持一个让自己舒服的仓位

每个人能够承受的风险不一样，所以不要看别人持有了多少的仓位，不要看别人买了多少多少的资金。

阿粉这个人还算是比较能够承受风险的，做基金定投的钱就是都赔光了，我也最多难受那么几秒钟。因为这些钱对我来说，不是很能影响我的生活质量，所以哪怕都赔光了，说不心疼是假的，但是起码我都可以接受，不会因为赔了 10%, 20% 就整天睡不着这种（阿粉吹个牛逼还不行…赔钱这事儿，怎么可能睡得着觉！！！

那么，如果你承受的风险能力比较弱，别说赔 10%, 20% 了，就是赔 5% 都心疼的不行，那就赶紧做一些动作，让自己舒服。

做投资只是让你的生活变得更好一些，但是如果因为这样导致自己睡不着，吃不好，我觉得是得不偿失，还不如卖出一些，保持一个让自己舒服的仓位。

毕竟，人生这么短暂，舒服最重要不是~

4， 关于投资这件事，你学多少知识，花多少时间都不为过

我有一点想不明白，就是大多数人在买东西的时候，都会货比三家，特别是女生买化妆品的时候，一定会挑好久好久。但是等到买基金，做投资的时候，却是想都不想跟着市面上那些所谓的“投资大师”们走。

就让我觉得，难道定投的钱，不是自己挣的钱嘛？买东西的时候，那么谨慎，怎么一到做投资的时候，就那么草率呢。

不要信市场上那些所谓的”投资大师”们的话，如果真的赚钱的话，没有人告诉你的。就算告诉，也是告诉自己的亲人，朋友这种，你和对方是什么关系，人家凭什么把赚钱这件事情交给你。

而且，一些投资方法如果真的公布出来，真的就没办法赚钱了，比如网格策略，如果公布出来，到最后可能大家都没得赚。

所以，不要相信任何人给你的投资建议。

要有自己的判断，这就需要你去学习投资相关的知识，比如什么是沪深 300 ，中证 500 ，什么是红利等等等等。在这上面学多少知识，花多少时间都不为过。

5， 要学会关注趋势

市场很大一部分都是受趋势影响的。

记得前段时间，网上有个段子：本来想定投基金赚一把，结果没想到天天拉着我见证历史。

学会关注趋势，关注国家大势。不是有句话说，站在风口上，猪都能飞起来。

怎么找风口呢?不关注趋势，就想找到正确的风口，想破头皮可能也想不到一个方向吧~

就算是股神巴菲特，也还保持着每天看报纸，分析趋势呢，更别说咱们这些普通人了。

不要问阿粉为啥有这么多经验分享，因为问着问着阿粉的眼泪就流下来了

在面试的时候都会被问到集合相关的问题，比如：你能讲讲 ArrayList 和 LinkedList 的区别吗？

那么我相信你肯定能够答上来： ArrayList 是基于数组实现的， LinkedList 是基于链表实现的

接下来面试官就会连环问了，那你能讲讲，它们都用在什么场景下吗？

阿粉知道这种程度肯定难不倒咱们读者的：因为 ArrayList 是基于数组实现的，所以在遍历的时候， ArrayList 的效率是要比 LinkedList 高的， LinkedList 是基于链表实现的，所以在进行新增/删除元素的时候， LinkedList 的效率是要比 ArrayList 高的

面试官：哦哦，好的，我大概了解了，我这边没有什么想问的了，您回去等消息可以吗

？？？发生了什么？

哈哈，上面模拟了一个面试场景，是想引出来这篇文章的主题： LinkedList 在新增/删除元素时，效率比 ArrayList 高，这是真的吗？

我相信你也知道套路，一般这么一问，那肯定就不是真的了

放一张图片，这是经过我测试之后的真实结果

因为微信不能放外链的缘故，可以在公众号后台发送 “20200821” 获取测试代码

ArrayList 与 LinkedList 新增元素比较

从图中可以看出来， LinkedList 在新增元素时，它的效率不一定比 ArrayList 高，这是要分情况的

如果是从集合头部位置新增元素的话，那确实是 LinkedList 的效率要比 ArrayList 高

但是如果是从集合中间位置或者是尾部位置新增元素， ArrayList 效率反而要比 LinkedList 效率要高

Excuse me ？竟然和我以前学的不一样？阿粉我学的浅，你别骗我

哈哈哈，为什么会这样呢

这是因为 ArrayList 是基于数组实现的嘛，而数组是一块连续的内存空间，所以在添加元素到数组头部时，需要对头部后面的数据进行复制重排，所以效率是蛮低的

但是 LinkedList 是基于链表实现的，在添加元素的时候，首先会通过循环查找到添加元素的位置，如果要添加的位置处于 List 前半段，那就从前向后找;如果位置在后半段，那就从后往前找，所以 LinkedList 添加元素到头部是非常高效的（小声 BB ，这我知道

哦，这你知道？看来基础蛮不错的嘛~

所以当 ArrayList 在添加元素到数组中间时，有一部分数据需要复制重排，效率就不是很高，那为啥 LinkedList 比它还要低呢？这是因为 LinkedList 把元素添加到中间位置的时候，需要在添加之前先遍历查找，这个查找的时间比较耗时

添加元素到尾部操作中， ArrayList 的效率要比 LinkedList 的还要高，这是为啥嘞

因为 ArrayList 在添加的时候不需要什么操作，直接插入就好了，所以效率蛮高的

但是 LinkedList 就不一样了，对于 LinkedList 来说，也不需要查找啥的，直接插入就可以了，但是需要 new 对象，还有变换指针指向对象呀，这些过程耗时加起来可就比 ArrayList 长了

它是有前提的，那就是 ArrayList 初始化容量是足够的情况下，才有上述的特点，如果 ArrayList 涉及到动态扩容，那它的效率肯定会降低

ArrayList 与 LinkedList 删除元素比较

删除元素和新增元素的原理是一样的，所以删除元素的操作和新增元素的操作耗时也是很相近

这里就不再赘述

ArrayList 与 LinkedList 遍历元素比较

测试结果非常明显，对于 LinkedList 来说，如果使用 for 循环的话，效率特别低，但是 ArrayList 使用 for 循环去遍历的话，就比较高

为啥呢？

emmm ，得从源码说起

先来看 ArrayList 的源码吧，这个比较简单

1
2

public class ArrayList<E> extends AbstractList<E>
        implements List<E>, RandomAccess, Cloneable, java.io.Serializable

能够看到， ArrayList 实现了 List ， RandomAccess ， Cloneable 还有 Serializable 接口

你是不是对 RandomAccess 这个接口挺陌生的？这是个啥？

但是通过查阅源码能够发现它也只是个空的接口罢了，那 ArrayList 为啥还要去实现它嘞

因为 RandomAccess 接口是一个标志接口，它标识着“只要实现该接口的 list 类，都可以实现快速随机访问”

实现快速随机访问？你能想到什么？这不就是数组的特性嘛！可以直接通过 index 来快速定位 & 读取

那你是不是就能想到， ArrayList 是数组实现的，所以实现了 RandomAccess 接口， LinkedList 是用链表实现的，所以它没有用 RandomAccess 接口实现吧？

beautiful ~就是这样

咱瞅瞅 LinkedList 源码

1
2
3

public class LinkedList<E>
    extends AbstractSequentialList<E>
    implements List<E>, Deque<E>, Cloneable, java.io.Serializable

果然，跟咱们设想的一样，没有实现 RandomAccess 接口

那为啥 LinkedList 接口使用 for 循环去遍历的时候，慢的不行呢？

咱们瞅瞅 LinkedList 在 get 元素时，都干了点儿啥

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public E get(int index) {
    checkElementIndex(index);
    return node(index).item;
}

Node<E> node(int index) {
    // assert isElementIndex(index);

    if (index < (size >> 1)) {
        Node<E> x = first;
        for (int i = 0; i < index; i++)
            x = x.next;
        return x;
    } else {
        Node<E> x = last;
        for (int i = size - 1; i > index; i--)
            x = x.prev;
        return x;
    }
}

在 get 方法中，主要调用了 node() 方法，因为 LinkedList 是双向链表，所以 if (index < (size » 1)) 在判断 i 是在前半段还是后半段，如果是前半段就正序遍历，如果是在后半段那就倒序遍历，那么为什么使用 for 循环遍历 LinkedList 时，会这么慢？（好像离真相越来越近了

原因就在两个 for 循环之中，以第一个 for 循环为例

• get(0) ：直接拿到了node0 地址，然后拿到 node0 的数据

• get(1) ：先拿到 node0 地址，然后 i < index ，开始拿 node1 的地址，符合条件，然后去拿 node1 的数据

• get(2) ：先拿到 node0 的地址，然后 i < index ，拿到 node1 的地址， i < index ，继续向下走，拿到 node2 的地址，符合条件，获取 node2 的数据

发现问题了嘛？我就是想要 2 的数据， LinkedList 在遍历时，将 0 和 1 也给遍历了，如果数据量非常大的话，那效率可不就唰唰的下来了嘛

那到现在，咱们也就非常明确了，如果是要遍历 ArrayList 的话，最好是用 for 循环去做，如果要遍历 LinkedList 的话，最好是用迭代器去做

我猜你一定会说，阿粉啊，那如果对方就给我传过来了一个 list ，我不知道它是 ArrayList 还是 LinkedList 呀？我该怎么办呢

还记得 ArrayList 和 LinkedList 有什么不同吗？是不是 ArrayList 实现了 RandomAccess 接口，但是 LinkedList 没有实现，所以可以从这点去着手解决

暖暖的阿粉在这里给个简单的小 demo ，可以参考下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

public class ListTest {
    public static void main(String[] args) {
        List<String> arrayList = new ArrayList<String>();
        arrayList.add("aaa");
        arrayList.add("bbb");
        isUseIterator(arrayList);

        List<String> linkedList = new LinkedList<String>();
        linkedList.add("ccc");
        linkedList.add("ddd");
        isUseIterator(linkedList);
    }

    public static void isUseIterator(List list){
        if (list instanceof RandomAccess){
            System.out.println("实现了 RandomAccess 接口,使用 for 循环遍历");

            for (int i = 0 ; i < list.size(); i++ ){
                System.out.println(list.get(i));
            }
        }else{
            System.out.println("没有实现 RandomAccess 接口,使用迭代器遍历");

            Iterator it = list.iterator();
            while (it.hasNext()){
                System.out.println(it.next());
            }
        }
    }
}

本篇文章用到的所有代码，都上传到了 github 上，因为微信不能放外链的缘故，可以在公众号后台发送 “20200821” 获取本文完整代码

所以，乖，下次面试官再问你 LinkedList 在新增/删除元素时，效率比 ArrayList 高吗，不要再傻傻的回答是了，拿阿粉这篇文章和他扯皮，保证没问题

参考:

极客时间 — 《Java 性能调优实战》

Hello 大家好，我是阿粉，今天给大家分享一个采用 Consul 实现的负载均衡的方案，很多小伙伴都知道 Nginx 可以实现负载均衡，但是可能没实现过结合 Consul，今天就给大家分享一下。

概念

CopyOnWrite 只是看字面意思就能看出来，就是在写入时复制，说得轻巧，写入时复制，具体是怎么实现的呢？

先来说说思想，具体怎么实现等下分析

CopyOnWrite 的思想就是：当向一个容器中添加元素的时候，不是直接在当前这个容器里面添加的，而是复制出来一个新的容器，在新的容器里面添加元素，添加完毕之后再将原容器的引用指向新的容器，这样就实现了写入时复制

你还记得在提到数据库的时候，一般都会说主从复制，读写分离吗？ CopyOnWrite 的设计思想是不是和经常说的主从复制，读写分离如出一撤？

优缺点

了解概念之后，对它的优缺点应该就比较好理解了

优点就是，读和写可以并行执行，因为读的是原来的容器，写的是新的容器，它们之间互不影响，所以读和写是可以并行执行的，在某些高并发场景下，可以提高程序的响应时间

但是呢，你也看到了， CopyOnWrite 是在写入的时候，复制了一个新的容器出来，所以要考虑它的内存开销问题，又回到了在学算法时一直强调的一个思想:拿空间换时间

还有一点就是，它只保证数据的最终一致性。因为在读的时候，读取的内容是原容器里面的内容，新添加的内容是读取不到的

基于它的优缺点应该就可以得出一个结论： CopyOnWrite 适用于写操作非常少的场景，而且还能够容忍读写的暂时不一致 如果你的应用场景不适合，那还是考虑使用别的方法来实现吧

还有一点需要注意的是：在写入时，它会复制一个新的容器，所以如果有写入需求的话，最好可以批量写入，因为每次写入的时候，容器都会进行复制，如果能够减少写入的次数，就可以减少容器的复制次数

在 JUC 包下，实现 CopyOnWrite 思想的就是 CopyOnWriteArrayList & CopyOnWriteArraySet 这两个方法，本篇文章侧重于讲清楚 CopyOnWriteArrayList

CopyOnWriteArrayList

在 CopyOnWriteArrayList 中，需要注意的是 add 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

    public boolean add(E e) {
        final ReentrantLock lock = this.lock;
        // 在写入的时候,需要加锁,如果不加锁的话,在多线程场景下可能会被 copy 出 n 个副本出来
        // 加锁之后,就能保证在进行写时,只有一个线程在操作
        lock.lock();
        try {
            Object[] elements = getArray();
            int len = elements.length;
            // 复制原来的数组
            Object[] newElements = Arrays.copyOf(elements, len + 1);
            // 将要添加的元素添加到新数组中
            newElements[len] = e;
            // 将对原数组的引用指向新的数组
            setArray(newElements);
            return true;
        } finally {
            lock.unlock();
        }
    }

在写的时候需要加锁，但是在读取的时候不需要添加

因为读取的是原数组的元素，对新数组没有什么影响，加了锁反而会增加性能开销

1
2
3

public E get(int index) {
	return get(getArray(), index);
}

举个例子：

CopyOnWrite 在 JUC 包下，那么它就保证了线程安全

咱们来做个小 demo 验证一下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

@Slf4j
public class ArrayListExample {

    // 请求总数
    public static int clientTotal = 5000;

    // 同时并发执行的线程数
    public static int threadTotal = 200;

    private static List<Integer> list = new ArrayList<>();

    public static void  main(String[] args) throws Exception{
        ExecutorService executorService = Executors.newCachedThreadPool();
        final Semaphore semaphore = new Semaphore(threadTotal);
        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
        for (int i = 0; i < clientTotal; i++) {
            final int count = i;
            executorService.execute(()->{
                try {
                    semaphore.acquire();
                    update(count);
                    semaphore.release();
                } catch (Exception e) {
                    log.error("exception",e);
                }
                countDownLatch.countDown();
            });
        }
        countDownLatch.await();
        executorService.shutdown();
        log.info("size:{}",list.size());
    }
    private static void update(int i){
        list.add(i);
    }
}

上面是客户端请求 5000 次，有 200 个线程在同时请求，我使用的是 ArrayList 实现，咱们看下打印结果：

如果是线程安全的话，那么最后的结果应该是 5000 才对，多运行几次你会发现，每次程序的执行结果都是不一样的

如果是 CopyOnWriteArrayList 呢？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

@Slf4j
public class CopyOnWriteArrayListExample {

    // 请求总数
    public static int clientTotal = 5000;

    // 同时并发执行的线程数
    public static int threadTotal = 200;

    private static List<Integer> list = new CopyOnWriteArrayList<>();

    public static void  main(String[] args) throws Exception{
        ExecutorService executorService = Executors.newCachedThreadPool();
        final Semaphore semaphore = new Semaphore(threadTotal);
        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
        for (int i = 0; i < clientTotal; i++) {
            final int count = i;
            executorService.execute(()->{
                try {
                    semaphore.acquire();
                    update(count);
                    semaphore.release();
                } catch (Exception e) {
                    log.error("excepiton",e);
                }
                countDownLatch.countDown();
            });
        }
        countDownLatch.await();
        executorService.shutdown();
        log.info("size:{}",list.size());
    }
    private static void update(int i){
        list.add(i);
    }
}

多运行几次，结果都是一样的：

由此可见， CopyOnWriteArrayList 是线程安全的

以上，感谢阅读~

关于消息队列，断断续续的看了很多资料，一直想抽个时间把这些知识整理记录下来，但是没腾出时间来写，正好所在的项目在实际业务中使用到了消息队列，索性就将这方面的知识整理一下，可能有理解不到位的地方，望网友批评指出！

Hello 大家好，我是阿粉，不知道你有没有遇到过这种场景，一套代码部署在不同的环境中，随着时间的过去，各个环境代码有版本差异，代码层面可以通过不同的版本来控制，但是数据库层面经常容易忘记更新！

在开始之前，咱们要知道：如果我的 SQL 语句执行的足够快，还有没有必要去做优化？

完全没有必要对吧

所以我们一般说，要给 SQL 做个优化，那肯定就是这条 SQL 语句执行的比较慢了

那么，为什么它会执行比较慢呢？

SQL 语句执行较慢的 3 个原因

没有建立索引，或者索引失效导致了 SQL 语句执行较慢

这个应该是比较好理解的，如果数据比较多，在千万级别以上，然后呢又没有建立索引，在这千万级别的数据中查找你想要的内容，简直就是在肉搏啊（哎呦，可了不得，竟然敢肉搏

索引失效这块内容说起来就比较多了，比如在查询的时候，让 like 通配符在前面了，比如经常念叨的“最左匹配原则”，又比如我们在查询条件中使用 or ，而且 or 前后条件中有一个列没有索引，等等这些情况都会导致索引失效

锁等待

常用的存储引擎主要有 InnoDB 和 MyISAM 这两种了，前者支持行锁和表锁，后者就只支持表锁

如果数据库操作都是基于表锁的话，意思就是说，现在有个更新操作，就会把整张表锁起来，那么查询的操作都不被允许，所以就不要说提高系统的并发性能了

• 聪明的你肯定就知道了，既然 MyISAM 只支持表锁，那么使用 InnoDB 不就好了？你以为 InnoDB 的行锁不会升级成表锁嘛？ too young too simple ！

• 如果对一张表进行大量的更新操作， mysql 就觉得你这样用会让事务的执行效率降低，到最后还是会导致性能下降，这样的话，还不如把你的行锁升级成表锁呢

• 还有一点，行锁可是基于索引加的锁，在执行更新操作时，条件索引都失效了，那么这个锁也会执行从行锁升级为表锁

不恰当的 SQL 语句

这个也比较常见了，啥是不恰当的 SQL 语句呢？就比如，明明你需要查找的内容是 name ， age ，但是呢，为了省事，直接 select * ，或者在 order by 时，后面的条件不是索引字段，这就是不恰当的 SQL 语句

优化 SQL 语句

在知道了 SQL 语句执行比较慢的原因之后，接下来要做的就是对症下药了

针对 没有索引/索引失效 这块，最有效的办法就是 EXPLAIN 语法了，那你知不知道 Show Profile 也可以嘞

针对 锁等待 这块，没办法了，只能自己多注意

针对 不恰当的 SQL 语句 这块，介绍几个常用的 SQL 优化，比如分页查询怎么优化一下可以查询的更快一些呀，你不是说 select * 不是正确的打开方式嘛？那什么是正确的 select 方式呢？别急嘛，阿粉下面都会说到的

废话不多说，咱们开始了

先来个表

为了确保优化后的结果和我写的一样（起码 90% 是相符的

所以咱们用一样的数据库好不好？乖~

首先建个 demo 的数据库

接下来咱们建表，就建个非常简单的表好不好

1
2
3
4
5
6

CREATE TABLE demo.table(
	id int(11) NOT NULL,
	a int(11) DEFAULT NULL,
	b int(11) DEFAULT NULL,
	PRIMARY KEY(id)
) ENGINE = INNODB

然后插入 10 万条数据

1
2
3
4
5
6
7
8
9
10
11

DROP PROCEDURE IF EXISTS demo_insert;
CREATE PROCEDURE demo_insert()
BEGIN
    DECLARE i INT; 
		SET i = 1;
    WHILE i <= 100000 DO
        INSERT INTO demo.`table` VALUES (i, i, i);
        SET i = i + 1 ;
    END WHILE;
END;
CALL demo_insert();

OK ，准备工作做好了，接下来开始实战

通过 EXPLAIN 分析 SQL 是怎样执行的

只要说 SQL 调优，那就离不开 EXPLAIN

EXPLAIN SELECT * FROM table WHERE id < 100 ORDER BY a;

咱们能够看到有好几个参数:

• id :每个执行计划都会有一个 id ，如果是一个联合查询的话，这里就会显示好多个 id

• select_type :表示的是 select 查询类型，常见的就是 SIMPLE (普通查询，也就是没有联合查询/子查询), PRIMARY (主查询), UNION ( UNION 中后面的查询), SUBQUERY (子查询)

• table :执行查询计划的表，在这里我查的就是 table ，所以显示的是 table， 那如果我给 table 起了别名 a ，在这里显示的就是 a

• type :查询所执行的方式，这是咱们在分析 SQL 优化的时候一个非常重要的指标，这个值从好到坏依次是: system > const > eq_ref > ref > range > index > ALL

  • system/const :说明表中只有一行数据匹配，这个时候根据索引查询一次就能找到对应的数据

  • eq_ref :使用唯一索引扫描，这个经常在多表连接里面，使用主键和唯一索引作为关联条件时可以看到

  • ref :非唯一索引扫描，也可以在唯一索引最左原则匹配扫描看到

  • range :索引范围扫描，比如查询条件使用到了 < ， > ， between 等条件

  • index :索引全表扫描，这个时候会遍历整个索引树

  • ALL :表示全表扫描，也就是需要遍历整张表才能找到对应的行

• possible_keys :表示可能使用到的索引

• key :实际使用到的索引

• key_len :使用的索引长度

• ref :关联 id 等信息

• rows :找到符合条件时，所扫描的行数，在这里虽然有 10 万条数据，但是因为索引的缘故，所以扫描了 99 行的数据

• Extra :额外的信息，常见的有以下几种

  • Using where :不用读取表里面的所有信息，只需要通过索引就可以拿到需要的数据，这个过程发生在对表的全部请求列都是同一个索引部分时

  • Using temporary :表示 mysql 需要使用临时表来存储结果集，常见于 group by / order by

  • Using filesort :当查询的语句中包含 order by 操作的时候，而且 order by 后面的内容不是索引，这样就没有办法利用索引完成排序，就会使用”文件排序”,就像例子中给出的，建立的索引是 id ， 但是我的查询语句 order by 后面是 a ，没有办法使用索引

  • Using join buffer :使用了连接缓存

  • Using index :使用了覆盖索引

如果对这些参数了解的非常不错，那么 EXPLAIN 这块内容就难不住你了

Show Profile 分析下 SQL 执行性能

通过 EXPLAIN 分析执行计划，只能说明 SQL 的外部执行情况，如果想要知道 mysql 具体是如何查询的，需要通过 Show Profile 来分析

可以通过 SHOW PROFILES; 语句来查询最近发送给服务器的 SQL 语句，默认情况下是记录最近已经执行的 15 条记录，如下图我们可以看到:

我想看具体的一条语句，看到 Query_ID 了嘛？然后运行下 SHOW PROFILE FOR QUERY 82; 这条命令就可以了:

可以看到，在结果中， Sending data 耗时是最长的，这是因为此时 mysql 线程开始读取数据并且把这些数据返回到客户端，在这个过程中会有大量磁盘 I/O 操作

通过这样的分析，我们就能知道， SQL 语句在查询过程中，到底是 磁盘 I/O 影响了查询速度，还是 System lock 影响了查询速度，知道了病症所在，接下来对症下药就容易多了

分页查询怎么可以更快一些

在使用分页查询时，都会使用 limit 关键字

但是对于分页查询，其实还可以优化一步

我这里给出的数据库不是太好，因为它太简单了，看不出来有什么区别，我使用目前项目上正在用的表来做个实验，可以看下区别（使用的 SQL 语句如下面）:

1
2
3
4

EXPLAIN SELECT * FROM `te_paper_record` ORDER BY id LIMIT 10000, 20;

EXPLAIN SELECT * FROM `te_paper_record` WHERE id >= ( SELECT id FROM `te_paper_record` ORDER BY id LIMIT 10000, 1) LIMIT 20;

上面一张图片，我没有使用子查询，可以看到执行了 0.033s ，下面的查询语句，我使用了子查询去做优化，能够看到执行了 0.007s ，优化的结果还是很显而易见的

那么，为什么使用了子查询，查询的速度就提上来了呢，这是因为当我们没有使用子查询时，查询到的 10020 行数据都返回回来了，接下来要对这 10020 行数据再进行过滤操作

那可不可以直接就返回需要的 20 行数据呢，这样就不需要再做过滤操作了，直接返回就可以了嘛

你也太聪明了吧。子查询就是在做这件事情

所以查询时间上有了一个很大的优化

正确的 select 打开方式

在查询时，有时为了省事，直接使用 select * from table where id = 1 这样的 SQL 语句，但是这样的写法在一些环境下是会存在一定的性能损耗的

所以最好的 select 查询就是，需要什么字段就查询什么字段

一般在查询时，都会有条件，按照条件查找

这个时候正确的 select 打开方式是什么呢？

如果可以通过主键索引的话， where 后面的条件，优先选择主键索引

为什么呢？这就要知道 MySQL 的存储规则

MySQL 常用的存储引擎有 MyISAM 和 InnoDB ， InnoDB 会创建主键索引，而主键索引属于聚簇索引，也就是在存储数据时，索引是基于 B+ 树构成的，具体的行数据则存储在叶子节点

也就是说，如果是通过主键索引查询的，会直接搜索 B+ 树，从而查询到数据

如果不是通过主键索引查询的，需要先搜索索引树，得到在 B+ 树上的值，再到 B+ 树上搜索符合条件的数据，这个过程就是“回表”

很显然，回表能够产生时间。

这也是为什么建议， where 后面的条件，优先选择主键索引

其他调优

看完上面的，心里应该就大概有数了， SQL 调优主要就是建立索引/防止产生锁等待/使用恰当的 SQL 语句去查询

但是，如果问你除了索引，除了上面这些手段，还有没有其他调优方式

啥？竟然还有？！

有的，这就需要跳出来，不要局限在具体的 SQL 语句上了，需要在数据库设计之初就考虑好

比如说，我们常说的要遵循三范式，但是在有的业务场景里面，如果在数据库里面多几个冗余字段的话，可能要比严格遵循三范式带来的性能要好很多。

但是这点就及其考验平时的积累了，阿粉在这里把这一点提出来之后，希望读者们可以看看自己项目上目前用的数据库有没有多余的字段，为什么要这样设计呢？这样多去观察，你的技术能力想不提高都很难

以上，就这样啦~

面试官都这么问了，我能说不能吗？