背景

最近时运不佳，几乎天天被线上问题骚扰。前几天刚解决了一个 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 的拦截器功能，正好用到了责任链模式。

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

责任链模式

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

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

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

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

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

前言

最近分享的一些源码、框架设计的东西。我发现大家热情不是特别高，想想大多数应该还是正儿八经写代码的居多；这次就分享一点接地气的： SpringBoot 使用中的一些小技巧。

算不上多高大上的东西，但都还挺有用。

前言

在上文 设计一个百万级的消息推送系统 中提到消息流转采用的是 Kafka 作为中间件。

其中有朋友咨询在大量消息的情况下 Kakfa 是如何保证消息的高效及一致性呢？

正好以这个问题结合 Kakfa 的源码讨论下如何正确、高效的发送消息。

内容较多，对源码感兴趣的朋友请系好安全带😏(源码基于 v0.10.0.0 版本分析)。同时最好是有一定的 Kafka 使用经验，知晓基本的用法。

前言

本次 Cicada 已经更新到了 v1.0.3。

主要是解决了两个 issue，#9 #8。

所以本次的主要更新为：

• Cicada 采用合理的线程分配来处理接入请求线程以及 IO 线程。
• 支持多种响应方式（以前只有 json，现在支持 text）。
• 为了满足上者引入了 context。
• 优雅停机。

其中我觉得最核心也最有用的就是这个 Context，并为此重构了大部分代码。

前言

首先迟到的祝大家中秋快乐。

最近一周多没有更新了。其实我一直想憋一个大招，分享一些大家感兴趣的干货。

鉴于最近我个人的工作内容，于是利用这三天小长假憋了一个出来（其实是玩了两天🤣）。

先简单说下本次的主题，由于我最近做的是物联网相关的开发工作，其中就不免会遇到和设备的交互。

最主要的工作就是要有一个系统来支持设备的接入、向设备推送消息；同时还得满足大量设备接入的需求。

所以本次分享的内容不但可以满足物联网领域同时还支持以下场景：

• 基于 WEB 的聊天系统（点对点、群聊）。
• WEB 应用中需求服务端推送的场景。
• 基于 SDK 的消息推送平台。

技术选型

要满足大量的连接数、同时支持双全工通信，并且性能也得有保障。

在 Java 技术栈中进行选型首先自然是排除掉了传统 IO。

那就只有选 NIO 了，在这个层面其实选择也不多，考虑到社区、资料维护等方面最终选择了 Netty。

最终的架构图如下：