服务端开发博客 | 后端架构 · 高并发 · 性能优化 · 微服务实战 👋🏼

引言 打开你们项目的 git log，大概率是这样： a3f2b1c fix bug 7c8d9e1 update 2b4f5a6 修改 9e1c3d7 xxx 5d6a7b8 修复订单问题 3f8c9d0 2024-01-15 update 这种 commit message 有什么问题？ "fix bug" —— 修的哪个 bug？怎么修的？ "update" —— 更新了什么？文档还是代码？ "修改" —— 改的哪里？ "xxx" —— ？ 半年后排查线上问题，需要 git bisect 定位是哪次提交引入的 bug，看到一堆 "fix bug" 直接崩溃。 commit message 不是写给自己的，是写给团队和未来的自己看的。 这篇文章从规范到自动化，讲透一套完整的 commit message 方案： Conventional Commits 规范：feat/fix/chore 等类型含义 commitlint：自动校验，不规范不让提交 husky：把校验挂到 git hook commitizen：交互式生成规范 message standard-version....

引言 面试题：为什么不用本地缓存？答：分布式系统都用 Redis。 但现实是——很多场景本地缓存仍然是刚需： 配置数据、字典数据——QPS 高但极少变更，每次走 Redis 多一跳网络 热点商品信息——Redis 也会被打爆，本地缓存兜底 计算结果缓存——复杂的统计结果，本地存一份避免重复计算 Java 生态里三大本地缓存各有拥趸： Guava Cache——老牌选手，曾经的王者 Ehcache——老牌中的老牌，功能最全 Caffeine——新生代，号称"Guava Cache 的替代品" 到底选谁？社区争论很多，但缺少实测数据支撑。 这篇文章从 6 个维度做实测对比：读写吞吐、内存占用、过期策略、淘汰算法、Spring Cache 集成、异步加载。每个维度都有压测数据，看完你心里就有答案了。 一、三巨头简介 1.1 Guava Cache 出身：Google Guava 工具库的一部分，2010 年左右推出。 定位：简单易用的进程内缓存，API 设计优雅。 特点： API 简洁，CacheBuilder 链式调用 支持 TTL、TTI、基于引用的回收 支持 CacheLo....

引言 现在一说 IDEA 插件，第一反应都是 GitHub Copilot、Cursor 这些 AI 补全工具。但 AI 再强，也只是替你写代码——真正卡效率的，往往是那些"机械重复"的小事： Mapper 接口和 XML 来回切，找半天对不上 想找某个 REST 接口，全局搜索搜出一堆无关代码 字段名驼峰转下划线，手动改一行改一次 Maven 依赖冲突报错，看 dependency:tree 看到眼花 同事写的代码括号嵌套五层，根本看不清配对 这些事 AI 帮不上忙，但下面这 8 个 IDEA 插件能。每个都是装上立刻见效、用过就回不去的类型。 一、MyBatisX：Mapper 和 XML 一键跳转 痛点 MyBatis 开发最烦的事： OrderMapper.java ← 接口 OrderMapper.xml ← 实现 写代码时来回切： 接口里写 selectById → 切到 XML 写 SELECT * FROM ... → 切回接口看参数类型 → 切到 XML 看字段名 原生 IDEA 没有这俩文件的关联，全靠肉眼对齐方法名。 MyBatisX 能做什么 1. 一键....

引言 社区都说虚拟线程（Virtual Threads）是"性能革命"，JDK 21 GA 后无数文章吹爆： "Virtual Threads 让你的吞吐提升几十倍！" "线程池要被淘汰了！" "100 万并发不是梦！" 但真到自己落地时，发现一堆疑问： 我们的业务场景到底能不能提升？ CPU 密集场景到底有没有用？ 线程池调到 500 够不够，虚拟线程真的完爆它吗？ 高并发短任务和长连接场景表现一样吗？ 光看官方 Benchmark 没用，得自己压一遍。这篇文章我用 10,000 并发，在 5 个真实业务场景下，对三种方案做横向对比： 传统线程池（200 线程） 传统线程池（500 线程） Virtual Threads 每种场景压 10 分钟，记录 QPS、P99 延迟、CPU、内存。看完这篇，你会清楚知道你的场景该不该上虚拟线程。 一、压测方案设计 1.1 测试环境 项目配置 CPU8 核 16 线程（Intel i7-12700H） 内存32GB DDR4 JDKOpenJDK 21.0.2 应用Spring Boot 3.2 + Virtual Thre....

引言 线上事故复盘： OrderMapper.xml 中有一行 SQL： SELECT * FROM order WHERE user_id = #{userId} 半夜上线后报错：You have an error in your SQL syntax 原因：`order` 是 MySQL 关键字，应该加反引号 `order` 这种错误你大概率遇到过。MyBatis 把 SQL 写在 XML 里，本质上还是字符串拼接——表名错了、字段名错了、参数类型错了，只有运行时才暴露。 有没有办法在写代码时就发现这些错误？有——用 jOOQ。 jOOQ（Java Object Oriented Querying）把数据库表映射成 Java 类，用 DSL（领域特定语言）写 SQL，编译期就能检查表名、字段名、类型。IDE 自动补全，重构跟着改，错字段直接红线。 本文对比 MyBatis 和 jOOQ，从代码生成到实战 CRUD、复杂联表、动态条件、事务，最后附 Spring Boot 集成配置和常见坑。 一、MyBatis 的痛点：SQL 是字符串 1.1 字符串拼接的代价 <!-- ....

引言 线上告警炸了： [P1] MySQL CPU 100% [P1] 应用接口 P99 5s [P1] 数据库连接池打满 打开 Grafana一看： Redis 命中率从 95% 掉到 30% MySQL QPS 从 2 千飙到 8 万 应用线程池全满 典型的缓存失效问题。但具体是哪种？ 缓存失效有三种典型形态——穿透、雪崩、击穿，每个都能让数据库瞬间崩溃，但原因和解决方案完全不同。 这篇文章把三个真实事故合并在一起复盘，每个坑附事故场景、排查过程、代码方案。看完这篇，下次再遇到你能 5 分钟定位是哪一种。 一、先搞清三个坑的区别 很多人把这三个概念搞混。一张表说清： 概念现象根因典型场景 穿透查的数据在缓存和 DB 都没有数据不存在恶意攻击、爬虫乱查 ID 雪崩大量缓存同时失效过期时间相同批量预热后统一过期 击穿单个热点 Key 失效瞬间热点 + 过期秒杀商品、首页推荐 记忆口诀： 穿透：查没有的 → DB 被"打穿" 雪崩：集体失效 → DB 被"压塌" 击穿：热点失效 → DB 被"击穿" 二、事故一：缓存穿透——压垮 DB 的隐形杀手 2.1 事故复盘 ....

引言 性能优化是后端开发永恒的命题。从 GC 停顿到内存诊断，从缓存到向量计算，每一项技术进步都直接影响着线上服务的稳定性。 本周性能优化领域有 3 件事值得每个服务端开发者关注：JDK 23 把 ZGC 停顿压到了亚毫秒级、Redis 8.0 引入向量搜索、async-profiler 3.0 终于能看懂 Virtual Threads 了。每件事背后都是性能优化方法论的一次升级。 一、JDK 23 早期构建版发布，ZGC 停顿压缩至亚毫秒级 1.1 事件概览 JDK 23 早期构建版（EA Build）发布，最值得关注的是 ZGC（Z Garbage Collector） 的进一步优化： 停顿时间压缩至亚毫秒级（< 1ms） 即使堆内存达到 16TB，GC 停顿仍稳定在亚毫秒 STW（Stop-The-World）阶段更少 1.2 为什么值得关注 GC 停顿是 Java 应用最大的性能痛点之一： 场景传统 GC 的影响 高 QPS 接口单次 200ms GC 停顿 → 瞬间丢几千请求 实时推荐系统GC 停顿导致响应抖动，用户体验下降 金融交易系统GC 停顿直接卡....

引言 JDK 21 把虚拟线程（Virtual Threads）正式 GA 了，社区里一片"革命""颠覆""未来已来"的声音。 但你可能还有疑问： 虚拟线程不就是 Go 的 goroutine 吗？Java 抄作业而已？ 它和原来的 Thread 有什么本质区别？ 为什么都说 IO 密集场景能提升几十倍吞吐？凭什么？ 要讲清这些，必须从操作系统的线程模型说起。这篇文章不堆源码，用图解 + 伪代码讲透三件事： 传统 Java 线程为什么贵 虚拟线程是怎么"凭空"造出几百万个的 Continuation + ForkJoinPool 是怎么把 IO 等待变成免费的 看完这篇，你会真正理解为什么这是一次"革命"，而不是"小修小补"。 一、操作系统线程模型：1:1 不是 Java 的选择，是历史包袱 1.1 三种线程模型 操作系统理论上支持三种线程模型： ① 1:1 模型（Kernel-level Thread，内核线程） ┌──────────┐ ┌──────────┐ ┌──────────┐ │ User T1 │ │ User T2 │ │ User T3 │ └────┬....

引言 运营小妹发来消息："帮我导出最近半年的订单数据，要 Excel 格式，有 1000 多万条。" 你自信满满："小意思，十分钟搞定。" 启动导出任务，看了一眼进度条，2 分钟后接口直接挂了。 查看日志： java.lang.OutOfMemoryError: Java heap space 堆内存飙到了 4G，GC 把 CPU 跑满，服务假死。 你又试了试加 -Xmx8g——这次撑了 5 分钟，还是挂了。 这就是大数据导出的典型坑：MyBatis 默认一次性把结果加载到内存，1000 万条订单 × 每条 50 个字段 ≈ 5-8 个 G，直接爆。 本文从踩坑的代码出发，一步步演进到最终方案： MyBatis 流式查询 → ResultHandler 逐条处理 → CSV 分片 → SXSSF 流式 Excel 内存：4G → 200M。 一、踩坑现场：传统导出为什么 OOM 1.1 传统写法 @Service public class OrderExportService { @Autowired private OrderMapper orderMapper; /** * 运....

引言 凌晨两点告警炸了，打开 ELK 想查日志： Loading... Loading... Loading... Timeout. Kibana 加载 30 秒才出结果，ES 节点 CPU 100%，磁盘又满了。 每次扩容都是加节点、加磁盘、加内存，运维成本高到离谱。 ELK 是好东西，但对中小团队来说太重——Elasticsearch 索引全部日志内容，光存储就是一笔大开销，再加上 JVM 调优、集群维护，运维同学直呼"养不起"。 有没有更轻量的方案？有。Loki + Promtail + Grafana——Grafana Labs 出品的"日志版 Prometheus"，只索引标签不索引全文，存储成本直接砍 80%，还能和 Grafana 无缝集成，在同一面板看 Metric + Trace + Log。 本文从零搭建一套完整的日志平台，附 docker-compose 一键部署 + Spring Boot 接入 + LogQL 查询实战。 一、为什么选 Loki 不选 ELK 1.1 ELK 的痛点 ELK = Elasticsearch + Logstash + Kiba....

引言 面试现场，面试官抛出经典问题："分布式事务怎么保证一致性？" 90% 的候选人脱口而出："2PC 和 TCC。" 面试官追问："你项目里用的哪个？" 候选人："……了解过原理，没用过。" 这篇文章不讲理论，只讲实战。从一个转账场景出发，带你走完 2PC 的坑、TCC 的重、最后落地 Seata AT 模式——对业务零侵入，自动回滚，这才是生产环境真正在用的方案。 一、问题背景：跨服务转账 1.1 场景描述 用户 A 向用户 B 转账 100 元，涉及两个服务： 转账服务（Transfer Service） ├── 账户服务 A（Account Service A）：扣减 A 的余额 └── 账户服务 B（Account Service B）：增加 B 的余额 两个服务连的是不同的数据库，本地事务管不了跨库操作。 1.2 问题在哪 @Service public class TransferService { @Autowired private AccountServiceA accountServiceA; // RPC 调用 @Autowired private Acco....

引言 线上接口突然变慢，排查一圈发现是数据库连接池打满了。 这时候问题来了：你用的是哪个连接池？为什么选它？它和别的有什么区别？ 很多人答不上来——"Spring Boot 默认的""公司一直用的"。 今天把三大主流连接池拉出来，统一环境、统一压测，10,000 并发下硬碰硬比一次，用数据说话。看完这篇，你应该能明确知道：什么场景该选什么。 一、三位选手介绍 1.1 HikariCP 属性说明 出身Brett Wooldridge，2013 年开源 定位"最快"的连接池，Spring Boot 2.0+ 默认 核心特点字节码优化、ConcurrentBag、无锁设计 代码量约 2,000 行（极致精简） 1.2 Druid 属性说明 出身阿里巴巴，2011 年开源 定位"监控最强"的连接池 核心特点内置 SQL 监控、慢 SQL 日志、WallFilter 防注入 代码量约 30,000 行（功能丰富） 1.3 DBCP2 属性说明 出身Apache Commons，DBCP1 的继任者 定位老牌连接池，基于 commons-pool2 核心特点稳定可....

引言 每个月 Java 生态都在冒出新工具，但大部分是"重复造轮子"。怎么判断一个新工具值不值得投入时间？我的标准很简单：它是否解决了一个我实际遇到的痛点。 8 月份有 5 个工具更新引起了我的注意，不是因为它们有多酷，而是因为每一个都踩中了 Java 开发者日常的真实痛点：单体应用模块混乱、Native Image 编译太慢、Testcontainers 命令行难用、Native Image 安全扫描空白、配置文件类型不安全。 下面逐个拆解。 雷达图总览 采用(Adopt) ↑ Testcontainers Desktop │ Spring Modulith 1.3 │ 试验(Trial) ←────────┼────────→ 评估(Assess) │ Pkl 0.27 │ DependencyCheck 11.0 │ 暂缓(Hold) ↓ GraalVM NBT 0.10 （编译速度提升，但仍需评估场景） 工具雷达位置一句话评价 Spring Modulith 1.3采用单体应用的模块化救命稻草 GraalVM NBT 0.10评估编译快了 40%，但先确认你真的需要....

引言 线上告警：订单查询接口 P99 飙到 5 秒，用户疯狂投诉。 打开监控一看，QPS 不高，机器负载也不高，但就是慢。典型的"代码写得烂"型性能问题。 本文记录这个接口从 5 秒优化到 200ms 的全过程，7 步走，每一步都有前后对比数据。不是理论，是真实线上案例。 零、问题接口 0.1 接口描述 GET /api/orders/{orderId} 功能：根据订单 ID 查询订单详情 返回：订单基本信息 + 用户信息 + 商品列表 + 物流信息 + 优惠信息 0.2 初始代码（慢得离谱的版本） @Service public class OrderQueryService { @Autowired private OrderMapper orderMapper; @Autowired private UserMapper userMapper; @Autowired private ProductMapper productMapper; @Autowired private LogisticsMapper logisticsMapper; @Autowired privat....

引言 线上又出故障了——接口变慢、内存飙高、GC 频繁。但你的反应是： 接口多慢？不知道，没有 QPS 和响应时间监控 内存为啥飙？不知道，没有 JVM 指标 GC 多频繁？不知道，没有 GC 日志采集 没有指标，排障就是"猜"。 本文从零搭建一套完整的指标体系：Micrometer 采集 → Prometheus 存储 → Grafana 可视化 → AlertManager 告警。全实战，附完整配置和仪表盘 JSON。 一、指标体系全景 1.1 为什么需要指标 问题场景需要的指标 接口慢了QPS、响应时间（P50/P95/P99） 内存溢出堆内存、非堆内存、GC 次数 线程耗尽活跃线程数、线程池队列长度 业务异常错误率、订单量、支付成功率 依赖故障DB 连接数、Redis 响应时间 1.2 技术选型 组件作用选型 采集应用内指标暴露Micrometer（Spring Boot 默认） 存储指标拉取和存储Prometheus 可视化仪表盘展示Grafana 告警规则触发通知AlertManager 1.3 数据流 Spring Boot App (Mic....