编辑
2026-10-25
学习记录
00

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。

编辑
2026-10-25
学习记录
00

Spring 项目里给 RocketMQ 消息限流:从生产端到消费端的完整方案

一句话结论:RocketMQ 是缓冲区,不是限流器。 它能把流量削平,但不会替你保护下游数据库,也不会阻止生产端把 Broker 打爆。限流要自己加,而且要先把“速率限制”“并发限制”“背压”这三件事分清楚。

一、为什么 RocketMQ 需要额外限流

典型场景:大促或者批量导入,生产端瞬间灌进几十万条消息。Broker 扛住了,但消费端以 consumeThreadMax = 64 的全速消费,分分钟把 MySQL 连接池、下游 HTTP 接口打满,然后整条链路一起雪崩。

很多人第一反应是“RocketMQ 有没有限流开关”。答案是:没有业务语义上的 QPS 限流开关。 它自带的保护机制解决的是另一个问题:

RocketMQ 自带机制实际作用是否等于业务限流
Broker 发送队列满后拒绝 / [TIMEOUT_CLEAN_QUEUE]保护 Broker 自身不被压垮否,是故障保护,且表现为报错
pullThresholdForQueue / pullThresholdSizeForQueue客户端缓存太多消息时暂停拉取否,是背压(backpressure)
consumeThreadMax限制消费线程数否,限制的是并发,不是每秒处理量
maxReconsumeTimes + 延迟等级失败重试与退避否,是失败处理

所以限流必须落在应用侧。一条完整的消息链路,有三个可以下手的位置:

上游业务 ──▶ [生产端限流] ──▶ Broker(缓冲、堆积) ──▶ [消费端限流 / 并发控制 / 背压] ──▶ DB、HTTP 下游
编辑
2026-10-24
项目分享
00

本地部署ollama启用amd核显

安装ollama正式版

本地部署Ollama使用开源大模型

比如0.13.5 github地址

下载amd版本ollma

这里也要下载0.13.5版本 github地址

编辑
2026-10-24
学习记录
00

Chrome 或 Edge

要在桌面上从 Chrome 或 Edge 导出密码:

打开浏览器设置,进入密码设置,比如。chrome://password-manager/settingsedge://wallet/passwords

找到导出密码并点击“下载文件”。你可能会被要求输入电脑密码以获得授权。对于 Microsoft Edge,这个功能可能隐藏在“已保存密码”部分的  菜单后面。

指定导出保存的位置,并确认格式为逗号分隔值(CSV)。

选择保存以完成导出。

其他浏览查看

https://bitwarden.com/help/import-from-chrome/

编辑
2026-10-24
学习记录
00

该文章已加密,点击 阅读全文 并输入密码后方可查看。