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

都说牛市来了，今年的 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 的一次契机。

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

StackOverflow 发布了 2021 年度开发者调查报告，整个调查问卷参与人数达到八万多，来自全球 180 多个地域。问卷内容包含基本信息，教育、工作经历，用到的技术相关，社区相关，人口相关，最终问题六个部分，每个部分由多个随机问题组成。涉及到的问题有受访者的所在地域，工作年限，薪资水平，性别，性取向，以及用到的语言和工具等。

随着开学季的到来，金九银十也来了，马上又到了新一波的跳槽季，本篇文章阿粉帮大家梳理了一下 2021 年以来 Java 极客技术原创的 80 篇优质文章，包含 Java / JVM、组件如 MySQL，Redis 队列、以及面试技巧和面试题，还有设计模式、软件设计、常用工具和技术成长相关的优质文章，内容较多，一下子肯定看不完，先收藏起来慢慢看。如果觉得有收获，欢迎分享，点赞，在看，评论四连！话不多说，请慢慢享用！

Hello 大家好，相信大家跟阿粉一样，在成为卓越的 Java 程序员的路上从未停止过学习，作为一个 Java 程序员还有很多我们需要学习的东西，特别是在这样一个技术快速发展的时期可能昨天还在流行的技术，转眼就已经落后了。那么在 2021 年已经接近尾声的时候有哪些技术我们可以继续不断的学习呢？

Hello 大家好， 我是阿粉，最近在写文章提交到 GitHub 的时候突发发现提交不上去，仔细一看原来是 GitHub 不支持密码验证了，熟悉 GitHub 的朋友都知道 GitHub 的仓库除了可以用 SSH 方式拉取之外还可以使用 HTTPS 的方式拉取，并且通过账号和密码进行提交。阿粉之前的项目就是使用 HTTPS 的方式来拉取，现在不让使用密码来进行提交了，突然就用不了了。

Hello 大家好， 我是阿粉，不知道你有没有遇到过这种场景，线上服务跑了一段时间过后偶尔会出现问题，光靠代码和数据分析找不到原因，而且这种情况也不是很常见所以对应的代码也没有加日志输出，如果说重新加上日志进行发布的话，就会破坏现场只能再等一段时间了，或者有的时候想看下接口的参数，从而判断接口参数有没有问题。

这个时候就在想有没有一个好的方法，可以不用重新修改源代码也不用发布升级就可以增加一些日志看到运行状态和入口参数呢？答案当然是肯定的，下面我们就来看一下神器 BTrace！

阿粉相信大家肯定所有的开发者都对Java8里面的所有的东西都感兴趣，虽然目前的 JDK 已经更新到 JDK17 了，但是阿粉相信，现在很多公司使用的还都是 JDK8 甚至是 JDK7，但是，就算是有些公司已经升级到 JDK8 但是对于 JDK8 里面的一些东西的使用，却没有使用的淋漓尽致。阿粉今天就给大家放出几个 JDK8 里面比较好用的。

JDK8

大家都是知道 JDK8 就开始使用 Lambda 表达式，但是很多不管是在教程上还是在其他的书籍上，都没有说在实际开发的时候去使用上这个 Lambda 表达式，而且包括 JDK8 里面的一些新的类，也都没有引入，所以阿粉在这里想要给大家安利一波使用方面的知识。

JDK8 – Optional类

这个类对于大家来说，是一个非常重要的类，不知道大家有没有被 java.lang.NullPointerException 疯狂的折磨过，不管是新人开发还是老开发，遇到这个问题的时候，都是头大的很，因为我们要在代码里面去疯狂的判断是否是null，如果不是 null 需要怎么处理，如果是 null 需要怎么处理，反正就是你要是想解决 java.lang.NullPointerException 这个问题，就免不了去加一些判断条件，而 Optional 这个类，则是帮你优雅的处理 null 的问题。

我们先看一组 Java7 中的一些判断空的实现：

1
2
3
4
5
6
7
8
9

 User user = usersMapper.selectUserById(userId);
 String userName = user.getUserName();
    if(user!= null){
        if(userName != null && !userName.isEmpty()){
                .....
              }
    }
  

阿粉相信大家一定都写过这个样子的代码，因为我们不知道SQL查询出来的数据中是否包含了我们的 Users 对象，如果要是 Users 对象，那么就会无情的出现 java.lang.NullPointerException 这个空指针异常，这时候就很尴尬了，老开发一脸懵逼，我竟然还有的地方没有验证？

但是验证了之后，你就会发现代码量是非常的大，而且有点不太美观，我们再来对比一下 JDK8 中，给我们提供的方法来进行验证的方式。

1
2
3
4
5
6

User user = usersMapper.selectUserById(userId);
Optional.ofNullable(user)
        .map(User::getUserName)
        .ifPresent(userName->{
        ....
        }

大家看这种链式编程，ofNullable() 方法给我们提供了判断 user 是不是空，并且去校验 userName，如果存在，然后执行下面的逻辑，相比较 JDK7 的内容，相信大家看起来的话肯定是没有 JDK7 中的表现的那么的明显，但是大家看代码是不是发现已经被处理的妥妥的了。而且非常的优雅。

相信大家肯定都看过一些教程，上面会写到：

1
2
3
4

    User user = usersMapper.selectUserById(userId);
    Optional<User> userOptional = Optional.ofNullable(user);
    Optional<String> str = userOptional.map(User::getUserName);
    ....

但是相对于代码的可读性来说，我们肯定还是希望使用 JDK7 上面的判断来进行判断，但是这种 JDK8 的链式编程，在一定程度上减少了代码量，并且开发效率也会相对应的提升。

如果大家不信，我们可以来运行一下我们的代码，然后看一下效果。

1
2
3
4
5

Optional.ofNullable(user)
        .map(User::getUserName)
        .ifPresent(userName->{
            System.out.println("用户UserName不为空");
        });

大家看，是不是就出现了我们想要的结果，一个判断 null 的操作，瞬间变得高大上了，而且代码的逼格瞬间上升一个档次。

对于 Optional 类，在 Java8 实战中给出了很多的方法，阿粉也是给大家摘取了一下，做了个总结，

• ofNullable 方法 ：将指定值用Optional封装之后返回，如果该值为null，则返回一个空的Optional对象

• empty 方法 ：返回一个空的Optional实例

• filter 方法 ： 如果值存在并且满足提供的谓词，就返回包含该值的Optional对象；否则返回一个空的 Optional对象

• flatMap 方法 ： 如果值存在，就对该值执行提供的mapping函数调用，返回一个Optional类型的值，否则就返 回一个空的Optional对象

• get 方法 ：如果该值存在，将该值用Optional封装返回，否则抛出一个NoSuchElementException异常

• ifPresent 方法 ： 如果值存在，就执行使用该值的方法调用，否则什么也不做

• isPresent 方法 ： 如果值存在就返回true，否则返回false

• map 方法 ：如果值存在，就对该值执行提供的mapping函数调用

• of 方法 ： 将指定值用Optional封装之后返回，如果该值为null，则抛出一个NullPointerException异常

• orElse 方法： 如果有值则将其返回，否则返回一个默认值

• orElseGet 方法 ： 如果有值则将其返回，否则返回一个由指定的Supplier接口生成的值

• orElseThrow 方法 ： 如果有值则将其返回，否则抛出一个由指定的Supplier接口生成的异常

大家看这些方法是不是都有很多相似的，比如 map，flatMap，还有orElse，orElseGet，orElseThrow 方法

map 和 flatMap 比较：

这两个都是做 转换值 的操作，区别就是入参的类型不是一样的，map的入参是 Function<? super T, ? extends U> mapper 而 flatMap 入参则是 Function<? super T, Optional<U> > mapper 。

入参的不同也就导致了他们获取返回值也是不同的，map中获取的返回值自动被Optional包装，flatMap中返回值保持不变,但必须是Optional类型。

这么一看总是感觉不太对的样子，我们去源码里面看看是什么样子的。

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

map:

public<U> Optional<U> map(Function<? super T, ? extends U> mapper) {
        Objects.requireNonNull(mapper);
        if (!isPresent())
            return empty();
        else {
            return Optional.ofNullable(mapper.apply(value));
        }
    }


flatMap:

 public<U> Optional<U> flatMap(Function<? super T, Optional<U>> mapper) {
        Objects.requireNonNull(mapper);
        if (!isPresent())
            return empty();
        else {
            return Objects.requireNonNull(mapper.apply(value));
        }
    }

map 方法参数中的函数 mapper 输出的是值，然后 map 方法会使用 Optional.ofNullable 将其包装为 Optional；而 flatMap 要求参数中的函数 mapper 输出的就是 Optional。

一个是比较聪明的，另外一个就相对来说不是那么聪明了，人家会自己包装呀，是不是？

同样的比较还有 orElse，orElseGet，orElseThrow 但是这个阿粉就不再给大家絮叨了，因为上面的方法解释上都很明显的能看到了。

Lambda 表达式

Lambda 表达式实际上就是相当于是一个匿名内部类，他就是让我们开发的人把函数当成参数传递给某个方法，然后把代码当做数据去处理。

阿粉相信大家肯定都了解这块，就比如说下面的代码对比：

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

Java7:

    List<String> stringList = Arrays.asList("1", "2", "3");
        for (String st:stringList) {
            System.out.println(st);
        }

Java8:

Arrays.asList("1", "2", "3").forEach((String st)->{
            System.out.println(st);
        });

同样的一个循环，我们肯定想用第二种写法不是么？

Java8 实际上在从发布开始，很多公司都在用，但是也有很多人依旧选择是 Java7，因为不想改变自己的学习风格，阿粉相信大家如果是一个决心在开发领域一直做下去的人，那么肯定会保持一个不断学习的心，所以，你是这样的人么？

Hello 大家好，我是阿粉。不知道大家在日常的工作中有没有遇到这样的场景，很多时候业务数据有变更需要及时加载到缓存、ES 或者发送到消息队列中通知下游服务。

一般遇到这种情况下，在实时性要求不高的场景我们有两种处理模式，一种是写任务定时推送数据同步到缓存中，另一个是下游服务定时自动拉取。这两种模式都依赖服务自己的定时周期时间，很多时候不好设定具体要多久执行一次，定时时间太短在数据没有变化的时候会有很多无效的操作，如果定时时间太长可能很多时候数据的延迟会比较大，某些时候影响也不好。

那有没有一种比较好的方式可以解决这个问题呢？答案当然是肯定的。今天就给大家介绍一下 Canal，基于 MySQL 的 bin log 日志来实时监听数据变化。

Hello，大家好，我是阿粉，最近互联网大厂频繁有动静出来，先是滴滴被下架二十多款 APP，后面有快手，字节宣布取消大小周，再有京东宣布涨薪两个月，这边 7.13 号晚 B站也挂了。

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 设计与实现

在上篇文章中，我们详细的介绍了 Quartz 的架构原理与单体应用，今天我们一起来分享一下 quart 的分布式调度和实践

在上篇文章中，我们深入的介绍了单机版本定时任务的实现原理，今天我们继续来点干活，介绍在平时使用最多的一个定时任务框架 Quartz！