由 dawei 某电商系统在大促前遭遇瓶颈：单台应用服务器吞吐量仅800 QPS，响应延迟飙升至1.2秒。后端架构师未急于扩容，而是聚焦三个可量化、易落地的调优点，两周内将QPS稳定提升至1700+，延迟降至450ms以下。
第一步是连接池与数据库访问重构。原应用使用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且使用默认G1GC。分析GC日志发现频繁Mixed GC（平均每次停顿180ms）。调整为：容器资源锁定2核3.2GB，JVM堆设为2GB，启用ZGC（-XX:+UseZGC），并关闭偏向锁。配合应用层对象复用（如ThreadLocal缓存Jackson ObjectMapper），Full GC归零，Young GC停顿压至2ms内。
AI生成内容图，仅供参考
三次调整均经过A/B测试验证：单次变更后灰度10%流量，监控TP99、错误率、GC频率、CPU Load四项核心指标。无任何功能回退，所有优化均可灰度开关控制。吞吐量翻倍并非靠堆资源，而是让每一份计算、每一次IO、每一MB内存都更贴近业务真实需求——架构优化的本质，是让系统在约束中更聪明地呼吸。