这不过年了，有的朋友就和阿粉说，不敢吃辣，阿粉就有点儿懵了，咋了呀，为啥不敢吃辣嘞

手把手教

Redis 作为当代互联网行业无可替代的 Key-Value 数据库，在我们日常的工作中占据主要的角色，对于常用的命令相信大家都很熟悉。今天给大家分享一个平时可能用到的少，但是也很重要的一个类型 BitArray。我们先通过简单的命令使用，了解该命令的用法，然后再给大家介绍一下底层的实现原理，帮助大家更好的了解。

简单使用

我们先看下什么是BitArray 位数组。Redis 使用字符串对象来存储位数组，一个 Byte 字节有 8 个 bit 位，通过控制每一个 bit 位为 0 或者 1来表示某个元素对应的值或者状态。通过使用 8 个 bit 位可以对复杂操作节省很多的空间。BitArray 相关的操作命令有 SETBIT,GETBIT,BITCOUNT,BITOP。下面我们依次看下命令的使用，最后再看下实现的原理。

首先我们在本地启动一个 Redis 实例，再启动一个客户端去链接如下图，

通过redis-cli 链接客户端，执行相应的命令，接下来使用一下 BitArray 相关的命令，

通过setbit test 2 1 命令我们创建了一个名为 test 的 bitarray 并将其第二位设置成 1，再使用getbit test 2 获取对应位的值。setbit命令功能是将对应的 key 指定 offset 的位置设置为 1 或 0，getbit 命令是获取指定 offset 位置的值。test 是一个位数组通过上面的命令值变成0000 0010 。

接下来我们再创建一个名为test2的位数组，并且通过多次使用 setbit 命令和 bitcount ，bitcount 命令的作用是用来统计位数组中 1 的个数，通过下面我们看到第一次使用 bitcount test2 命令时结果为 1，当使用了 setbit test2 1 1 命令后再次使用 bitcount 命令我们发现结果已经变成 2 了。其中 test2 的刚开始是0000 0100 后面变成0000 0101。

bitop 命令相信大家都能理解，都是一些与，或，异或，非的运算，就不赘述了，具体使用可以看上图。

原理

前面说到 Redis 是通过字符串对象来实现位数组的，所以字符串对象有的功能，在位数组上面都是有的，在Redis 底层位数组的存储结构也是基于 SDS （简单动态字符串）的，如下：

其中 len 字段表示包含的 buf 数组的个数，buf[i] 表示的是第i个字节数组里面具体的数值，buf[len] 是末尾的分隔符\0 。上图中的buf[0] 是一个字节，其中有 8 个 bit 位，在使用了 setbit 命令后初始值为0000 0000，buf[1] 中就是分隔符\0。

SETBIT

当我们执行setbit key offset value 命令时，我们分两步：

1. 计算出创建多少个字节数组(offset / 8) + 1；
2. 判断是否长度不够需要进行扩容；
3. 计算出 offset 对应的字节位置 byte = offset / 8;
4. 计算出 offset 对应的 bit 位，bit = (offset mod 8) + 1;
5. 根据 offset 找到对应的位置将此处的值改成value 并返回旧值；

假设我们执行的命令时setbit test2 3 1，第一步先计算字节个数 (3 / 8) + 1 = 1，计算出来我们只需要一个字节；第二步跟原始 len 进行比较，发现不需要扩容；3. 根据 offset 计算存放的字节 3 / 8 = 0 则，存放的 buf[0] 中；第四部计算 bit，( 3 mod 8) + 1 = 4，表示的是第四个 bit 位。经过一轮 test2 就变成了 0000 1000。

setbit 命令执行的操作都是常数级别的，时间复杂度为 O(1)。

GETBIT

我们知道的setbit 命令是如何实现的，那么getbit 命令也就知道如何计算了，过程是类似的。

1. 找到对应的字节数组 byte = offset / 8;
2. 计算出对应的 bit 位bit = (offset mod 8) + 1;

经过上面的计算我们可以知道当执行命令 getbit test2 3 的时候，先算出 3 / 8 = 0 ，找到 buf[0]，再使用(3 mod 8) + 1 = 4，找到 bit 位。

看到这里细心的小伙伴就会有疑问，会说不对啊，根据这个计算返回的值应该是 0 啊，因为上面 setbit命令执行完的结果是0000 1000 啊。

能发现这个问题的小伙伴说明很用心在看了，这里就要跟大家说下了，虽然 setbit 命令执行完结果是0000 1000 但是在 buf[0] 中存储的确实反过来的，即为0001 0000。采用的是逆序的方式来保存位数组的。

之所以采用逆序保存位数组是为了减少位数组的移动，提高性能，感兴趣的小伙伴可以自行研究一下。

BITCOUNT 命令

bitcount 命令是用来计算一个位数组中 1 的个数，说起来比较简单，但是实现起来却很有讲究。我们设想一下，统计一个位数组中 1 的个数有多少个，最简单的办法就是遍历，依次累加。但是当我们的位数组很大的时候，整个效率就会变得非常慢，因为遍历是跟长度正相关的，当存放 100MB 的位数组整个遍历需要八亿次。而当达到 500MB 时整个遍历就达到了四十亿次！

在 Redis 中采用的是查表和 variable-precision SWAR 算法，查表是指当位数组长度小于 128 时，直接根据预设的映射表找到对应 1 的个数，直接返回。而variable-precision SWAR 算法相对比较复杂，阿粉也还要再研究研究，今天就先不分享了。

BITOP 命令

bitop 命令相对简单一点，因为 Redis 底层是基于 C 语言实现的，C语言本身就支持相关的逻辑运算。因为本身就是二进制位数组，所以对应的逻辑运算会简单很多就不赘述了，相信大家都能理解。

参考资料

Redis 设计与实现（第二版）

Hello 大家好，我是阿粉，相信最近大家都看到郑爽父亲的那个道歉视频，原本这件事情已经过去了，但是这则道歉视频里面的大大的某品牌 Logo 闪瞎了阿粉的狗眼，话不多说，见下图。

说真的这种负面新闻正常的品牌应该都是退而避之，恨不得立马躲得远远的，像之前的任何娱乐圈的人出了事，各大代言的品牌都立马下架商品，而某度的这种“迎难而上”的做法，真的让人不能理解。

事情发酵的很快，随着道歉视频的出来，很多网友都发现了这个品牌的 Logo ，一时间各种批判的声音都出来了，而且据说这个事情在百度内部的高管群里都被讨论了。随后某度官微也出来道歉了，表示说诚恳的接受大家的批判，而且在这个视频中出现 Logo 不涉及任何经济行为，其中的细节作为局外人阿粉就不了解了，有没有经济行为大家自行脑补就行。

文中提到会诚恳接受大家的批评，对给网友带来的不好感受表示非常抱歉，并强调这个视频访谈不涉及任何经济行为，昨天第一时间在相关账号中下线了该内容。还表示：“孩子的话题背后公众表达的是同理心、同情心，人们希望的是事情得到最好的解决。关切越深期待越高，我们必将在未来的工作中加倍严谨、严肃，充分考虑每一位朋友的感受。“经过处理过后，部分网上的视频都做了打码处理，屏蔽了相关文字信息。

相关的道歉视频大家可以公众号后台回复【道歉】查看

我们都知道这么做是不对的，因为大家都知道品牌效应，一个品牌的 Logo 代表了一个品牌的价值观。为什么那些大牌在代言人出现负面新闻的时候都紧急下线商品，并且解约呢？这是因为如果不这样做就会影响到品牌的形象，而对于一个品牌来说，一旦品牌的形象受到负面影响那将会是重大损失，很有可能一去不复返。虽说当今的互联网是流量的时代，得流量者得天下，但是获取流量也不能通过蹭这种负面新闻的热度来获取，这种行为只会让人更加厌恶。

Hello 大家好，我是阿粉，作为 Java 工程师，数据库用的最多的肯定是 MySQL，而对于 MySQL 公号前面也发过很多文章，感兴趣的可以去翻翻。今天阿粉主要是想通过 LeetCode 上面的一个题目来再带大家看看 MySQL 的变量使用以及通过 Explain 的解析看看SQL 的执行过程。虽然平时在工作中对于 MySQL 使用的很多，但是相对于 MySQL 的变量使用相对还是较少的，所以阿粉在刚看到的时候还是有点懵的，不过我相信大家肯定不会像阿粉一样，毕竟能关注我们公众号的读者都是优秀的。

最近“拼多多”这是一直在风口浪尖上了，舆论的旋涡那是一层接着一层，员工猝死，员工跳楼自杀，员工发言开除员工，操纵用户手机删除本地保存的图片等一系列的事件，让“拼多多”一直保持在热搜的位置上。

阿粉元旦的时候去看了一部电影，心灵奇旅。

先说明这篇文章不包含任何广告内容，也不提供任何投资理财建议，股市有风险，投资需谨慎！

都说牛市来了，今年的 A 股的行情确实很不错，从上面的截图中可以看到阿粉的一只基金已经收益 90% 了。90% 是什么概念，估计连股神巴菲特都没有过，所以这几天阿粉慌的一批，除了慌的很之外，另一个就是懊悔的很，当初应该多买点的，只能说人性是贪婪的。

上一次的文章中，阿粉在面试官面前说了对启动流程不太理解，然后和他聊了一会，然后他又提出了你既然不是特别了解启动流程的话，那你对Tomcat的生命周期熟悉么？

昨天团队里的妹子很突然地就让阿粉跟她说说怎么才能写出一手好的代码

Hello,大家好，我是阿粉~

『上班 996，下班 ICU！』这是 2019 年上半年的热门事件，那个时候整个互联网圈子都在抵制 996，抵制无良公司。

不过随着 2020 年疫情开始，外部环境变得很差， 越来越多人无奈接受了 996 ，这个话题开始慢慢淡出了视野。

不过，最近两天 996 话题再次引爆互联网，又一上了热搜了，而事情的真实起因说起来真的令人心痛。

1 月 3 号下午，网友在脉脉平台爆料，拼多多员工在凌晨一点半下班回家路上晕倒猝死。

据网上爆料信息，这位拼多多员工是 98 年，年仅 22 岁，19 届毕业，内部花名润肺，从事拼多多新疆买菜项目的招商相关岗位。

2020 年的12 月 29 日凌晨一点半，下班路上突然晕倒，经过抢救无效去世。

事情爆料出来之后，热度越来越高，一晚上的时间该话题达到了近千万的热度，知乎话题被顶到热门，而微博 996 ，拼多多等话题也被顶上了热搜。

随后脉脉上又有内部员工爆料，拼多多 HR 正在开始删帖。

这个套路是不是很熟悉？

撤热搜，降热度，删帖子，互联网大厂对待大众舆论一套组合拳。

如果事情就到此为此，也许就没么魔幻！

2021 年 1 月 4 日早上，疑似拼多多官方知乎账号发表回应，不过 1 分钟之后就被秒删。

不过互联网都是有记忆的，许多知乎网友都看到这个回答，截图传播。

仔细看下这个回答，这什么意思❓❓❓

这是想表达 猝死=以命换钱=努力吗❓❓❓

这真的是经过脑子吗❓❓❓

随后 2020 年 1 月 4 号下午拼多多官方回应：“我们心痛如绞，我们爱你，深深的想念你。”

然后又进行辟谣，称其从未发布过上面的截图。

本来事情也许就到此为止了，官方都发声明辟谣了，但是网上那些截图真的是伪造吗？

如果真的是假的，那么作为这张截图的源头知乎，起码也要负相关的责任。

拼多多这是要把黑锅甩给知乎啊，不过知乎没怂，选择了硬刚。

知乎小管家拿出了后台数据，时间精确到了秒，啪啪打了拼多多的脸，砍了拼多多一刀。

不得不说，知乎🐂🍺。

事情的最后，拼多多最终发布道歉声明，把锅甩给了一个合作供应商的员工。

这个套路有没有感觉让人很熟悉❓❓❓

好像每次看到热点新闻，都是临时工默默抗下所有！

现在开始回顾一下这件事，拼多多这波公关，怎么说呢，真的……负分。

先是谎称官方好回答是谣言，被辟谣之后又说是营销合作方的锅，是他们在乱搞。

最后还让一个员工手写新来澄清。

一个官方的号都不能让人相信的话，这个官方号还有啥用，还有公信力吗？

建议早点换个公关团队吧。

拼多多为什么这么忙？

去年十月，拼多多五周年的时候，黄峥在内部发表称拼多多全员都要「开启硬核奋斗模式」。

什么是硬核奋斗模式？

很多大厂开始大小周的上班方案，相比这个，拼多多更加狠，据网上爆料拼多多推出超级版的大小周方案，大周 7 天，小周 6 天。

这么计算下来，每个月就休息两天。

另外据说拼多多买菜业务全年无休，今年的春节假期很有可能也是不放假！！！

这真的很硬核！！！

可能很多人不了解拼多多买菜业务，简单解释一下，其实就是社区团购业务，最近非常火热。

京东、滴滴、美团、阿里叫的上名的互联网大厂都来参了一手。

拼多多将买菜业务列为重点项目，倾其所有资源投入，All in 买菜。

也许正因为竞争太激烈，所有人都想在这个赛道抢到头筹，争取跑的比竞争对手快，所以开始无止尽的加班，无止尽压榨底层员工。

最后

其实写到这里，阿粉觉得真的有点无奈，身处现在互联网圈子，感觉个体力量真的很渺小。我们只能被资本摆布，只能逼着去 996。

不过即使这样，阿粉还是要发声，让这件事能被更多的读者看到。

哎，真的很痛心！希望这次事件能成为大家反抗 996 的一次契机。

最后提醒大家一下，真的要注意一下自己的身体健康，平时有时间的话还是要适当运动一下，毕竟身体是我们自己的。

阿粉最近在疯狂的研究各种用的工具里面的源码实现，之前给大家都专门的去扣了一下 JDK 里面自带的exe程序，这次阿粉开始更加无聊，直接开始搞Tomcat。

Hello，大家好，我是阿粉，天气越来越冷了，但是再冷的天也不能阻挡阿粉学习的心，今天大家就跟着阿粉一起来学习一下 Redis 的数据持久化吧。

最近，北京的疫情开始零散出现，顺义区宣布进入战时状态；党政机关人员不经批准不允许离京；对于普通民众，提议非必要不离京，建议市民在京过年。

Hello，大家好，我是阿粉~

上次我们分享 Redis 字符串的底层原理，今天我们再来看下 Redis List 列表的底层原理。

Redis List 命令

Redis List 列表支持的相关指令比较多，比如单个元素增加、删除操作，也支持多个元素范围操作。

Redis List 列表支持列表表头元素插入/弹出(LPUSH/LPOP)，也支持表尾元素插入/弹出(RPUSH/RPOP)。

另外 Redis List 列表还支持根据下标(LINDEX )获取元素，也支持根据根据下标覆盖相应的元素(LSET )。

除此之外，Redis List 列表还支持的范围操作，比如获取指定范围内全部元素(LRANGE )，移除指定范围内的全部元素(LTRIM )。

了解完的 Redis 相关指令，我们来看下 Redis List 列表底层实现方式，使用两种数据结构：

• 压缩列表(ziplist)
• 双向列表(linkedlist)

ps:本篇文章基于 Redis 3.2 开始进行讲解

双向列表(linkedlist)

上面我们知道了List 列表支持表头/表尾元素的插入/弹出，这类操作使用链表那就非常高效，时间复杂度为 O(1)。

Redis 双向列表(linkedlist) 由两个结构构成：

• list
• listnode

结构如下：

list 结构体中保存了表头节点，表尾节点以及链表包含的节点的数量，正因为如此操作表头/表尾元素的插入/弹出，链表长度的计算将会非常高效，时间复杂度为O(1)。

listnode结构体中除了保存节点的值以外，还会保存前后节点的指针，这样如果需要获取某个节点的前置节点与后置节点也会非常高效，时间复杂度为O(1)。

另外如果需要指定位置插入/删除元素，那么只需要变动当前位置节点前后指针即可，这个插入/删除操作复杂度为O(1)。

不过需要注意了，插入/删除动作前提我们需要找到这个指定位置，这个查找动作我们只能遍历链表，复杂度为O(N)，所以插入/删除的复杂度为O(N)。

双向列表(linkedlist)除了用作在列表键以外，还广泛用于发布/订阅，慢查询等内部操作。

既然双向列表(linkedlist)可以满足列表键的操作，那为什么 Redis 列表还采用其他的数据结构？

其实主要是因为内存占用问题，双向链表由于使用两个结构体，而这两个结构体都需要保存一些必要信息，这必然将会占用部分内存。

而当元素很少的时候，如果直接使用双向链表，内存还是比较浪费的。所以 Redis 引入压缩列表。

压缩列表

压缩列表是 Redis 为了节约内存而开发，它由一系列的特殊编码的的连续内存块组成的顺序型数据结构，整体结构如下：

从上面结构可以看出来，压缩列表实际上类似与我们使用的数组，数组中每一个元素保存一个数据。

不过与数组不同的是，压缩列表的表头存在三个字段

• zlbytes 代表列表长度
• zltail代表列表尾节点距离压缩列表起始地址的偏移量
• zllen代表压缩列表的节点的个数

另外压缩列表的表尾还有一个字段，zlend里面保存一个特殊的值， OXFE，用于标记压缩列表的末端。

一个压缩列表可以由多个节点构成，每个节点可以保存整数值或字节数组，结构如下：

使用压缩列表，如果查找定位表头元素，我们只需要使用压缩列表起始地址加上表头三个字段长度就可以直接点位，查找非常快，复杂度是 O(1)。

而压缩列表的最后一个元素，查找起来也非常轻松，我们使用压缩列表起始地址加上zltail包含的长度就可以直接点位，查找也非常快，复杂度是 O(1)。

至于列表中的其他元素，就没有这么好运了，我们只能从第一个元素或者最后一个元素，遍历列表查找，此时的复杂度就是 O(N) 了。

另外压缩列表的新增、删除元素，都将会导致重新分配内存，效率不高，平均复杂度为 O(N)，最坏福复杂度为 O(N^2)。

编码转换

当我们创建一个 Redis 列表键，如果同时满足以下两个条件，列表对象将会使用压缩列表作为底层数据结构

• 列表对象保存的所有字符串元素的长度都小于 64 字节
• 列表对象中保存的元素数量小于 512 个

如果不能同时满足这两个条件，那么默认将会使用双向列表作为底层数据结构。

小结

Redis 列表底层使用两种数据结构，压缩列表与双向链表。

压缩列表由于使用了连续内存块，内存占用少，并且内存利用率高，但是新增、删除由于涉及重新分配内存，效率不高。

双向列表呢，新增、删除元素非常方便，但是由于每个节点都是独立的内存快，内存占用比较高，且内存碎片化严重。

这两种数据结构在表头/表尾插入与删除元素，都十分高效。但是其他操作，可能就效率较低。

所以我们使用 Redis 列表，一定要因地制宜，可以将其当做 FIFO 队列，这样仅使用 POP/PUSH ，效率将会很高。

参考资料

1. Redis 设计与实现

3分钟带你搞定SpringBoot中Schedule

定时任务，可以说是业务系统必不可少的一个部分，今天我们就一起来了解一下 JDK 定时任务实现及原理分析。