前言

标题没有看错，真的是让我写个 bug！

刚接到这个需求时我内心没有丝毫波澜，甚至还有点激动。这可是我特长啊；终于可以光明正大的写 bug 了🙄。

先来看看具体是要干啥吧，其实主要就是要让一些负载很低的服务器额外消耗一些内存、CPU 等资源（至于背景就不多说了），让它的负载可以提高一些。

前言

最近有朋友问我这么一个面试题目：

现在有一个非常庞大的数据，假设全是 int 类型。现在我给你一个数，你需要告诉我它是否存在其中(尽量高效)。

需求其实很清晰，只是要判断一个数据是否存在即可。

但这里有一个比较重要的前提：非常庞大的数据。

前言

之前写过一篇《从源码分析如何优雅的使用 Kafka 生产者》 ，有生产者自然也就有消费者。

建议对 Kakfa 还比较陌生的朋友可以先看看。

就我的使用经验来说，大部分情况都是处于数据下游的消费者角色。也用 Kafka 消费过日均过亿的消息（不得不佩服 Kakfa 的设计），本文将借助我使用 Kakfa 消费数据的经验来聊聊如何高效的消费数据。

前言

磨了许久，借助最近的一次通宵上线 cicada 终于更新了 v2.0.0 版本。

之所以大的版本号变为 2，确实是向下不兼容了；主要表现为：

• 修复了几个反馈的 bug。
• 灵活的路由方式。
• 可拔插的 IOC 容器选择。

其中重点是后面两个。

背景

最近时运不佳，几乎天天被线上问题骚扰。前几天刚解决了一个 HashSet 的并发问题，周六又来了一个性能问题。

大致的现象是：

我们提供出去的一个 OpenAPI 反应时快时慢，快的时候几十毫秒，慢的时候几秒钟才响应。

尝试解决

由于这种也不是业务问题，不能直接定位。所以尝试在测试环境复现，但遗憾的测试环境贼快。

没办法只能硬着头皮上了。

中途有抱着侥幸心里让运维查看了 Nginx 里 OpenAPI 的响应时间，想把锅扔给网络。结果果然打脸了；Nginx 里的日志也表明确实响应时间确实有问题。

背景

上午刚到公司，准备开始一天的摸鱼之旅时突然收到了一封监控中心的邮件。

心中暗道不好，因为监控系统从来不会告诉我应用完美无 bug，其实系统挺猥琐。

打开邮件一看，果然告知我有一个应用的线程池队列达到阈值触发了报警。

由于这个应用出问题非常影响用户体验；于是立马让运维保留现场 dump 线程和内存同时重启应用，还好重启之后恢复正常。于是开始着手排查问题。

万万没想到 JCSprout 截止目前居然有将近1.6W star。真的非常感谢各位大佬的支持。

年初时创建这个 repo 原本只是想根据自己面试与被面试的经历记录一些核心知识点，结果却是越写越多。

前言

在上文《一份针对于新手的多线程实践》留下了一个问题：

这只是多线程其中的一个用法，相信看到这里的朋友应该多它的理解更进一步了。

再给大家留个阅后练习，场景也是类似的：

在 Redis 或者其他存储介质中存放有上千万的手机号码数据，每个号码都是唯一的，需要在最快的时间内把这些号码全部都遍历一遍。

有想法感兴趣的朋友欢迎在文末留言参与讨论🤔🤨。

网友们的方案

前言

前段时间在某个第三方平台看到我写作字数居然突破了 10W 字，难以想象高中 800 字作文我都得巧妙的利用换行来完成(懂的人肯定也干过😏)。

干了这行养成了一个习惯：能撸码验证的事情都自己验证一遍。

于是在上周五通宵加班的空余时间写了一个工具：

https://github.com/crossoverJie/NOWS

利用 SpringBoot 只需要一行命令即可统计自己写了多少个字。

1

java -jar nows-0.0.1-SNAPSHOT.jar /xx/Hexo/source/_posts

前言

近期在做 Cicada 的拦截器功能，正好用到了责任链模式。

这个设计模式在日常使用中频率还是挺高的，借此机会来分析分析。

责任链模式

先来看看什么是责任链模式。

引用一段维基百科对其的解释：

责任链模式在面向对象程式设计里是一种软件设计模式，它包含了一些命令对象和一系列的处理对象。每一个处理对象决定它能处理哪些命令对象，它也知道如何将它不能处理的命令对象传递给该链中的下一个处理对象。该模式还描述了往该处理链的末尾添加新的处理对象的方法。

光看这段描述可能大家会觉得懵，简单来说就是该设计模式用于对某个对象或者请求进行一系列的处理，这些处理逻辑正好组成一个链条。

下面来简单演示使用与不使用责任链模式有什么区别和优势。