1 前言

在开始正题之前，先闲聊几句。有人说，计算机科学这个学科，软件方向研究到头就是数学，硬件方向研究到头就是物理，最轻松的是中间这批使用者，可以不太懂物理，不太懂数学，依旧可以使用计算机作为自己谋生的工具。这个规律具有普适应，看看“定时器”这个例子，往应用层研究，有 Quartz，Spring Schedule 等框架；往分布式研究，又有 SchedulerX，ElasticJob 等分布式任务调度；往底层实现看，又有多种定时器实现方案的原理、工作效率、数据结构可以深究…简单上手使用一个框架，并不能体现出个人的水平，如何与他人构成区分度？我觉得至少要在某一个方向有所建树：

1. 深入研究某个现有框架的实现原理，例如：读源码
2. 将一个传统技术在分布式领域很好地延伸，很多成熟的传统技术可能在单机 work well，但分布式场景需要很多额外的考虑。
3. 站在设计者的角度，如果从零开始设计一个轮子，怎么利用合适的算法、数据结构，去实现它。

回到这篇文章的主题，我首先会围绕第三个话题讨论：设计实现一个定时器，可以使用什么算法，采用什么数据结构。接着再聊聊第一个话题：探讨一些优秀的定时器实现方案。

每一个不恰当的提问都在消耗别人对你的耐心，程序员届早已经有了诸如《提问的智慧》之类的经典文章介绍了什么是蠢问题，如何避免问蠢问题。然而，常年混迹于十几个技术交流微信群的我，发现很多小白程序员并不懂得这一点，为改善微信群的技术交流氛围，转此文，意图是让大家在担任提问者的角色时，尽可能提高提问的素质，让自己成为值得被教的人。

原文出处：https://github.com/aptx4869yuyang2017/How-To-Ask-Questions-The-Smart-Way

1 前言

在前一篇文章 《聊聊 TCP 长连接和心跳那些事》 中，我们已经聊过了 TCP 中的 KeepAlive，以及在应用层设计心跳的意义，但却对长连接心跳的设计方案没有做详细地介绍。事实上，设计一个好的心跳机制并不是一件容易的事，就我所熟知的几个 RPC 框架，它们的心跳机制可以说大相径庭，这篇文章我将探讨一下 ** 如何设计一个优雅的心跳机制，主要从 Dubbo 的现有方案以及一个改进方案来做分析 **。

前言

可能很多 Java 程序员对 TCP 的理解只有一个三次握手，四次握手的认识，我觉得这样的原因主要在于 TCP 协议本身稍微有点抽象（相比较于应用层的 HTTP 协议）；其次，非框架开发者不太需要接触到 TCP 的一些细节。其实我个人对 TCP 的很多细节也并没有完全理解，这篇文章主要针对微信交流群里有人提出的长连接，心跳问题，做一个统一的整理。

在 Java 中，使用 TCP 通信，大概率会涉及到 Socket、Netty，本文将借用它们的一些 API 和设置参数来辅助介绍。

定义

在不谈及 dubbo 时，我们大多数人对 URL 这个概念并不会感到陌生。统一资源定位器 (RFC1738――Uniform Resource Locators (URL)）应该是最广为人知的一个 RFC 规范，它的定义也非常简单

因特网上的可用资源可以用简单字符串来表示，该文档就是描述了这种字符串的语法和语
义。而这些字符串则被称为：“统一资源定位器”（URL）

** 一个标准的 URL 格式 ** 至多可以包含如下的几个部分

1

protocol://username:password@host:port/path?key=value&key=value

1 前言

国际惯例，先报成绩，熬了无数个夜晚，最后依旧被绝杀出了第一页，最终排名第 21 名。前十名的成绩分布为 413.69~416.94，我最终的耗时是 422.43。成绩虽然不是特别亮眼，但与众多参赛选手使用 C++ 作为参赛语言不同，我使用的是 Java，一方面是我 C++ 的能力早已荒废，另一方面是我想验证一下使用 Java 编写存储引擎是否与 C++ 差距巨大 (当然，主要还是前者 QAQ)。所以在本文中，我除了介绍整体的架构之外，还会着重笔墨来探讨 Java 编写存储类型应用的一些最佳实践，文末会给出 github 的开源地址。

背景

已经过去的中间件性能挑战赛，和正在进行中的 第一届 PolarDB 数据性能大赛 都涉及到了文件操作，合理地设计架构以及正确地压榨机器的读写性能成了比赛中获取较好成绩的关键。正在参赛的我收到了几位公众号读者朋友的反馈，他们大多表达出了这样的烦恼：“对比赛很感兴趣，但不知道怎么入门”，“能跑出成绩，但相比前排的选手，成绩相差 10 倍有余”…为了能让更多的读者参与到之后相类似的比赛中来，我简单整理一些文件 IO 操作的最佳实践，而不涉及整体系统的架构设计，希望通过这篇文章的介绍，让你能够欢快地参与到之后类似的性能挑战赛之中来。

前言

这是一篇译文，原文出处 戳这里。其实很久以前我就看完了这篇文章，只不过个人对响应式编程研究的不够深入，羞于下笔翻译，在加上这类译文加了原创还有争议性，所以一直没有动力。恰逢今天交流群里两个大佬对响应式编程的话题辩得不可开交，趁印象还算深刻，借机把这篇文章翻译一下。说道辩论的点，不妨也在这里抛出来：

响应式编程在单机环境下是否鸡肋？

结论是：没有结论，我觉得只能抱着怀疑的眼光审视这个问题了。另外还聊到了 RSocket 这个最近在 SpringOne 大会上比较火爆的响应式 “ 新“网络协议，github 地址 戳这里，为什么给”新“字打了个引号，仔细观察下 RSocket 的 commit log，其实三年前就有了。有兴趣的同学自行翻阅，说不定就是今年这最后两三个月的热点技术哦。

Java 圈子有一个怪事，那就是对 RxJava，Reactor，WebFlux 这些响应式编程的名词、框架永远处于渴望了解，感到新鲜，却又不甚了解，使用贫乏的状态。之前转载小马哥的那篇《Reactive Programming 一种技术，各自表述》时，就已经聊过这个关于名词之争的话题了，今天群里的讨论更是加深了我的映像。Java 圈子里面很多朋友一直对响应式编程处于一个了解名词，知道基本原理，而不是深度用户的状态 (我也是之一)。可能真的和圈子有关，按石冲兄的说法，其实 Scala 圈子里面的那帮人，不知道比咱们高到哪里去了（就响应式编程而言）。

实在是好久没发文章了，向大家说声抱歉，以后的更新频率肯定是没有以前那么勤了（说的好像以前很勤快似的），一部分原因是在公司内网写的文章没法贴到公众号中和大家分享讨论，另一部分是目前我也处于学习公司内部框架的阶段，不太方便提炼成文章，最后，最大的一部分原因还是我这段时间需要学 (tou) 习(lan)其 (da) 他(you)东 (xi) 西啦。好了，废话也说完了，下面是译文的正文部分。

还记得上一篇记录我心情的随笔是写在离开魔都，去往南京的时候，此时的我，又来到了杭州。工作发生了变故，心境也发生了变化，倒是有不少东西想跟各位来聊一聊，择其三汇成此文。

本文的前 3 节参考修改自微信公众号「咖啡拿铁」的文章，感谢李钊同学对这个话题热情的讨论。

1 前言

一提到 Java 中的随机数，很多人就会想到 Random，当出现生成随机数这样需求时，大多数人都会选择使用 Random 来生成随机数。Random 类是线程安全的，但其内部使用 CAS 来保证线程安全性，在多线程并发的情况下的时候它的表现是存在优化空间的。在 JDK1.7 之后，Java 提供了更好的解决方案 ThreadLocalRandom，接下来，我们一起探讨下这几个随机数生成器的实现到底有何不同。

2 Random