在单体拆成微服务之后，一个最容易被低估的事实是：网络调用不再具备单进程函数调用的可靠性。HTTP/RPC 天然存在超时、重试、乱序、重复投递，而服务间的调用链一旦拉长，任何一环的抖动都会被下游放大。于是「幂等、限流、熔断」这三件事，从"可选优化"变成了"生产底线"。本文不打算罗列概念，而是从我在生产环境踩过的坑出发，讲清楚每一层的设计取舍、参数调优与排查思路。

一、为什么这三件事必须放在一起设计

很多团队把幂等、限流、熔断当成三个独立的工具分别接入，结果往往是：限流拦住了突发流量，但重试风暴依然打垮了下游；幂等保证了重复请求不重复扣款，但熔断打开后客户端还在无脑重试。它们的本质其实是同一件事的三个切面——在不可靠的分布式环境里，保证系统在异常流量下仍然做出正确且可预期的行为。

一、为什么连接池不是"池化一个对象"这么简单

很多工程师把连接池当成一个"预先 new 好一批 Connection，用完放回去"的简单缓存。这种理解在低并发下不会出错，但一旦压测或大促，问题就会集中爆发：连接耗尽、线程阻塞、数据库被打爆、业务雪崩。要理解连接池，首先要理解它管理的"资源"到底贵在哪里。

一个 JDBC 物理连接的开销分三部分：

1. 网络握手：TCP 三次握手 + TLS（如果开启 SSL）+ 数据库协议层的认证交换。内网单次通常 1~3ms，跨机房或云上可达几十毫秒。
2. 服务端会话初始化：MySQL 会为每个连接分配独立线程、独立内存缓冲（sort_buffer_size、join_buffer_size、read_buffer_size 等），还要做权限校验和库表元数据加载。高并发下频繁创建连接等于频繁向服务端索要内存与线程。
3. 连接状态与事务语义：连接是有状态的——当前数据库、事务隔离级别、autocommit、会话变量、临时表、锁等。复用连接时必须"清洗"这些状态，否则就会产生脏数据或锁泄漏。

在 Java 21 中，虚拟线程（Virtual Threads）作为 LTS 特性正式转正（JEP 444）。它承诺以"每个请求一个线程"的编程模型承载百万级并发，同时保持阻塞式代码的可读性。但虚拟线程不是银弹：它改变了线程的调度方式、栈的存储方式，也引入了 pinning 等一系列新问题。这篇文章不讲"虚拟线程让并发变得简单"这类正确的废话，而是深入 JVM 内部，把载体线程调度、栈存储、pinning 的成因与排查、以及真实生产中的调优参数讲透。

一、平台线程与虚拟线程：模型上的本质差异

要理解虚拟线程，必须先明确它与传统平台线程（Platform Thread）的差异。平台线程是操作系统线程（Linux 下的 pthread）的一对一包装，它的调度由内核完成，栈由内核分配，默认约 1MB，创建和切换的开销都相当可观。当你在一个高并发服务里为每个请求开一个平台线程时，瓶颈往往不是 CPU，而是线程数量达到几千后，线程栈的内存占用与内核调度的上下文切换成本。

深夜两点，告警群突然炸了：某核心服务的堆内存使用率连续 30 分钟超过 95%，Full GC 频率从平时的每 40 分钟一次飙升到每分钟数次，接口 P99 从 120ms 恶化到 3s，紧接着节点开始轮番 OOM 重启。这类场景对每一个后端工程师来说都不陌生。本文以一次真实的生产内存泄漏事故为蓝本，完整复盘从「发现异常」到「定位根因」再到「止血与根治」的全链路排查过程，重点讲清楚 jstat、jmap、jstack、MAT 这些工具各自该在什么时机用、能拿到什么证据、如何互相印证。

一、问题现象：先定性，再动手

拿到告警后的第一件事不是急着 dump 堆，而是先回答三个问题：这是内存泄漏，还是内存本来就不够？是 Full GC 频发导致的暂停，还是年轻代晋升压力过大？是单点问题还是全集群问题？

很多人对 Netty 的认知停留在「一个高性能的 NIO 框架」这个层面，但真正在生产环境里扛过高并发、踩过内存泄漏和背压的坑之后，才会意识到：Netty 的性能不是靠某个单一 API 实现的，而是由线程模型、内存管理、流水线设计与背压机制这四个环节共同构成的一套工程体系。任何一环被忽视，都会在压测时以「线程打满」「直接内存 OOM」「消息堆积」的形式集中爆发。

本文不打算复述官方文档，而是从源码与线上事故出发，把这四块讲透：主从 Reactor 为什么这样拆、ChannelPipeline 的事件如何传播、ByteBuf 与零拷贝到底省掉了什么、高低水位如何实现背压。最后附上一份可直接落地的调优清单。

在单体架构时代，事务靠数据库的 ACID 就能兜底；一旦服务拆成微服务，一笔业务跨越订单、库存、账户三个独立数据源时，@Transactional 就彻底失效了——每个服务的事务都是"局部自治"的，任何一个环节失败都不会回滚别人已经提交的改动，最终落得一地数据不一致。本文不打算泛泛介绍"什么是分布式事务"，而是从工程视角拆解四种主流方案的取舍，再深入 Seata AT 模式的两阶段提交、全局锁与 undolog 细节，最后给出我在生产环境踩过的坑与调优清单。

一、先想清楚：为什么大部分场景首选"最终一致性"

在日常 CRUD 之外，真正能拉开工程师差距的，是对框架底层运行机制的掌握。循环依赖是 Spring 面试的高频考点，但绝大多数人只背下了"三级缓存"这四个字，却说不清"为什么是三级而不是两级"、也讲不明白"构造器循环依赖为什么无解"。本文从容器启动流程出发，沿着 Bean 生命周期的完整链路，把三级缓存的来龙去脉、设计权衡和生产实践一次讲透。

一、容器启动流程：一条 refresh() 主线

Spring 的 IoC 容器无论以何种方式创建——ClassPathXmlApplicationContext、AnnotationConfigApplicationContext 还是 Spring Boot 内嵌的 AnnotationConfigServletWebServerApplicationContext——最终都会收敛到 AbstractApplicationContext#refresh() 这一个方法上。它是整个容器的"总装线"，理解它也就理解了容器启动的全貌。

在 Java 并发编程的世界里，ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock、ThreadPoolExecutor 的 Worker……这些我们几乎每天都在使用的工具，背后都站着一个共同的"地基"——AbstractQueuedSynchronizer（AQS）。它是 java.util.concurrent（JUC）包中最核心的抽象，没有之一。

很多人对 JVM 的理解停留在"解释执行 + 垃圾回收"的层面，却忽略了真正决定吞吐上限的那一层——即时编译器（JIT Compiler）。HotSpot 之所以能在长时间运行后逼近甚至反超静态编译语言，靠的不是把字节码逐条翻译成机器码这么简单，而是一整套基于运行时反馈的激进优化：分层编译、内联、逃逸分析、标量替换、同步消除。这些优化彼此咬合，任何一环失效都可能让后续优化整条链断裂。

本文不打算把 JIT 讲成教科书，而是从生产排障的视角出发，讲清楚三个问题：这些优化在什么条件下才会发生、如何验证它真的发生了、以及它失效时的典型症状是什么。

类加载机制是 JVM 中最容易被"背八股文"却最难真正吃透的一块。很多人能脱口而出"双亲委派模型"六个字，却说不清 ClassLoader.loadClass 和 Class.forName 的初始化时机差异，也解释不了 SPI 为什么要打破双亲委派、以及 Tomcat 为什么每个 Web 应用都要有独立的 ClassLoader。本文从字节码加载的完整生命周期出发，结合生产环境的真实踩坑，把这一机制讲透。

一、类从字节码到实例：五个阶段的完整链路

一个 .class 文件从磁盘到真正可用，要经历加载（Loading）→ 验证（Verification）→ 准备（Preparation）→ 解析（Resolution）→ 初始化（Initialization）五个阶段。前三个阶段通常被笼统称为"加载"，但实际上语义完全不同，很多线上问题的根源就是混淆了这些阶段。