项目与简历面试题

Java大神2026/4/20大约 33 分钟高频面试题项目与简历面试题

请介绍一下你最有挑战的项目，你的角色与贡献

面试官您好，我来介绍一下我最有挑战的一个项目

项目背景与挑战 🎯

我在 XX 电商公司负责订单中心系统的重构与性能优化项目。当时我们面临的核心问题是：

大促期间订单峰值达到12 万 TPS，原有系统响应超时率飙升至35%
数据库连接池频繁耗尽，导致大量订单丢失和重复下单
系统架构臃肿，单体应用有200 + 个接口，维护成本极高
历史技术债严重，代码耦合度高，一个小改动可能引发雪崩效应

我的角色与核心任务 🛠️

我担任核心开发兼技术负责人，主要负责：

订单核心链路的架构设计与重构
数据库分库分表方案的落地
性能压测与瓶颈定位
带领 3 人小组完成核心模块开发

关键技术方案与我的贡献 💡

1. 架构分层重构

我主导将原有单体订单系统拆分为微服务架构，采用 DDD 领域驱动设计思想：

我的贡献：

设计了订单状态机模型，统一了 17 种订单状态流转逻辑
引入 Sentinel 做服务熔断降级，保障大促期间核心链路可用
实现了分布式事务最终一致性方案，解决了跨服务数据一致性问题

2. 数据库分库分表优化

针对订单表数据量过大（单表5 亿 + 条）的问题，我设计了水平分库分表 + 冷热分离方案：

优化前	优化后	提升幅度
提升幅度	提升幅度	-
查询平均耗时 800ms	查询平均耗时 25ms	96.875%
写入 TPS 3000	写入 TPS 15 万	50 倍
连接池耗尽频繁	连接池使用率稳定在 30% 以下	-

我的贡献：

基于 Sharding-JDBC 实现了自定义分片算法，按用户 ID 哈希 + 时间范围双维度分片
设计了数据迁移方案，实现了零停机平滑迁移
开发了冷热数据自动归档工具，将 3 个月前的订单自动归档到历史库

3. 缓存架构升级

我重新设计了多级缓存架构，解决了缓存击穿、雪崩和一致性问题：

我的贡献：

引入 Caffeine 本地缓存，减少了 80% 的 Redis 请求
实现了基于 Canal 的数据库变更监听，保证缓存最终一致性
设计了布隆过滤器 + 互斥锁方案，彻底解决了缓存击穿问题

项目成果与个人成长 🏆

性能指标：大促期间订单峰值从 12 万 TPS 提升至25 万 TPS，响应超时率从 35% 降至0.01%
业务指标：订单丢失率从 0.5% 降至0，用户投诉量下降90%
技术沉淀：输出了 3 篇技术文档，形成了公司内部的分库分表最佳实践
团队成长：带领的 3 人小组中有 2 人晋升为高级开发工程师

遇到的最大困难与解决思路 🤔

最大困难：分库分表后，跨库查询和统计分析变得非常困难。

解决思路：

非实时统计需求：引入 ClickHouse 数据仓库，通过 Canal 同步数据进行离线分析
实时查询需求：对常用的跨库查询场景进行数据冗余，通过消息队列保证一致性
极端场景：使用 Elasticsearch 实现全文检索和复杂条件查询

面试官可能追问的问题及回答要点 📝

1.你们的分布式事务是怎么实现的？为什么选择这个方案？

答：采用可靠消息 + 最终一致性方案，因为订单系统对一致性要求不是强一致，且该方案性能最好

2.分库分表后，如何处理主键 ID？

答：使用雪花算法生成分布式 ID，保证全局唯一且有序

3.缓存和数据库的一致性是怎么保证的？

答：采用 "先更新数据库，再删除缓存" 的策略，同时通过 Canal 监听数据库变更异步更新缓存

请介绍一下你最有挑战的项目，你的角色与贡献

面试官好，我挑一个最有挑战的项目说一下——“电商大促核心交易链路优化”，我在里面担任核心研发，主要负责缓存架构设计、异步削峰和JVM调优三块。

🎯 一句话背景：双11峰值流量是日常的 30 倍，要求下单 RT < 50ms，库存不准率 < 0.01%，系统不能雪崩。

🔥 挑战一：热点库存扣减，缓存与DB一致性

常规方案是直接扣 DB，大促时行锁严重，库存扣减成了瓶颈。

我的方案：

采用 “Redis 预扣减 + Lua 脚本”，把库存缓存到 Redis，用 Lua 原子执行 decr + 校验，单机 QPS 从 2k 提升到 8w+。
为防止少卖，设计了 “异步回补” 机制：Worker 消费 Kafka 消息，批量 merge 后更新 DB 库存，并做 Redis 与 DB 的对账。最终一致性延迟 < 200ms。
🧠 亮点：用 “版本号 + 逻辑过期” 解决缓存写冲突，没有用分布式锁，避免额外开销。

🧩 挑战二：削峰填谷，防止下游崩盘

大促瞬间流量会把下游的履约、物流服务打垮。

我的方案：

引入 Kafka 三层队列隔离：核心订单（高优）、普通订单（中优）、对账补偿（低优），不同消费线程池，避免互相影响。
自研了一个 “令牌桶 + 动态限流” 的组件：根据下游 RT 和异常率，自动调节令牌生成速率。上线后，下游服务的 P99 RT 下降 60%。

🧪 挑战三：JVM 摸高与 GC 调优

交易服务要低延迟，但大对象创建频繁导致 Young GC 耗时超过 50ms。

我的实践：

通过 jstat 和 GC 日志发现，订单快照序列化时产生大量 byte[] 进入老年代。
调优：调整 -XX:SurvivorRatio=6，增大 Survivor 区；将订单快照写入 堆外直接内存（DirectBuffer），减少 GC 压力。
结果：Full GC 从压测时的 3 次/分钟 → 0 次，Young GC 停顿稳定在 15ms 以内 ✅。

📊 我的角色与贡献总结

维度	我的动作	效果
🧱 架构设计	主导 Redis+异步库存方案，绘制核心链路时序图	系统抗住 30 倍峰值流量
💻 核心编码	编写 Lua 脚本、Kafka Worker、动态限流组件	核心链路 QPS 提升 40 倍
🔧 性能调优	JVM 参数调整、SQL 索引优化、连接池配置	RT 从 230ms → 38ms
📈 稳定性	设计对账补偿任务，灰度发布+监控报警	库存偏差率 `<` 0.005%

😎 这个项目让我最深的感觉是：高性能不是“用新技术”，而是把缓存、异步、调优这些基本功，在业务压力下做扎实。

项目中遇到的难题及解决方案

面试官您好，我将按照 STAR 法则为您详细介绍我在电商订单系统中遇到的最具挑战性的问题及解决方案。

📌 背景与问题（Situation）

我之前负责公司电商平台的订单中心模块，在去年 618 大促预热阶段，我们遇到了严重的库存超卖问题。

平时商品下单 QPS 约 100，大促预热时瞬间飙升至 5000+
超卖率最高达到 5%，导致大量用户付款后无法发货
数据库 CPU 使用率飙升至 95% 以上，出现大量慢查询和锁等待
部分热门商品甚至出现 "负库存" 现象

🎯 我的任务（Task）

作为核心开发，我需要在一周内解决库存超卖问题，同时保证系统性能不下降，确保 618 大促顺利进行。

🛠️ 解决方案（Action）

我分三个阶段逐步解决了这个问题：

阶段 1：问题排查与失败尝试

初步排查：发现问题根源是多个线程同时读取库存，然后同时扣减，导致数据不一致
失败方案 1：使用数据库悲观锁（select ... for update）
- 问题：锁粒度太大，导致大量线程阻塞，系统吞吐量下降 80%
失败方案 2：使用数据库乐观锁（版本号机制）
- 问题：高并发下冲突率极高，大量请求失败，用户体验极差

阶段 2：最终方案设计

我最终采用了 "Redis 预扣减 + MQ 异步确认 + 数据库最终一致" 的架构：

阶段 3：关键技术实现

Redis 原子操作：使用DECRBY命令保证库存扣减的原子性

Long stock = redisTemplate.opsForValue().decrementBy("stock:" + productId, quantity);
if (stock < 0) {
    // 库存不足，回滚
    redisTemplate.opsForValue().incrementBy("stock:" + productId, quantity);
    throw new InsufficientStockException();
}

库存预热：大促前将所有商品库存预热到 Redis 中
防重复扣减：使用订单号作为幂等键，防止 MQ 消息重复消费
兜底机制：定时任务对比 Redis 和数据库库存，保证最终一致性

✅ 最终结果（Result）

库存超卖率从 5% 降至0%
系统 QPS 从 5000 提升至20000+
数据库 CPU 使用率从 95% 降至30% 以下
618 大促期间系统稳定运行，没有出现任何库存相关问题
该方案被推广到公司其他业务线，成为高并发库存扣减的标准解决方案

🔥 面试官高频追问 & 标准答案

追问问题	回答要点
如果 Redis 宕机了怎么办？	1. Redis 采用主从 + 哨兵架构保证高可用 2. 降级方案：Redis 不可用时，暂时切换到数据库乐观锁 3. 熔断机制：当库存服务不可用时，暂时关闭下单功能
为什么不用分布式锁？	1. 分布式锁性能不如 Redis 原子操作 2. 分布式锁存在锁超时、死锁等问题 3. Redis 预扣减方案更简单高效，适合高并发场景
如何防止恶意下单刷库存？	1. 限制单个用户的下单频率和数量 2. 使用验证码或人机验证 3. 对异常 IP 进行限流
定时任务对比库存的频率是多少？	1. 平时每小时执行一次 2. 大促期间每 10 分钟执行一次 3. 只对比有库存变动的商品，提高效率

项目中遇到的难题及解决方案

我印象最深的一次是，在一次抢茅台活动中，出现了超卖问题，实际成交数比库存多了十几单，直接导致客诉。😰

当时我们的架构是 Spring Boot + Redisson，用 Redis 分布式锁来控制库存扣减。

简单画一下流程：

表面看这个流程没毛病，但在压测复盘时我发现——锁提前过期了。

原因是我锁的过期时间设了 3 秒，但那次抢购流量巨大，数据库那一下 RT 飙到 200ms+，加上业务代码里查库存、校验用户资格等逻辑，整个锁持有时间超过了 3 秒。于是锁自动释放，下一个线程趁虚而入，俩请求同时扣了同一份库存。

这个问题本质是：锁的占有时间 > 锁的过期时间，也就是经典的『锁误删』 + 『并发安全问题』 🔓

当时团队有两种声音，一是『把过期时间调大，比如 30 秒』，但这会带来死锁风险——万一业务线程挂了，所有请求都被卡住 30 秒。

我给的方案是：Redisson 的看门狗（Watch Dog）机制 + Lua 原子解锁 🐕。

看图：

核心改动就三步：

加锁不设 leaseTime，让 Redisson 默认开启看门狗，每 10 秒自动续期，业务多久锁就持有多久。
释放锁用 Lua 脚本，先 get 判断 value 是不是自己线程的，是才 del，保证不删别人的锁。
finally 里释放锁，确保异常也能解锁。

除了这个，我们还加了一道兜底——数据库乐观锁。SQL 改成：

UPDATE product SET stock = stock - 1 
WHERE id = #{id} AND stock > 0;

这样哪怕极端情况下锁失效，DB 层面也能拦住超卖 🛡️。

上线后用 JMeter 模拟 5000 并发，库存 100，结果成交单正好 100，不再超卖。事后复盘画了个对比图：

指标	修复前 🔴	修复后 🟢
超卖订单	15 单	0
平均锁等待时间	2.8s	0.3s
库存扣减错误率	12%	0%
业务执行期间锁安全性	过期即失控	自动续期直到释放

这样既保证了高并发下的性能，又不会因为业务抖动导致锁失控，后续连续三场大促没再出过问题。😊”

项目中如何做技术选型？

面试官您好，关于技术选型这个问题，我认为它不是简单的 "选最新的" 或者 "选最火的"，而是一个基于业务场景、团队能力和长期发展的系统性决策过程。我在过往项目中总结了一套可落地的选型方法论，分享给您：

技术选型的核心原则 🎯

我始终坚持这 4 个核心原则，它们是所有决策的基石：

完整的技术选型流程 🛠️

我会按照这个标准化流程来做，避免拍脑袋决策：

关键评估维度与打分表 ✅

我会从以下 7 个维度对每个备选方案进行量化打分（1-5 分），避免主观判断：

评估维度	权重	评估要点
业务匹配度	30%	是否能解决核心业务问题？性能是否满足？扩展性如何？
技术成熟度	20%	发布时间？社区活跃度？issue 解决速度？大厂使用情况？
团队能力	15%	团队现有技术栈？学习成本？招聘难度？
性能表现	10%	吞吐量、响应时间、并发能力、资源消耗
可维护性	10%	代码质量？文档完善度？调试难度？
生态与集成	10%	与现有系统集成？周边工具？第三方支持？
风险与成本	5%	开源协议？商业支持？运维成本？潜在风险？

Java 后端常见技术选型参考 🧑‍💻

结合我多年的经验，给您分享一些主流场景的选型建议：

1. 基础框架

首选：Spring Boot + Spring Cloud Alibaba 🌟（国内生态最好，文档齐全，坑少）
备选：Quarkus（云原生，启动快，内存占用低）
不推荐：纯 Spring MVC（开发效率低）、Dubbo 2.6 以下版本（维护性差）

2. 数据库

关系型：MySQL 8.0+（InnoDB 引擎）✅
缓存：Redis 6.0+（性能好，功能全）
搜索：Elasticsearch 7.x+（生态成熟）
时序：InfluxDB 2.x（监控场景首选）

3. 消息队列

高吞吐：Kafka（日志、大数据场景）
高可靠：RabbitMQ（业务消息，支持死信队列）
轻量级：RocketMQ（阿里开源，国内支持好）

常见的技术选型误区 ❌

盲目追新：用刚发布的技术做核心业务，踩坑无数
技术炫技：为了用而用，简单问题复杂化
个人偏好：我喜欢什么就用什么，不考虑团队
过度设计：一开始就搞分布式、微服务，杀鸡用牛刀
只看性能：忽略了开发、运维和学习成本

实际案例分享 📖

举个我之前做的电商订单系统的例子：

一开始有人提议用 Go 语言开发，说性能好
但我们团队都是 Java 背景，学习 Go 需要 2-3 个月，而且电商业务复杂，Java 生态更成熟
最终我们选择了 Spring Boot + MySQL + Redis + RocketMQ 的组合
结果：项目按时上线，性能满足要求，团队上手快，后期维护也很顺利

社区团购订单系统消息中间件选型过程

当时业务量预估：日订单量 100w+，大促会有 3~5 倍瞬时脉冲，系统要完成下单、库存扣减、支付回调、物流状态同步等流程。架构上我们希望用异步消息来解耦、削峰填谷。于是技术选型就围绕 “用哪款消息队列” 展开，主要踩了下面 5 个关键点：

1. 业务需求翻译成技术指标

别一上来就列一堆中间件名字，先把模糊的业务要求落地成可衡量的点 📋：

消息顺序性：同一个订单的状态流转必须有序（已支付→已发货→已签收），不然会出脏数据。
事务消息：下单和库存预扣要保证最终一致性，不能超卖。
积压能力：大促时下游消费可能慢，需要有亿级消息堆积能力，且不能影响上游。
延迟要求：实时性不强，秒级即可。
运维友好度：团队当时 8 个人，还要管其他服务，最好能托管。

2. 圈定候选方案，多维对比

没直接看官网吹牛，而是拉了一张客观的对比表，把公司内常用的 RocketMQ、Kafka、RabbitMQ 放在同一维度上打分 ⚖️：

维度 🧭	RocketMQ ⭐	Kafka 🔥	RabbitMQ 🐰
消息顺序性	✅ 全局/分区顺序	⚠️ 单分区有序	❌ 无严格顺序
事务消息	✅ 原生支持	❌ 不支持	❌ 不支持
堆积能力	✅ 亿级 & 不影响性能	✅ 磁盘顺序写很强	⚠️ 堆积影响性能
吞吐量	10w+ TPS	百万 TPS	万级 TPS
社区&云服务	阿里云商业版，内部推广	全球生态，云版本多	社区活跃，无商业化云
团队熟悉度	2 人有使用经验	一般了解	无经验
运维成本	中（云版低）	高（调优复杂）	低（Erlang 运维黑盒）

🎯 技术点：顺序消息 + 事务消息是刚需，这点直接筛掉了 RabbitMQ。Kafka 虽吞吐无敌，但缺少事务消息，要实现“下单=发半消息+执行本地事务+回查”就得二次封装，不划算。

3. 原型验证，不只看纸面数据

光有表格不行，我们还搭了个最小 POC 📱：

在测试环境用 RocketMQ 实现了下单事务消息，模拟极端情况：发消息超时、回查失败、Broker 宕机重启后能自动核对订单状态。
做了压测：在阿里云 4C8G 规格下，单一 topic 日累计 500w 消息无丢失，堆积 2000w 后消费者重启仍能顺序恢复。
Kafka 也跑了压测，虽然吞吐更高，但为了实现顺序+事务需要手工维护“幂等 key→分区映射”，代码侵入性强，出了 bug 很难排查 😫。

4. 团队能力与演进成本

选型不能只看框架强不强，更要看人能不能兜住 👷：

团队里两位同事之前用 RocketMQ 解决过资金结算的可靠投递，踩过“消息重复”、“业务幂等”的坑，直接复用经验。
运维方面，我们直接买阿里云 RocketMQ 商业版，省去 Broker 调优和故障转移的精力，聚焦业务。
如果硬上 Kafka，光“消费者 Rebalance 导致重复消费”这一项就需要投入额外学习成本，项目排期不允许。

5. 决策结果 + 风险预案

最终选择了 RocketMQ，同时保留了一个轻量的 Pulsar 调研（因为 pulsar 存算分离是趋势，但当时社区不够成熟，列为半年后观察项）📌。
也准备了降级方案：如果云服务故障，降级为本地 DB+定时任务 扫描未确认订单，用最笨但最稳的方式兜底。技术选型永远要想好退路。

总结 📝

技术选型本质上是一个权衡取舍的过程。没有最好的技术，只有最适合的技术。一个好的技术选型应该是：

能解决当前的业务问题
团队能够轻松驾驭
有良好的发展前景
综合成本最低

最后，我认为技术选型不是一次性的工作，而是一个持续迭代的过程。我们需要定期复盘，根据业务发展和技术进步，适时调整技术栈。

项目中如何保障系统高可用？

面试官您好，关于系统高可用的保障，我会从5 个核心维度结合我实际负责的电商订单系统经验来回答，确保每个措施都能落地见效👇

高可用整体架构全景图

五大核心保障措施

1. 架构层：从根源避免单点故障 🚫

集群化部署：所有服务至少 3 节点起步，单节点故障自动剔除，订单系统 12 台应用服务器，单台故障不影响整体
异地多活：核心业务部署北京 + 上海双机房，采用单元化架构，单机房故障时流量 100% 切到另一机房，RTO<5 分钟
限流熔断降级：用 Sentinel 实现接口级限流（下单接口 QPS=5000），超时自动熔断；非核心功能（如商品推荐）降级返回默认值

2. 服务层：提升服务容错能力 🛡️

负载均衡：LVS+Nginx 四层 + 七层负载，结合权重轮询 + IP 哈希，避免单台服务器过载
服务注册发现：Nacos 实现服务自动注册与心跳检测，不健康实例 30 秒内自动下线
超时重试：所有 RPC 调用设置合理超时时间（默认 1 秒），幂等接口最多重试 2 次，非幂等接口禁止重试

3. 数据层：保障数据不丢失 🔒

MySQL 高可用：一主两从架构，主库故障自动切换（MGR），读写分离分担读压力
Redis 高可用：3 主 3 从 + 哨兵模式，数据持久化（RDB+AOF），避免缓存雪崩
数据备份：每日全量备份 + 每小时增量备份，备份文件异地存储，定期做恢复演练

4. 运维层：提前发现潜在问题 👀

全链路监控：SkyWalking 追踪每个请求的调用链，慢接口（>500ms）自动告警
指标监控：Prometheus 监控 CPU、内存、磁盘、QPS、错误率等核心指标，设置多级告警阈值
日志中心：ELK 统一收集所有服务日志，支持按 traceId 快速定位问题

5. 应急层：快速响应故障 ⚡

灰度发布：所有上线先灰度 10% 流量，观察无问题再全量，出现问题立即回滚
故障预案：制定常见故障预案（如数据库宕机、缓存击穿），定期组织演练
混沌工程：主动注入故障（如杀死进程、断网），验证系统的容错能力

总结与加分项 💡

高可用不是单一技术就能解决的，而是架构设计 + 技术实现 + 运维体系 + 团队能力的综合结果。在我们项目中，通过以上措施，系统全年可用性达到了99.99%，平均故障恢复时间 < 10 分钟。

项目中如何保障系统高可用？

面试官您好，关于“项目中如何保障系统高可用”，我结合最近负责的电商订单系统来聊聊我们落地的思路 ⬇️

核心原则：把故障当作必然事件，分层防御、快速止损、柔性可用。

我们先看一张整体高可用架构分层图 👇

围绕这张图，我分6层防护讲一下如何保证高可用 🚀

1. 🧩 无状态化 & 集群部署 —— 让任何节点都可以被替换

所有业务服务无状态，Session 统一存到 Redis 集群
借助 Nacos 的健康检查 + Spring Cloud LoadBalancer，自动踢掉不健康节点
容器化部署在 K8s，基于 HPA 自动扩缩容，大促从容应对

💡 小技巧：我们启动时预热 JIT，避免刚扩容出来的节点性能抖动。

2. 🛡️ 流量防护 —— 限流、熔断、降级、隔离

这是最核心的组合拳，用 Sentinel 在网关和微服务层做四重防护：

线程池隔离：核心交易链路用独立线程池，慢 SQL 不会拖垮整个服务
降级策略：查询降级为缓存兜底，下单降级为异步排队，提示“稍后查看结果”
规则持久化到 Nacos，能动态秒级生效

⚠️ 踩过坑：一同事没配熔断，慢查询占满连接池，后来全线补上熔断+线程池隔离。

3. 🗄️ 数据高可用 —— 不能丢、不能慢

MySQL：半同步复制 + MGR 主从，读写分离（ShardingSphere），从库延迟超过 2 秒自动切回主库查询
Redis：Cluster 哨兵集群，数据做RDB+AOF双重持久化；缓存穿透用布隆过滤器，热点Key加本地Caffeine多级缓存
对数据库连接池做保护：HikariCP + 熔断，防止流量冲垮DB

4. 📨 中间件高可用 —— 所有依赖都要集群化

RocketMQ：DLedger 多副本集群，同步刷盘，消费位移存 DB，保证消息不丢
Nacos：3 节点 AP 模式，多机房部署，配置变更推送可靠
ES：跨可用区分片，至少 1 个副本
原则：中间件必须去单点，容忍少数节点挂掉。

5. 📊 全链路监控 & 自愈 —— 看不见的故障最可怕

Metrics：Prometheus + Grafana，大盘展示 QPS、RT、错误率、系统负载
Tracing：SkyWalking 全链路追踪，方便定位慢链
Logging：ELK 集中日志，配置慢 SQL / 错误日志告警
自动自愈：连续健康检查失败自动重启容器；CPU > 70% 自动扩容；死信队列积压自动发钉钉告警
故障发生能做到分钟级发现、5分钟内止损 ✅

6. 🚀 发布 & 容灾 —— 减少人为故障

灰度发布：通过 Nacos + Spring Cloud Gateway 元数据路由，10% 流量先验证
CI/CD 流水线：卡点检查测试覆盖率、SonarQube 扫描，再全量
全链路压测：用 JMeter+流量染色，模拟峰值3倍流量，提前发现瓶颈
故障演练：每月随机杀节点、断网，验证降级逻辑和监控告警是否真实生效
多机房同城双活还在规划，目前数据异步备份至灾备机房 🏗️

✅ 成果

通过这些手段，系统在日均数千万调用量下，全年可用性 ≥ 99.99%，扛住了多次大促。哪怕某个机房断电，也能保证核心交易不彻底中断。

线上问题排查与性能优化案例

面试官您好，我分享一个印象最深刻的线上问题：订单支付接口超时导致用户支付成功率骤降的排查与优化全过程。

问题背景 🚨

时间：2025 年双 11 大促峰值期（11 月 11 日 00:00-00:30）
现象：
- 支付接口平均响应时间从 50ms 飙升至 3s+
- 超时率从 0.01% 暴涨至 15%
- 部分服务实例出现 OOM 告警
- 用户投诉 "支付成功但订单未更新" 激增
影响：直接导致约 2000 笔订单状态异常，预估损失 GMV 50 万 +

排查流程（黄金 15 分钟）⏱️

1. 第一步：快速排查（前 5 分钟）

# 1. 查看进程状态
top -Hp <pid>
# 2. 查看GC情况
jstat -gcutil <pid> 1000
# 3. 生成线程dump
jstack <pid> > thread_dump.txt
# 4. 生成堆dump（紧急情况只dump存活对象）
jmap -dump:live,format=b,file=heap_dump.hprof <pid>

关键发现：

FullGC 每分钟执行 12 次，每次耗时 800ms+
老年代使用率持续 95% 以上
大量线程阻塞在ConcurrentHashMap.get()方法上

2. 第二步：根因定位（中间 5 分钟）

通过 MAT 分析堆 dump，发现一个本地缓存对象占用了 80% 的堆内存：

- ConcurrentHashMap$Node[] @ 0x7f8a00000000
  - size: 1,200,000 entries
  - retained heap: 2.4GB
  - 内容：订单支付流水记录

最终根因：

开发人员为了优化性能，在支付服务中添加了一个没有过期时间、没有容量限制的本地缓存，用来存储支付流水。大促期间流量暴增，缓存对象无限膨胀，导致：

堆内存耗尽，频繁 FullGC
GC 停顿时间过长，接口响应超时
ConcurrentHashMap 在高并发下的扩容竞争导致线程阻塞

紧急止血方案 🩹

立即重启所有异常服务实例（临时释放内存）
调整 JVM 参数，将堆内存从 4GB 扩容到 8GB
关闭本地缓存，所有请求直接走数据库
限流降级，将支付接口 QPS 限制在 500 以内

效果：10 分钟内，接口响应时间恢复到 100ms 以内，超时率降至 0.1% 以下。

永久优化方案 ✅

优化维度	具体措施	优化效果
缓存架构	替换为 Redis 分布式缓存，设置 15 分钟过期时间，最大内存 1GB	本地内存占用减少 90%
并发控制	使用 Caffeine 替代 ConcurrentHashMap，支持自动过期和容量限制	无扩容竞争，线程安全
数据库优化	给支付流水表添加联合索引，优化查询 SQL	单条查询耗时从 20ms 降至 2ms
JVM 优化	调整 GC 参数：-XX:+UseG1GC -XX:MaxGCPauseMillis=200	FullGC 频率降至每小时 1 次
监控告警	添加缓存命中率、内存使用率、GC 指标的告警	提前发现潜在问题

优化前后对比 📊

经验总结与通用方法论 📝

1. 线上问题排查 "三板斧"

看监控：先看系统指标（CPU、内存、磁盘、网络），再看应用指标（QPS、响应时间、错误率）
查日志：应用日志、GC 日志、系统日志，重点关注异常堆栈
做 dump：线程 dump 看阻塞，堆 dump 看内存泄漏

2. 性能优化 "三原则"

先定位再优化：不要盲目猜测，用数据说话
先紧急再永久：先止血恢复业务，再彻底解决问题
优化要有度量：优化前后必须有明确的指标对比

3. 避坑指南 ⚠️

永远不要使用无容量限制、无过期时间的本地缓存
高并发场景下慎用 ConcurrentHashMap 的自动扩容
大促前必须进行全链路压测，提前发现性能瓶颈
建立完善的监控告警体系，做到早发现早处理

订单中心接口频繁超时案例

项目背景

这是一个日活大概 200 万的电商系统，出问题的是 /order/detail 接口，上游是 App 端订单详情页，QPS 峰值在 2000 左右。有一天大促预热期，监控突然告警——P99 耗时从 200ms 飙到 3.5s，大量 504，用户进订单详情页要白屏很久 😰

🔍 现场止血与初步定位

1. 看监控大盘（我们用的是 Grafana + Prometheus）

QPS 没暴涨，正常波动，排除流量冲击。
接口 P99 飙升时段集中，但 DB 连接数、CPU 也都没打满。奇怪了。
JVM GC 日志：Young GC 频繁，平均单次耗时 80ms，偶尔有 Full GC 😱

2. 立刻 dump 堆内存

jmap -dump:format=b,file=heap.hprof <pid>

同时抓了线程栈：

jstack -l <pid> > jstack.log

3. 分析线程栈，发现大量 Tomcat 工作线程 BLOCKED 在 HashMap.get() 上。

"http-nio-8080-exec-200" #200 daemon prio=5 os_prio=0 tid=... waiting for monitor entry
java.util.HashMap.get(HashMap.java:566)
...

这说明有线程在遍历 HashMap 的同时其他线程在 put/get，引发了死循环竞争（JDK 7/8 头插法并发扩容问题）。定位到是代码里一个本地缓存用了非线程安全的 HashMap，并发读写导致死链，CPU 空转，响应超时。

4. 堆转储分析（用 Eclipse MAT）

一个大对象 localOrderCacheMap 占据了近 1.2G 堆内存，里面 Entry 数量巨大，而且对象没回收。
内存泄漏路径：SessionFactory → LocalCacheManager → ConcurrentHashMap → 内部 Entry 持有大量 Order 对象，但实际业务逻辑没有设置 TTL，只增不减 💥

问题链条基本清晰了：线程不安全的本地缓存 → 并发死链 → CPU 飙升 + 内存泄漏 → GC 频繁 → 接口超时。

🧯 止血操作：先重启了那两台出问题的服务实例，接口恢复到 400ms 左右，争取了排查时间。

🔧根因与优化方案

拆解成三个问题点，做了对症优化：

问题点	表象	根因	优化措施
1. 线程死锁/死链	线程 BLOCKED	本地缓存用 `HashMap` 应对并发读写的扩容，造成死链	替换为 `ConcurrentHashMap`，并且对热 key 做分段锁写入
2. 内存泄漏	老年代持续增长，Full GC	缓存无淘汰策略，OOM 风险	引入 Caffeine，设置 `maximumSize=10000`，`expireAfterWrite=30min`
3. 缓存击穿	某些热 key 过期瞬间大量请求打到 DB	无互斥加载	用 Caffeine 的 `refreshAfterWrite` + 线程池异步刷新，同时加一个 `LoadingCache` 的同步加载防止击穿

补充一个细节：之前那个本地缓存存的是完整的订单 DTO 对象，里面还嵌套了用户信息、物流状态，序列化开销很大。我拆成了两级缓存：

Redis 只存 protobuf 序列化 的二进制数据，体积比 JSON 小 60%，网络开销也降下来了。

📊 优化效果对比

上线后用同样压测工具（JMeter，2000 并发，持续 10 分钟）做对比：

指标	优化前	优化后	提升
P99 响应时间	3500ms	180ms	⬇️ 94.8%
吞吐量 (TPS)	300	2100	⬆️ 600%
GC 平均停顿	820ms/min	25ms/min	⬇️ 96.9%
老年代内存峰值	1.8G	600M	⬇️ 66.7%
错误率	8.2%	0%	✅

线上真实表现：大促期间接口稳定在 P99 < 200ms，没有再出现超时告警 🎉

后续做的防劣化

在 CI 流水线里加了个简单的 JMH 微基准测试，专门跑缓存读写场景，阈值提前卡死。
监控加上了 JVM 内存池增长趋势、缓存命中率、线程 BLOCKED 数量三个看板。
复盘文档沉淀到 wiki，全组分享，避免其他模块踩同样的坑。

💬 总结一下就是：工具链要熟（jstack、MAT、Arthas），排查要有序——从现象到日志到代码，最后落到优雅的治理上。 这个案例之后，我对 JVM 内存管理和并发编程的理解完全不一样了。