一、事故现场

这是一个典型的 Java 服务卡顿现场。

业务反馈的观点是。订单后台偶尔打不开，刷新几次又恢复了。

监控里的接口曲线很有规律：

平时 RT：120ms异常时 P99：0.8s持续时间：到 秒发生频率：每隔 到 分钟一次

说到再看机器资源。

CPU 平时 %，异常瞬间升到 %堆内存长期在 % 到 %线程数没有明显增长数据库连接池也没有占满

看起来内存还有不少空间。

但日志里出现了一条关键记录：

Pause Full 4090M->2180M .317s

这句话已经解释了接口为什么会集体卡顿。说起来，

Full GC 期间发生了 Stop-The-World。业务线程需要暂停，

暂停 .317 秒接口自然也会卡 .317 秒左右。

二、你看到的 %。可能是 GC 之后的结果

• Pain Point: 监控数据显示堆内存使用率低，看不到问题。不过，
• Pain Point: 想通过单条堆曲线判断是否存在 Full GC。
• Pain Point: 监控采样间隔太大导致误判。
• Pain Point: 对 GC 日志不熟悉，不知道如何判断 Full GC 是否频繁。按理说，
• Pain Point: 想快速定位导致长时间停顿的代码方法。
• Pain Point:

很多人看到监控里的堆内存曲线，会下意识认为： 堆只用了 %所以不是内存问题

但监控通常是每 秒、 秒甚至 分钟采样一次。真实过程可能是： :: 堆占用 .3GB:: 突然创建大量临时对象:: 堆占用接近 4GB:: 触发 Full GC，暂停 .317 秒:: 回收后降到 .1GB:: 监控采样，记录 %

• "监控刚好错过了 GC 前的峰值。只采到了回收后的结果"

三、先用 jstat 确认是不是 GC 在抖

• User Concern: 如何快速确认是否是 GC 引起的停顿？说起来，
• User Concern: 想用命令行工具观察实时 GC 状态。
• User Concern: 不想停机或重启 JVM 就能排查。
• User Concern: 了解各个字段含义。
• User Concern: 能否在生产环境直接查看？bash jps -l # 假设 PID 是 ,持续观察 GC： jstat -gcutil ,1000 每秒输出一次主要看： E Eden 区使用率O Old 区使用率YGC Young GC 次数YGCT Young GC 总耗时FGC Full GC 次数FGCT Full GC 总耗时GCT GC 总耗时 说到现场观察到。S0 S1 E O M CCS YGC YGCT FGC FGCT GCT 第三行出现了两个变化： 从FGC来看，-> FGCT： -> 一次 Full GC 用了约 .317 秒。老年代从 % 降到了 % 这也证明前面的判断： 监控看到的 %，是 Full GC 回收之后的结果。按理说，

  四、打开 GC 日志。比盯着监控猜更直接

  • bUser Concern: 想要完整可视化的数据来分析停顿原因。
  • bUser Concern: 希望日志里能看到“为什么触发 Full”。bash # JDK9+ 推荐方式 再看-Xlog，gc*,safepoint:file=/data/logs/app/gc.log:time,uptime,level,tags:filecount=5。filesize=100M 线上至少应该保留这些信息：
    • GC触发原因
    • GC前后的堆大小各阶段耗时是否发生Full GCSafepoint暂停时间等。text # Pause Young # Humongous regions: # Pause Young ...3721M->3590M .214ms # Pause Full # Humongous regions: # Pause Full ...4090M->2180M .622ms 这里最的观点是，- “Humongous” 标识>10 MB 的大对象被 G1 当作单独 Region 对待；- 大量大对象会迅速填满连续 Region，从而增加 Full GC 压力。话说回来，接下来不是立刻调大 `-Xmx`。而是要找： **应用为什么在短时间内创建这么多大对象？**

      五、先看对象，再找代码入口

      • bUser Concern: 想知道“到底哪些类/对象占用了这么多内存”。怎么说呢，
      • bUser Concern: 想把热点对象定位到具体业务方法。bash # 查看堆概况 jcmd GC.heap_info # 查看直方图 jcmd GC.class_histogram> /tmp/histo-before.log # 隔一段时间再取一次 jcmd GC.class_histogram> /tmp/histo-after.log 常见位置比较靠前的对象：
        • `byte`、`char` 和 `String` 占用异常高；常见原因：`一次性读取大文件/查询大量数据/拼接超大字符串/多次序列化/JSON 大规模解析`。java // 示例：报表接口 POST /internal/order/syncAll 每隔 X 分钟执行一次。若需进一步确认，可在可控环境开启 JFR： bash jcmd JFR.start name=allocation settings=profile duration=120s filename=/tmp/allocation.jfr # 打开 JFR 后按分配热点查看 → 找到报表接口。---

          六、根因：一份 JSON 在内存里出现了好几次

          • bUser Concern: “我们只需要拉取数据并持久化，不应该让同一份 JSON 再度占据多份内存”。### 原始实现 java public int syncAllOrders { String json = restTemplate.getForObject( remoteUrl + "/orders/all",String.class);List orders = objectMapper.readValue( json,new TypeReference {});List entities = orders.stream .map .toList;orderRepository.saveAll;return entities.size;话说回来，} 远程程序的数据增长后响应体已接近 **80 MB**。*80 MB 并不等于只占 **80 MB 堆*** 整个处理过程中可能同时存在：
            • `HTTP 响应字节数组转换后的 String`
            • `Jackson`解析过程中的缓冲区— 多倍放大！
            • `DTO 列表 + Entity 列表` — 再复制一遍！
            • `批量保存时临时集合与缓存列表` — 又一层拷贝！

            所以。一份原始 JSON 在短时间内被复制成多个对象，占用数倍甚至十倍以上空间； 任务每 X 分钟执行一次上一次产生的大量临时对象还没完全回收，就开始新的一轮分配 → 老年代被推高 → G1 启动 Full GC → 所有请求都被 Stopped‑The‑World 暂停。

            ---

            七、第一版修复：不要一次性拉完

            User Pain Points Addressed：- 避免单次全量拉取导致峰值过高；- 把数据分页处理即可降低峰值占用； 怎么说呢，- 同步任务不再堵塞线上请求。java public int syncOrders { int page = 0;按理说，int pageSize = 200;int total = 0;

            while {
            OrderPage result = remoteClient.queryOrders;if .isEmpty) break;List batch =
            result.getRecords.stream
            .map
            .toList;话说回来，orderRepository.saveAll;total += batch.size;if ) break，page++;}
            return total;

            } **关键点**：
            • 每页仅持有少量实体；
            • 避免把所有结果放入一个全局 List；

            否则分页外观仍旧是 “全量”，因为所有实例仍驻留于堆中。

            ---

            八、第二版修复：必须处理大响应时用流式解析

            User Pain Points Addressed：- 上游暂不可分页 → 必须改造客户端逻辑；- 降低峰值占用，即使保持全量下载，也要即时释放。java public void importOrders throws IOException { JsonFactory factory = objectMapper.getFactory;try ) { if，= JsonToken.START_ARRAY) { throw new IllegalArgumentException;}

             List batch = new ArrayList<>;while == JsonToken.START_OBJECT) {
            OrderDTO dto = objectMapper.readValue;batch.add)，if == BATCH_SIZE) { // e.g.,BATCH_SIZE=5000 or so.
            orderRepository.saveAll;batch.clear，}
            }
            if ) { // last partial batch.
            orderRepository.saveAll;}
            

            } }
            • 流式读取+按批次写入数据库 显著降低峰值；
            • 若仍有大型缓冲区，可考虑 Streaming API + writeToFile 或使用 ObjectInputStream.

            ---

            九、为什么把 Xmx 调大不是最终答案？

            User Pain Points Addressed：- 想通过扩大堆来“撑得住”长时间停顿，却忽略更深层问题；- 担心更大的 Heap Dump 更耗磁盘与 CPU。扩容可以争取一些额外时间，但不会消除“大对象频繁分配”的根本原因。一旦数据继续增长，Full GC 会变得更频繁、更长。说到最佳顺序，
            ① 控制单次数据规模→② 降低生命周期和拷贝次数→③ .

            ---

            十、修复后的结果

            Smooth & Predictable Behavior Achieved! Monitoring now shows:
            单次最大响应从 ~80 MB 减至 ~200 KB 老年代峰值从 % 减至较低水平 Full GC 数目显著下降 P99 接口延迟从 ~800 ms 降至 ~180 ms

            ---

            十一、Full GC 排查清单

            # 开始检查
            Migrating from an older version?Here’s a concise checklist you can follow.

            🔎 Step-by-Step Flow for Spotting and Fixing Periodic Long Pauses

            Step	What to Check	Typical Tool	Key Indicators
            A. Confirm timing alignment	Is pause period matching your observed spikes?	Server logs & latency metrics	P99 spikes ≈ safepoint pause time
            B. Examine pre‑ and post‑state of memory	How much memory was before vs after stop?	jstat,jcmd heap_info,ps -aux	Sudden spike in eden/old usage before pause
            C. Review raw log entries	Look for “Pause Full” lines & reasons	/gc.log。/hs_err_pid*.log	“Humongous Allocation”,“Concurrent Mark Sweep”,etc
            D. Identify allocation hotspots	Which classes are exploding?	jcmd gc.class_histogram,JFR allocation profile	byte,char。String dominate
            E. Map hotspots back to code paths	Which service endpoints or scheduled jobs cause m?	Code review + stack traces from logs/JFR	Report endpoint /syncAll,big JSON payload
            F. Consider environment constraints	Disk space for dumps。CPU availability for extra sampling tools

            Quick Tips

            • Always capture a before and after histogram snapshot around a pause event.
            • If you’re using a containerised JVM make sure you expose enough heap – orwise GCs may get throttled silently.
            • Don’t jump straight to heap dumps on production – y can be huge and trigger furr pauses.

            ---

            ---

            十二、

            使用者痛点回顾：

            • “显示堆只有30%使用，却经常卡死。” • “不知道是不是因为某个定时任务造成的大规模临时对象。” • “想通过工具快速定位并修复，而不是盲目调参。怎么说呢，”

            再看解决思路简述。

            MOST IMPORTANT TAKEAWAYS!其实，
            Key Lessons Learned'
            No only look at memory usage percentage.	No just enlarge Xmx.	No just rely on monitoring curves.	No ignore large objects . Batching & streaming are must.

            最终根因——一次性拉取 && 全部反序列化导致同一份 JSON 在 JVM 内部出现多份拷贝。引发频繁且长时间的 Stop‑The‑World。

            方法这方面。

            • 分页或流式读取，把“一批”拆成“小批”；说起来，• 及时释放引用，不要把所有实例聚集在一个集合里；• 开启完整 GCRawLogs 与 JFR 做热点分析；•，而不是盲目扩大 Xmx。

            ---

            如果你遇到 Java 服务卡顿、“Long Pauses”、CPU 飙升或任何 Spring Boot / MySQL / Redis / Nginx 部署疑难。欢迎关注我的公众号并私信我，我可以免费帮你做初步排查与调整建议。发送问题请务必附上以下信息：

            '故障现象 + 时间点 + 脱敏完整日志 + JDK/Middleware版本 + 最近发布/配置变更截图'

            请勿发送任何密码／Token／数据库账号／服务器私钥／使用者隐私信息。说起来，如需深入操作，请提前说明范围与风险，并尽量在非高峰期完成。老实说，

            至于下一篇预告。《线程池参数到底怎么配，主要线程配置错误导致请求积压》——敬请期待！