由 dawei 某电商系统在大促前遭遇瓶颈：单台应用服务器吞吐量仅800 QPS，响应延迟飙升至1.2秒。后端架构师未急于扩容，而是聚焦三个可量化、易落地的调优点，两周内将QPS稳定提升至1700+，延迟降至450ms以下。
AI渲染图，仅供参考
第一步是连接池与数据库访问重构。原应用使用HikariCP默认配置（最大连接数20），但实际业务存在大量短时并发查询，导致连接争抢严重。将连接池最大值动态设为CPU核心数×4，并启用connection-timeout和validation-timeout机制；同时将高频单表查询从MyBatis的XML拼接改为预编译+参数绑定，并为WHERE字段添加复合索引。这使DB平均RT从95ms降至28ms，线程阻塞率下降76%。
第二步是异步化关键非核心路径。订单创建流程中，短信通知、用户积分更新、埋点日志写入均为耗时操作，但不阻塞主链路。将这些操作剥离至基于RabbitMQ的异步队列，并采用本地内存缓存+批量落库方式处理积分变更。主线程响应时间缩短320ms，CPU利用率峰谷差收窄40%，避免了线程池因IO等待而饥饿。
第三步是JVM与容器协同调优。原容器分配2核4GB，JVM堆设为3GB，但G1 GC频繁触发混合收集，STW时间超预期。调整为堆2GB（-Xms2g -Xmx2g），启用ZGC（-XX:+UseZGC），并关闭显式GC调用；同时将容器CPU配额提升至3核，配合JVM设置-XX:ActiveProcessorCount=3。GC暂停时间从平均85ms降至3ms以内，吞吐稳定性显著增强。
三次调整均通过AB测试与生产灰度验证，无代码逻辑变更，仅依赖配置优化与架构解耦。服务器横向扩展需求推迟三个月，节省云资源成本约40%。调优本质不是堆参数，而是厘清瓶颈根源——连接争抢、同步阻塞、GC反模式，每一处都对应明确可观测指标（连接等待时长、线程状态分布、GC日志吞吐量）。当系统行为被精准度量，性能提升便不再依赖经验直觉，而成为可复现、可推演的工程实践。