redis 在项目中用的话，主要就是用作缓存了

网络爬虫技术，早在万维网诞生的时候，就已经出现了，今天我们就一起来揭开它神秘的面纱！

前天的时候，也就是国庆刚刚过的几天的时候，一个之前在学校的小学弟在问阿粉，说现在想入行当程序员，需要准备什么样子的知识，于是阿粉就给他提出了一些意见，比如先掌握好基础，然后代码规范，以及之后的框架什么的，这时候，小学弟问了一句，对英语的要求高么？阿粉说英语不太好的话，问题不太大，但是还是要学习英语的。

能想起来几种呢？

长假第一天，不知道各位小伙伴玩的可好?

阿粉就比较惨了，刚买好的回家的动车票，领导就告知长假前两天还需要加班，赶下项目的进度。

本来还想吐槽抱怨的，不过听到领导说国庆加班三倍工资，哎，算了算了，辛苦一点算什么？为公司服务~

哈哈，幸好今年长假有八天，少了两天也无妨。

好了，不扯这个了，不知道各位出去玩之路，是否顺利？是不是也堵在路上了？

1、序

在实际项目中，有时为了响应速度，难免会对一些高清图片进行一些处理，比如图片压缩之类的，而其中压缩可能就是最为常见的。最近，阿粉就被要求实现这个功能，原因是客户那边嫌速度过慢。借此机会，阿粉今儿就给大家介绍一些一下我做这个功能时使用的 Thumbnailator 库。

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

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

前言

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

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

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

1. 帮助我们理解知识

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

2. 获得成就感

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

3. 提高影响力

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

4. 面试加分项

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

后话

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

Hello，大家好，我是鸭血粉丝~

最近看同事的代码时候，学到了个小技巧，在某些场景下非常挺有用的，这里分享一下给大家。

Spring 中 @Autowired注解，大家应该不会陌生，用过 Spring 的肯定也离不开这个注解，通过这个注解可以帮我们自动注入我们想要的 Bean。

除了这个基本功能之外，@Autowired 还有更加强大的功能，还可以注入指定类型的数组，List/Set 集合，甚至还可以是 Map 对象。

比如说当前应用有一个支付接口 PayService,分别需要对接支付宝、微信支付、银行卡，所以分别有三个不同实现类 AliPayService,WechatPayservice,BankCardPayService。

四个类的关系如下图所示：

如果此时我需要获取当前系统类所有 PayService Bean，老的方式我们只能通过 BeanFactory或者 ApplicationContext 获取。

1
2
3
4
5
6
7
8
9
10
11

// 首先通过 getBeanNamesForType 获取 PayService 类型所有的 Bean
String[] names = ctx.getBeanNamesForType(PayService.class);
List<PayService> anotherPayService = Lists.newArrayList();
for (String beanName : names) {
    anotherPayService.add(ctx.getBean(beanName, PayService.class));
}
// 或者通过 getBeansOfType 获取所有 PayService 类型
Map<String, PayService> beansOfType = ctx.getBeansOfType(PayService.class);
for (Map.Entry<String, PayService> entry : beansOfType.entrySet()) {
    anotherPayService.add(entry.getValue());
}

但是现在我们可以不用这么麻烦了，我们可以直接使用 @Autowired 注入 PayService Bean 数组，或者 PayService List/Set 集合，甚至，我们还可以注入 PayService 的 Map 集合。

1
2
3
4
5

@Autowired
List<PayService> payServices;

@Autowired
PayService[] payServicesArray;

知道了这个功能，当我们需要使用 Spring 实现策略模式就非常简单。

可能有的小伙伴不太了解策略模式，没关系，这类阿粉介绍一个业务场景，通过这个场景给大家介绍一下策略模式。

还是上面的例子，我们当前系统需要对接微信支付、支付宝、以及银行卡支付。

当接到这个需求，我们首先需要拿到相应接口文档，分析三者的共性。

假设我们这里发现，三者模式比较类似，只是部分传参不一样。

所以我们根据三者的共性，抽象出一组公共的接口 PayService，

1
2
3

public interface PayService {
    PayResult epay(PayRequest request);
}

然后分别实现三个实现类，都继承这个接口。

那么现在问题来了，由于存在三个实现类，如何选择具体的实现类？

其实这个问题很好解决，请求参数传入一个唯一标识，然后我们根据标识选择相应的实现类。

比如说我们在请求类 PayRequest 搞个 channelNo 字段，这个代表相应支付渠道唯一标识，比如说支付宝为：00000001,微信支付为 00000002，银行卡支付为 00000003。

接着我们需要把唯一标识与具体实现类一一映射起来，刚好我们可以使用 Map 存储这种映射关系。

我们实现一个 RouteService，具体代码逻辑如下：

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

@Service
public class RouteService {

    @Autowired
    Map<String, PayService> payServiceMap;

    public PayResult epay(PayRequest payRequest) {
        PayService payService = payServiceMap.get(payRequest.getChannelNo());
        return  payService.epay(payRequest);
    }

}

我们在 RouteService 自动注入 PayService 所有相关 Bean，然后使用唯一标识查找实现类。

这样我们对外就屏蔽了支付渠道的差异，其他服务类只要调用 RouteService 即可。

但是这样实现还是有点小问题，由于我们唯一标识为一串数字，如果像我们上面直接使用 @Autowired注入 Map,这就需要我们实现类的 Bean 名字为 00000001 这些。

但是这样命名不是很优雅，这样会让后来同学很难看懂，不好维护。

所以我们需要做个转换，我们可以这么实现。

首先我们改造一下 PayService 这个接口，增加一个方法，每个具体实现类通过这个方法返回其唯一标识。

1
2
3
4
5
6

public interface PayService {

    PayResult epay(PayRequest request);

    String channel();
}

具体举个支付宝实现类的代码，其他实现类实现类似。

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

@Service("aliPayService")
public class AliPayService implements PayService {

    @Override
    public PayResult epay(PayRequest request) {
        // 业务逻辑
        return new PayResult();
    }
    @Override
    public String channel() {
        return "00000001";
    }
}

最后我们改造一下 RouteService，具体逻辑如下：

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

@Service
public class RouteService {

    @Autowired
    Set<PayService> payServiceSet;
    
    Map<String, PayService> payServiceMap;

    public PayResult epay(PayRequest payRequest) {
        PayService payService = payServiceMap.get(payRequest.getChannelNo());
        return  payService.epay(payRequest);
    }

    @PostConstruct
    public void init() {
        for (PayService payService : payServiceSet) {
            payServiceMap = new HashMap<>();
            payServiceMap.put(payService.channel(), payService);
        }
    }
}

上面代码首先通过自动注入 ` PayService 一个集合，然后我们再将其转为一个 Map`，这样内部存储刚好是唯一标识与实现类的映射了。

好了，今天的小技巧就分享到这里，学到小伙伴，不妨点个赞吧。

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

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

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

朋友 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% 的概率一个人等另一个人加班

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

哎，最近阿粉又双叒叕犯事了。

事情是这样的，前一段时间阿粉公司生产交易偶发报错，一番排查下来最终原因是因为 Redis 命令执行超时。

可是令人不解的是，生产交易仅仅使用 Redis set 这个简单命令，这个命令讲道理是不可能会执行这么慢。

那到底是什么导致这个问题那？

为了找出这个问题，我们查看分析了一下 Redis 最近的慢日志，最终发现耗时比较多命令为 keys XX*

看到这个命令操作的键的前缀，阿粉才发现这是自己负责的应用。可是阿粉排查一下，虽然自己的代码并没有主动去使用 keys命令，但是底层使用框架却在间接使用，于是就有了今天这个问题。

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