hello~各位读者好，我是鸭血粉丝（大家可以称呼我为「阿粉」）。今天，阿粉带着大家来了解一下 最近在项目中遇到的一个坑。

1业务场景

前端用了个富文本插件 Ueditor ，插件初始化的时候需要从后端获取 config 配置。

2入坑经历

首先看下最开始的代码：

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

	@RequestMapping(value = "/getConfig")
    public Object getConfig(HttpServletRequest request){
       return readConfig()；
    }

	/**
     * 读取配置文件
     * @return
     */
    private UedConfig readConfig() {
        String path = this.getClass().getResource("/").getPath();
        FileInputStream fileInputStream = new FileInputStream(path + "config/ued_config.json");
        //读出来,转成对象返回
        ...
    }

代码大概就是这样，然后启动起来之后，前端告诉我没有获取到信息。纳尼，我postman自测都没问题，有数据返回。然后阿粉跑去问前端，有报错吗？前端说跨域了。当时阿粉就不乐意了，马上 ctrl+c 加上ctrl+v 把后端处理跨域请求的配置发给前端。然后前端告诉我是jsonp 请求跨域。阿粉一脸懵逼？？？jsonp 跨域？没听说过啊。马上找度娘去，果然一搜全是处理方式。因为是 springboot 项目，所以找了个最简单的。看代码：

1
2
3
4
5
6

@ControllerAdvice
public class JsonpAdvice extends AbstractJsonpResponseBodyAdvice {
    public JsonpAdvice(){
        super("callback");
    }
}

看，是不是很简单。要是 AbstractJsonpResponseBodyAdvice 这个单词下面没有红线就更完美了。没有引入类吗？怎么难得倒阿粉呢。alt+enter，嗯哼，什么情况，没有这个类？不可能啊。马上问度娘一下，原来这个类是 springboot 2.0以下才有。那怎么办呢？2.0以上好像没有处理 jsonp 跨域的方式啊。阿粉又在百度搜啊搜，果然，皇天不负有心人，阿粉看到 jackson 里面有个类 JSONPObject 可以处理，然后阿粉改了一下代码：

1
2
3
4

@RequestMapping(value = "/getConfig")
public Object getConfig(String callback,HttpServletRequest request){
    return new JSONPObject(callback,readConfig());
}

然后重启,自测没问题。让前端试下，可以正常获取。OK，完美。

后面项目完成了，前后端也对接完了，发到测试环境，让测试人员测试。Duang~一个bug扔阿粉头上，获取配置失败。不可能啊，肯定是前端的问题，跑去找前端让前端看下。前端看了之后给我来了一句，测试环境不跨域。瞬间一万头草尼玛从头上飘过。阿粉辛辛苦苦花了几个小时才把跨域问题处理了，你给我说测试环境不跨域。

哎，没办法，这口锅只能自己含泪抗下了。然后阿粉又改了一次代码：

1
2
3
4

@RequestMapping(value = "/getConfig")
public Object getConfig(String callback,HttpServletRequest request){
    return StringUtils.isEmpty(callback) ? readConfig() : new JSONPObject(callback,readConfig());
}

还是做了个兼容，因为前端还需要连我本地调试。不过这次应该没有问题了吧，阿粉心里还是有些小得意。提交代码，发测试，搞定。

Duang~同样的bug再一次扔在了阿粉脸上。心都凉了，怎么回事呢？日志也没报错啊。捣鼓半天，不知道什么原因，阿粉只能加写log，因为在测试环境不好调试，也没报错。然后让运维配合一下，然后发现 this.getClass().getResource(“/”).getPath() 得到的路径不对，阿粉再一次一脸懵逼，这个不是获取项目根路径吗？怎么回事呢。

然后阿粉有厚着脸皮找度娘，果然一下就找到原因了，因为 springboot 集成了tomcat，项目直接是打成 jar 包运行的，不能通过 this.getClass().getResource(“/”).getPath() 这种获取项目根路径的方式来获取，只能通过流的方式，然后阿粉又改了下代码：

1
2
3
4
5
6
7
8
9

/**
     * 读取配置文件
     * @return
     */
private UedConfig readConfig() {
    InputStream resourceAsStream = this.getClass().getResourceAsStream("/"+"config/ued_config.json");
    //读出来,转成对象返回
    ...
}

好了，这次提交之后终于可以了。解决了 bug ，阿粉心里美滋滋。

3 总结

经常看到一些小伙伴说，本地对接没问题，怎么一到测试环境就那么多 bug 呢。阿粉总结了一下，主要还是以下几点：

1. 系统不一样，本地一般都是window系统，而测试和线上一般都是 linux 系统。
2. 运行方式不一样，本地 springboot 项目是通过代码工具 （idea）启动，而测试和线上是通过 jar 包启动。
3. 比如还有一些其他 jar 引入的问题
4. 。。。

好了，阿粉这次的分享就到这里了。希望阅读阿粉文章的朋友少走一些弯路。要是觉得有用的话，记得点个赞哦。

Hello 大家好，我是鸭血粉丝，前面一篇文章给大家介绍了 SpringBoot 项目是如何从单机切换接入集群的，没看过的小伙伴可以去看一下SpringBoot 项目接入 Redis 集群 。这篇文章给大家介绍一个 Redis 工具 redis-full-check，主要是用来校验迁移数据过后的准确性，下面我们来看一下。

前言

在阿粉刚刚选择走上程序员道路的时候，脑海中还没有技术博客这个概念。那个时候入门靠的是培训班的视频，初学的过程中总会遇到许多陌生的概念，视频里没听懂的话一般会选择到搜索引擎去搜一下，多看几种不同的解释进行消化，也就是从这时开始接触到的技术博客。

在最开始的时候，我对博客的理解和我们读书时候做的笔记差不多，就是把学到的知识记录下来。但是慢慢的，我开始接触到了一些比较优秀的博客，他们的共性是能够把一个知识点讲得很清楚，能给出自己的理解，或者有适当的示例代码帮助读者理解。慢慢地我也萌发了要写博客的念头，初衷很简单，就是要把自己理解的某个知识点用自己的话分享出来。

屈指一算，从开创博客园账号至今也已经一年半了，自己的博客记录了自己的技术成长过程，收获了很多，下面我就给大家分享一下写博客能给大家带来什么好处吧。

1. 帮助我们理解知识

首先写博客能帮助我们很好地梳理并掌握一个知识点。不知道大家有没有听过这样的话：在学一个知识点的时候，如果只是听一遍讲，那你大概能掌握10%；做了笔记，大概掌握25%；能做出相应的题目，掌握50%；如果能把这个知识点教授给别人的话，那么就掌握了80%了。如果我们把写博客当成一个给他人传授知识的过程，当我们的博客写完了，自然地我们也就掌握了这个知识。当然这个过程是非常不容易的，想要把知识传授给他人，首先我们自己要吃透了这个知识。我个人在写博客的时候常常会遇到这么一种情况：写着写着就写不下去了，发现自己其实没有搞懂，理解透彻某个知识。为了把博客写下去，会强迫自己去把相关的知识搞懂。当我们通过博客的形式把一个知识点讲懂之后，其实我们就明白了一个知识点的来龙去脉，这对我们形成系统的知识体系很有帮助。

2. 获得成就感

写博客除了能帮助我们巩固理解知识外，还能给我们带来一些学习之外的乐趣。就我自己而言，每当我写的文章被别人评论或点赞，心里都会暗暗一乐，毕竟大多数情况下人还是希望得到他人认可的。尽管有时候得到的也不全是认可，可能会有其他小伙伴指出你的不足，也不失是一次学习的机会。

3. 提高影响力

在我个人看来，写博客还能提高自己的影响力，你的每一篇博客都是一次能力的展示，如果你的内容足够优秀的话，这些博客就是你的一张名片。我曾经因为博客收到过出版社的出书邀约，大厂的面试邀约等，尽管当时知道自己还没有达到那个水平，但还是蛮开心的。

4. 面试加分项

在面试写简历的时候，我们可以直接放上自己的博客链接，在同等水平的情况下，长期精心维护的技术博客是很有可能成为加分项的，毕竟大家都喜欢乐于分享知识的人。我曾经经历过一场有趣的面试，那是一场腾讯的主管面试，采用视频面试。面试的形式很常规，面试官抛出一个知识点，让我能讲多少讲多少。当时不知道为啥，他问的内容很多都是我掌握的比较好的内容。等面试结束的时候他告诉我他从面试开始就一直在看我的博客，刚好我的博客涉及的知识点也比较多，他就直接从上面挑知识问了，并对我的博客给予了肯定。虽然这是小概率事件了，但是也从侧面说明总有一天你的博客会帮上忙的。

后话

不知道以上写博客的好处能不能打动你，在我个人看来，写博客是一件百利无一害的事情，可能唯一比较麻烦的就是写博客比较费时间，不过我想花出去的时间能获得以上四个方面的收获也是值得的。把写博客当成一种习惯吧，坚持下来一定会有所收获的。

阿粉一定鼓足勇气，跟喜欢的女生表白

今天同事问阿粉一个问题，觉得挺有意义的，在这里也问问各位读者们：如果时间可以倒流，你最想做什么呢？为什么呢？

这个问题阿粉也问了问身边的一些朋友们，下面是他们的答案，或许可以给你一些启发

朋友 A ：如果时间可以倒流，我特别想要回到高中的时候，好好学习，踏踏实实的去努力，好好读书。不是那种死板教条的读书，是有计划有效率的读书，希望自己能够死不要脸一些，多向老师和同学请教问题，我可能天资不够聪慧，但是如果能够有效率一些，死不要脸一些，最起码会比现在要好得多吧

朋友 B ：我想回到高三结束的那个暑假啊，跟喜欢的女生表白。我也是后来才知道，当时我喜欢的那个女生，对我也有好感，我当时但凡是再勇敢一点儿，也不至于母胎 solo …

朋友 C ：我跟你讲，要是能回到过去的话，我就回到 2006 年 6 月 1 日，中国船泊 5 元钱，全部身价买了后 2007 年 9 月 298 抛，然后买房子，然后入股腾讯阿里，在微信刚起来的时候就去做公众号，这样的话 2020 年的我可能算不上首富，但起码也可以算是人生赢家了（狗头保命

朋友 D ：我希望我能回到初中的时候，告诉自己你很棒，自信一些。我以前就是一个比较敏感的小女生，非常在意别人看法，心情不愉快的时候就是自己憋着，也不会和别人人沟通，一个人硬抗。有的时候，朋友就会跟我说比较喜欢我，对我称赞有加，但是因为我不是很自信，所以对自己的闪光点视而不见。这些年在男朋友的耐心陪伴下才慢慢建立起自己的自信心，才敢表达自己的想法，说到这里，想和所有的女生说一句，你就是最棒的，不要怀疑自己，要自信一些！（PS ： 这个小姐姐好暖，阿粉爱了

朋友 E ：希望在大学的时候，自己少在宿舍睡会儿觉，打会儿游戏，多出去走走，多交朋友。一定要积极结交朋友，因为他们可以或多或少带给你快乐，在未来的生活里朋友是非常重要的一个存在，很多事情都可以帮到你，真的到那个时候，你会无比的庆幸自己有好朋友在身边陪伴着自己

朋友 F ：如果时间可以倒流，我想回到高中，跟我的老班道个歉，谢谢她当时是一直为我考虑，当时自己太年少轻狂了，根本没有把她的话放在心上，反而以为是老班想要放弃我这个学生了，处处和她顶撞，说那么难听的话。当时如果能够站在她的角度去想想…现在想要和她道个歉，都已经联系不到她了，特别遗憾

朋友 G ： 如果时间可以倒流么？我就回到母亲的子宫里，脐带绕颈三圈勒死我自己，哈哈哈，阿粉你肯定没想到我会这样回答

朋友 G 是个调皮鬼，平时就是段子频出，问他的时候他给我这个回答，真是让我惊呆了，脑回路总是这么清奇

其实阿粉对于这个问题也是认真的想了想，阿粉也有想要回去的时候，比如阿粉小的时候，一家人在冬天围着火炉，边取暖边和父母说笑，现在一年可能也就过年的时候回去；比如阿粉做错事惹母亲生气的时候；但是怎么可能会回去呢

只是当我们有这么念头的时候，肯定是当时是哪里自己没有做好，所以想要回去，尽自己的努力去做的更好一些

过去的已经过去，已经是抓不住的了，其实我们不如将那份心情和遗憾，放在未来，尽全力去做好当下的事情，去抓住未来。

故事还长，不要失望~

Hello 大家好，我是鸭血粉丝，Redis 想必大家一定不会陌生，平常工作中或多或少都会用到，不管是用来存储登录信息还是用来缓存热点数据，对我们来说都是很有帮助的。但是 Redis 的集群估计并不是每个人都会用到，因为很多业务场景或者系统都是一些简单的管理系统，并不会需要用到 Redis 的集群环境。

阿粉之前也是这样，项目中用的的 Redis 是个单机环境，但是最近随着终端量的上升，慢慢的发现单机已经快支撑不住的，所以思考再三决定将 Redis 的环境升级成集群。下面阿粉给大家介绍一下在升级的过程中项目中需要调整的地方，这篇文章不涉及集群的搭建和配置，感兴趣的同学自行搜索。

扶我起来，我还能学

上周六发了一篇文章： 有个程序媛女朋友是什么体验？ ，把阿粉酸的，周六日都没缓过来。但是阿粉又是一个比较负责任的博主，酸归酸，文章还是要更新的

题目是个标题党啦，就是想带你过一遍 ReentrantReadWriteLock ，为了让可爱的读者们多看几眼阿粉的文章，可真是费劲了心思，就问你我暖不暖

ReentrantReadWriteLock 与 ReentrantLock 区别？

在这篇文章中: 阿粉写了八千多字，就是为了把 ReentrantLock 讲透 阿粉对 ReentrantLock 已经做了非常详细的讲解了

那么，今天想要说的 ReentrantReadWriteLock 和 ReentrantLock 有什么区别呢？如果只是从名字上来说的话，就是多了一个 ReadWrite 嘛

如果对 ReentrantLock 比较熟的话，那么当阿粉问你， ReentrantLock 是独占锁还是共享锁，你的第一反应就是: 独占锁

ReentrantReadWriteLock 是在 ReentrantLock 的基础上做的优化，什么优化呢？ ReentrantLock 就是不管操作是读操作还是写操作都会对资源进行加锁，但是聪明的你想想嘛，如果好几个操作都只是读的话，并没有让数据的状态发生改变，这样的话是不是可以允许多个读操作同时运行？这样去处理的话，相对来说是不是就提高了并发呢

很多事情都是说起来容易，具体是怎么实现的呢？

啥也不多说，咱们直接上源码好吧

在使用 ReentrantReadWriteLock 时，一般都是调用 writeLock 和 readLock 两种方法，它在源码中定义如下:

1
2

public ReentrantReadWriteLock.WriteLock writeLock() { return writerLock; }
public ReentrantReadWriteLock.ReadLock  readLock()  { return readerLock; }

而 writeLock 和 readLock 是 ReentrantReadWriteLock 的两个内部类，其中这两种锁的实现如下（其中省略了一些代码）：

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

public static class ReadLock implements Lock, java.io.Serializable {
    public void lock() {
    	// 共享锁
        sync.acquireShared(1);
    }
		
	public void unlock() {
		// 共享锁
        sync.releaseShared(1);
    }
}

public static class WriteLock implements Lock, java.io.Serializable {
    public void lock() {
    	// 独占锁
        sync.acquire(1);
    }
	
	public void unlock() {
		// 独占锁
        sync.release(1);
    }
}

从源码就能够看出，对于读锁 readLock 它使用的是共享锁，也就是多个线程读没问题 但是对于写锁 writeLock 它使用的是独占锁，就是当一个线程要进行写操作时，其他的线程都要停下来等待

简单点儿说就是：一个资源可以被多个读线程访问，或者被一个写线程访问，但是不能同时存在读线程和写线程，这也是读写锁的定义

ReadLock 和 WriteLock 共享一个变量

如果让你设计一个读写锁的话，会怎样设计？

阿粉还真的认真想了想这个问题，如果让我设计的话，我应该会用两个变量去控制读和写，当线程获取到读锁时就对读变量进行 +1 操作，当获取到写锁时，就对写变量进行 +1 操作

但是通过看 ReentrantReadWriteLock 源码发现，它只是通过一个 state 来实现的

具体实现如下:

1
2
3
4
5
6
7
8
9

static final int SHARED_SHIFT   = 16;
static final int SHARED_UNIT    = (1 << SHARED_SHIFT);
static final int MAX_COUNT      = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

/** Returns the number of shared holds represented in count  */
static int sharedCount(int c)    { return c >>> SHARED_SHIFT; }
/** Returns the number of exclusive holds represented in count  */
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

有两个关键方法 sharedCount 和 exclusiveCount ，乖，光是从名字意思来看应该也是可以猜出来的吧: sharedCount 就是共享锁的数量，而 exclusiveCount 则是独占锁的数量

通过看源码，能够看出来，对于 sharedCount 来说，它的计算方式就是无符号右移 16 位，空位都以 0 来补齐( c >>> SHARED_SHIFT; )

对于 exclusiveCount 来说，它的计算方式就是将传进来的 c 和 EXCLUSIVE_MASK 做 “&” 运算，那么 EXCLUSIVE_MASK 的值是什么呢？就是 (1 << SHARED_SHIFT) - 1 ，如果对位运算比较熟的话，应该会很容易看出来 (1 << SHARED_SHIFT) - 1 的值就是 65535 ，化成二进制就是 16 个 1，传进来 c 的值，和 16 位全为 1 做 “&” 运算的话，只有 1 & 1 才为 1 ，也就是说，传进来的 c 值经过这样转换之后，还是原来的值

说到这里，可能有点儿懵了，没关系，咱们来个总结就好说了(为了好理解，我就用大白话说了，争取你们都能看懂

对于 sharedCount 来说，只要传进来的值不大于 65535 ，那么经过计算之后，值都是 0

对于 exclusiveCount 来说，传进来的值是多少，经过计算之后还是多少

不管是 sharedCount 还是 exclusiveCount ，最大值都是 65535 ，因为是和 16 做位运算，其实这个数字也是相当够用了

那么，看到这里，各位应该就比较了解了吧，对于 ReadLock 和 WriteLock 来说，在源码层次其实并不是用两个变量去做的，而是通过一个 state 来实现的，思路真的是非常的巧妙

对于阿粉上面说的，如果还是不清楚的话，可以自己写个 demo 去验证一下，很简单的，就比如下面这样:

1
2
3
4
5
6
7

public static void main(String[] args) {
    int shareCount = 3000 >>> 16;
    System.out.println("shareCount : " + shareCount);

    int exclusiveCount = 1 & ((1 << 16) - 1);
    System.out.println("exclusiveCount : " + exclusiveCount);
}

等你运行完之后，你就发现，哇，怎么和我说的一样，哈哈哈哈

对于 sharedCount 来说，它是针对读锁的，所以不管多少进程进行读取资源，都没关系，所以它的值就是 0

对于 exclusiveCount来说，它是针对写锁的，那么只要有一个进程在进行写入，其他线程都要停下来等待，所以它的值就是传进来的值

综上，使用一个状态的话，我们只需要去判断 state 这个状态就可以了

WriteLock 的具体实现

OK ，既然你都看到了这里，我就默认上面的内容你都理解了

WriteLock 说白了就是独占锁，所以在获取 WriteLock 时，不能只考虑是否有写锁在占用，还要考虑有没有读锁.接下来咱们就去探究一下， WriteLock 它具体是怎么实现的

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

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

protected final boolean tryAcquire(int acquires) {
    Thread current = Thread.currentThread();
    // 获取到锁的状态
    int c = getState();
    // 获取写锁的数量
    int w = exclusiveCount(c);
    // c != 0 说明有读锁/写锁
    if (c != 0) {
        // (Note: if c != 0 and w == 0 then shared count != 0)
        // w == 0 说明此时没有写锁,有读锁 或者 持有写锁的线程不是当前线程
        if (w == 0 || current != getExclusiveOwnerThread())
            return false;
        // 如果写锁数量超出了最大值,没啥说的,抛异常就完事儿了
        if (w + exclusiveCount(acquires) > MAX_COUNT)
            throw new Error("Maximum lock count exceeded");
        // Reentrant acquire
        // 当前线程持有写锁,为重入锁,直接 +acquires 即可
        setState(c + acquires);
        return true;
    }
    // CAS 操作,确保修改值成功
    if (writerShouldBlock() ||
        !compareAndSetState(c, c + acquires))
        return false;
    setExclusiveOwnerThread(current);
    return true;
}

如果对 ReentrantLock 比较熟的话，你会发现，上面的代码大部分都是见过的 有一点区别就是调用了 exclusiveCount 方法，看当前是否有写锁存在，接下来通过 c != 0 and w == 0 判断了当前是否有读锁存在

ReadLock 的具体实现

WriteLock 探究完了，接下来瞅瞅 ReadLock ，话不多说，直接上源码

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

public void lock() {
    sync.acquireShared(1);
}

public final void acquireShared(int arg) {
    if (tryAcquireShared(arg) < 0)
        doAcquireShared(arg);
}

protected final int tryAcquireShared(int unused) {
    Thread current = Thread.currentThread();
    int c = getState();
    // 写锁不等于 0 时,看看当前写锁是否在尝试获取读锁
    if (exclusiveCount(c) != 0 &&
        getExclusiveOwnerThread() != current)
        return -1;
    // 获取读锁数量
    int r = sharedCount(c);
    // 读锁不需要阻塞,而且读锁需要小于最大读锁数量,同时 cas 操作进行加 1 操作
    if (!readerShouldBlock() &&
        r < MAX_COUNT &&
        compareAndSetState(c, c + SHARED_UNIT)) {
        // 当前线程是第一个并且第一次获取读锁时
        if (r == 0) {
            firstReader = current;
            firstReaderHoldCount = 1;
        } else if (firstReader == current) {
            // 如果当前线程再次获取读锁,则直接进行 ++ 操作即可
            firstReaderHoldCount++;
        } else {
            // 当前线程不是第一个获取读锁的线程,就放入线程本地变量
            HoldCounter rh = cachedHoldCounter;
            if (rh == null || rh.tid != getThreadId(current))
                cachedHoldCounter = rh = readHolds.get();
            else if (rh.count == 0)
                readHolds.set(rh);
            rh.count++;
        }
        return 1;
    }
    return fullTryAcquireShared(current);
}

看完有没有觉得和写锁那块挺像的，不同就在于因为是读锁嘛，所以只要没有写锁占用，而且读锁的数量没有超过最大的获取数量，就都可以获取读锁

在上面， firstReader firstReaderHoldCount cachedHoldCounter 都是为 readHolds 服务的，它是为了获取当前线程持有锁的数量，在 ThreadLocal 基础上添加了 Int 变量来统计，这样比较方便嘛

具体实现如下:

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

static final class ThreadLocalHoldCounter
    extends ThreadLocal<HoldCounter> {
    public HoldCounter initialValue() {
        return new HoldCounter();
    }
}

static final class HoldCounter {
    // 当前线程持有锁的数量
    int count = 0;
    // Use id, not reference, to avoid garbage retention
    // 当前线程 ID
    final long tid = getThreadId(Thread.currentThread());
}

回到题目，手写一个读写锁出来？

接下来，再回到题目，如果面试官让手写一个读写锁出来，你会如何实现呢？

在读了源码之后，相信你心里应该有谱了

首先来个 state 变量，然后高 16 位设置为读锁数量，低 16 位设置为写锁数量低，然后在进行读锁时，先判断下是不是有写锁，如果没有，直接读取即可，如果有的话那就需要等待；在写锁想要拿到锁的时候，就要判断写锁和读锁是不是都存在了，如果存在那就等着，如果不存在才进行接下来的操作

在这里阿粉给出一个简单版的实现:

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

 public static class ReadWrite{
    // 定义一个读写锁共享变量 state
    private int state = 0;

    // state 高 16 位为读锁数量
    private int getReadCount(){
        return state >>> 16;
    }

    // state 低 16 位为写锁数量
    private int getWriteCount(){
        return state & (( 1 << 16 ) - 1 );
    }

    // 获取读锁时,先判断是否有写锁
    // 如果有写锁,就等待
    // 如果没有,进行加 1 操作
    public synchronized void lockRead() throws InterruptedException{
        while ( getWriteCount() > 0){
            wait();
        }

        System.out.println("lockRead --- " + Thread.currentThread().getName());
        state = state + ( 1 << 16);
    }

    // 释放读锁数量减 1 ,通知其他线程
    public synchronized void unLockRead(){
        state = state - ( 1 << 16 );
        notifyAll();
    }

    // 获取写锁时需要判断读锁和写锁是否都存在,有则等待,没有则将写锁数量加 1
    public synchronized void lockWrite() throws InterruptedException{

        while (getReadCount() > 0 || getWriteCount() > 0) {
            wait();
        }
        System.out.println("lockWrite --- " + Thread.currentThread().getName());
        state ++;
    }

    // 释放写锁数量减 1 ,通知所有等待线程
    public synchronized void unlockWriters(){
        state --;
        notifyAll();
    }
}

阿粉自己测试了下，没啥大问题

但是如果细究的话，还是有问题的，就比如，如果现在我有好多个读锁，如果一直不释放的话，那么写锁是一直没办法获取到的，这样就造成了饥饿现象的产生嘛

解决的话也蛮好解决的，就是在上面添加一个记录写锁数量的变量，然后在读锁之前，去判断一下是否有线程要获取写锁，如果有的话，优先处理，没有的话再进行读锁操作

这块聪明的读者，就试试自己实现吧，阿粉这里就不给具体实现了

前几天阿粉说阿粉最近换了公司，而且入职之后干掉了公司里面的测试数据库的事情，而接下来的事就比较有意思了，来自“科班出身”的哥们和来自“培训出身”的我的大型辩论(SIBI)现场，也不能说是通俗的甩锅，但是确实有那么点意味。

再过一段时间就是国庆假期加上中秋假期了，很多小伙伴都准备趁着这个时间好好出去玩耍，而就在昨天，文化和旅游部最新公布的《在线旅游经营服务管理暂行规定》将于今年10月1日起正式施行，其中特地声明了禁止大数据的杀熟的行为，那么大数据都干了些什么，让的文化和旅游部门专门提醒呢？

Hello 大家好，我是鸭血粉丝，想必看到标题你们就猜到了，阿粉这次又写 bug 了，不过这次不是直接把服务器搞挂了，而是多写了一个判断导致线上业务接口少下放了一条链接数据，没有这个链接，就会导致线上的数据跟其他合作方对不上，换句话说就是会收不到钱！收不到钱意味着就是损失。

有人问阿粉，有个程序媛女朋友是一种什么体验。阿粉虽然没有，但是身边有案例，这不为了满足大家的好奇心，去问了一圈，结果问下来之后，阿粉酸了…

程序员 A ：你问我有个程序媛女朋友是啥体验？第一体验就是脱单了！还有什么体验比这更好么？

阿粉摸了摸自己的头发，默默的低下了头

程序员 B ：记得有次跟我女朋友表白，告诉她我爱她，在我心里她永远都是第一位的，结果遭到她的质问，在我心里谁是第零？！！！

程序员 C ：我女朋友就是程序媛，然后有次她在家也加班来着，让我帮忙看一下代码

“你为啥要用要敲空格键呢？用 tab 键不香么？”“用空格键不管怎么看，格式都不会变”“怎么会有人用空格？空格键除了制造噪音外哪里比 tab 强了，而且我跟你讲，用 tab 键可以让减少文件的占用空间”“我就用空格键怎么了，我就爱用怎么了”“你是老大，代码自己看吧”

程序员 D ：什么体验么？和程序媛在一起，周末的时候就不是逛街了，是对着撸代码，时不时再吐吐槽对方的代码写的都是啥

阿粉想到周末都是自己在看技术视频，我的眼泪才没有流下来，我明明在笑…

程序员 E ：我调试喜欢打 log ，女朋友调试喜欢打断点，每次都是她求我让我帮忙看看她的程序，然后调着调着我俩就开始抢笔记本了，“你给我，你这么写不行，给我我来写”“不要，我觉得是这里的问题，让我再试试，肯定是这里的问题”“不对不对，不是那里的问题，我有思路，把笔记本给我，我给你写”……到最后我俩差点儿打起来，好委屈，刚开始不是她来求我的么，而且还要嘲笑我一番喜欢打 log ，调试明明打 log 无敌好吧……

程序员 F ：乖，咱们左括号换个行成不

对方：不要！！！

遇上这么一个女朋友，我能怎样？

程序员 G ：最大的体验就是，平时的饭就不要想着在家吃了，特别是晚饭，在家吃是不可能的，因为 50% 的概率大家都加班， 50% 的概率一个人等另一个人加班

最后一条笑到你了吗？你有没有什么想要和阿粉聊聊的？

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，阿粉的服务再也没有担心过服务注册和发现以及配置管理混乱的问题了。

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. 最后来张流程图：