前言

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

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

结论是：没有结论，我觉得只能抱着怀疑的眼光审视这个问题了。另外还聊到了 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

前言

很久没有写关于 Spring 的文章了，最近在系统梳理 Dubbo 代码的过程中发现了 XML schema 这个被遗漏的知识点。由于工作中使用 SpringBoot 比较多的原因，几乎很少接触 XML，此文可以算做是亡羊补牢，另一方面，也为后续的 Dubbo 源码解析做个铺垫。

XML schema 扩展机制是啥？这并不是一块很大的知识点，翻阅一下 Spring 的文档，我甚至没找到一个贯穿上下文的词来描述这个功能，XML Schema Authoring 是文档中对应的标题，简单来说：

Github 上有众多优秀的开源项目，大多数 IT 从业者将其当做了予取予求的工具库，遇到什么需求，先去 Github 搜一把，但有没有想过有一天自己也可以给开源事业做一些贡献呢？本文将会以 incubator-dubbo 项目为例，向你阐释，给开源项目做贡献并不是一件难事。

前言

一提到线程安全的并发计数器，AtomicLong 必然是第一个被联想到的工具。Atomic* 一系列的原子类以及它们背后的 CAS 无锁算法，常常是高性能，高并发的代名词。本文将会阐释，在并发场景下，使用 AtomicLong 来充当并发计数器将会是一个糟糕的设计，实际上存在不少 AtomicLong 之外的计数器方案。近期我研究了一些 Jdk1.8 以及 JCTools 的优化方案，并将它们的对比与实现细节整理于此。

相关面试题：

单机场景下，有比 AtomicLong 更高效的并发计数器方案吗？

前言

JMH 是 Java Microbenchmark Harness（微基准测试）框架的缩写（2013 年首次发布）。与其他众多测试框架相比，其特色优势在于它是由 Oracle 实现 JIT 的相同人员开发的。在此，我想特别提一下 Aleksey Shipilev（JMH 的作者兼布道者）和他优秀的博客文章。笔者花费了一个周末，将 Aleksey 大神的博客，特别是那些和 JMH 相关的文章通读了几遍，外加一部公开课视频 《”The Lesser of Two Evils” Story》 ，将自己的收获归纳在这篇文章中，文中不少图片都来自 Aleksey 公开课视频。

最近的两篇文章，介绍了我参加的中间件比赛中一些相对重要的优化，但实际上还存在很多细节优化，出于篇幅限制并未提及，在最近的博文中，我会将他们整理成独立的知识点，并归类到我的系列文章「JAVA 拾遗」中。

维持了 20 天的复赛终于告一段落了，国际惯例先说结果，复赛结果不太理想，一度从第 10 名掉到了最后的第 36 名，主要是写入的优化卡了 5 天，一直没有进展，最终排名也是定格在了排行榜的第二页。痛定思痛，这篇文章将自己复赛中学习的知识，成功的优化，未成功的优化都罗列一下。

Kong（https://github.com/Kong/kong）是一个云原生，高效，可扩展的分布式 API 网关。 自 2015 年在 github 开源后，广泛受到关注，目前已收获 1.68w+ 的 star，其核心价值在于高性能和可扩展性。

为什么需要 API 网关

在微服务架构之下，服务被拆的非常零散，降低了耦合度的同时也给服务的统一管理增加了难度。如上图左所示，在旧的服务治理体系之下，鉴权，限流，日志，监控等通用功能需要在每个服务中单独实现，这使得系统维护者没有一个全局的视图来统一管理这些功能。API 网关致力于解决的问题便是为微服务纳管这些通用的功能，在此基础上提高系统的可扩展性。如右图所示，微服务搭配上 API 网关，可以使得服务本身更专注于自己的领域，很好地对服务调用者和服务提供者做了隔离。