JDK 8 到 21 的语言变化,可以概括成一句话:让类型系统承担更多表达责任,让模板代码更少。
这篇是系列第一篇,只讲语言和标准库;JVM、GC、字符集、模块系统放到运行时篇,Spring 的落地放到迁移篇。
TL;DR
- 语言主线:
var(10)→ switch 表达式(14)→ 文本块(15)→ record(16)→ sealed(17)→ switch / record 模式匹配(21)。- 标准库优先用:
List.of、Stream.toList、Optional.ifPresentOrElse、Files.readString、HttpClient。- 生产不要用预览特性;record 不要做 JPA 实体;
List.of不接受 null。
一句话结论:RocketMQ 是缓冲区,不是限流器。 它能把流量削平,但不会替你保护下游数据库,也不会阻止生产端把 Broker 打爆。限流要自己加,而且要先把“速率限制”“并发限制”“背压”这三件事分清楚。
典型场景:大促或者批量导入,生产端瞬间灌进几十万条消息。Broker 扛住了,但消费端以 consumeThreadMax = 64 的全速消费,分分钟把 MySQL 连接池、下游 HTTP 接口打满,然后整条链路一起雪崩。
很多人第一反应是“RocketMQ 有没有限流开关”。答案是:没有业务语义上的 QPS 限流开关。 它自带的保护机制解决的是另一个问题:
| RocketMQ 自带机制 | 实际作用 | 是否等于业务限流 |
|---|---|---|
Broker 发送队列满后拒绝 / [TIMEOUT_CLEAN_QUEUE] | 保护 Broker 自身不被压垮 | 否,是故障保护,且表现为报错 |
pullThresholdForQueue / pullThresholdSizeForQueue | 客户端缓存太多消息时暂停拉取 | 否,是背压(backpressure) |
consumeThreadMax | 限制消费线程数 | 否,限制的是并发,不是每秒处理量 |
maxReconsumeTimes + 延迟等级 | 失败重试与退避 | 否,是失败处理 |
所以限流必须落在应用侧。一条完整的消息链路,有三个可以下手的位置:
上游业务 ──▶ [生产端限流] ──▶ Broker(缓冲、堆积) ──▶ [消费端限流 / 并发控制 / 背压] ──▶ DB、HTTP 下游
要在桌面上从 Chrome 或 Edge 导出密码:
打开浏览器设置,进入密码设置,比如。chrome://password-manager/settingsedge://wallet/passwords
找到导出密码并点击“下载文件”。你可能会被要求输入电脑密码以获得授权。对于 Microsoft Edge,这个功能可能隐藏在“已保存密码”部分的 菜单后面。
指定导出保存的位置,并确认格式为逗号分隔值(CSV)。
选择保存以完成导出。