作业稳定性与性能调优：内存溢出、GC问题、算子链优化、并行度设置、资源分配

各位同学，咱们今天聊点硬核的。实时流计算跑在金融场景里，最怕什么？不是数据量大，而是作业突然挂了。内存溢出、GC风暴、算子链不合理、并行度拍脑袋定——这些坑我全踩过。今天就把这些血泪教训掰开了讲。

一、内存溢出：别等OOM了才找原因

内存溢出，说白了就是JVM堆内存不够用了。我见过最夸张的一次，某交易风控作业每半小时OOM一次，重启后半小时又挂。查了半天，发现是状态后端配置不当，RocksDB的写缓存把堆外内存撑爆了。

我个人习惯，在作业上线前先做一次内存压力测试。用生产流量的1/10跑24小时，观察堆内存使用曲线。如果曲线持续上升，说明有状态泄漏。常见的泄漏点：

• Keyed State未清理：比如ValueState只写不删，时间长了就炸
• ListState无限追加：某些场景下忘记设置最大长度
• 广播状态滥用：把全量配置塞进广播状态，每个并行实例都存一份

我曾经帮一个团队排查过，他们的作业每处理100万条数据，堆内存就涨200MB。最后发现是MapState的TTL没设置，过期数据一直堆积。加上TTL后，内存曲线直接平了。

二、GC问题：别让Full GC成为常态

GC问题在实时计算里特别隐蔽。你看着CPU不高，内存也没满，但吞吐量就是上不去。为什么？因为GC线程在后台频繁做STW（Stop-The-World）。

我建议，先看两个指标：

指标	健康值	危险值
Young GC频率	< 10次/分钟	> 30次/分钟
Full GC间隔	> 30分钟	< 5分钟
GC暂停时间	< 100ms	> 1秒

如果Full GC间隔小于5分钟，基本可以断定作业要出问题。我记得有一次线上告警，说某支付风控作业延迟飙升到30秒。上去一看，Full GC每3分钟一次，每次暂停2秒多。原因是什么？堆内存给了8GB，但新生代只分了1GB，对象频繁晋升到老年代。

调优方案其实不复杂：

• 调整新生代比例：-XX:NewRatio=2 改成 1，让新生代和老年代各占一半
• 使用G1GC：对于大堆内存（>16GB），G1比CMS更稳定
• 控制对象大小：避免在算子中创建大量临时对象，比如用StringBuilder代替字符串拼接

三、算子链优化：别让数据在算子间瞎折腾

算子链优化，说白了就是减少数据在算子之间的序列化/反序列化开销。Flink默认会尽量把能链在一起的算子合并成一个task。但有些场景下，默认行为反而会坏事。

举个例子：

// 默认会链在一起
DataStream<String> source = env.addSource(...);
source
  .map(new MyMapFunction())    // 算子1
  .filter(new MyFilterFunction()) // 算子2
  .keyBy(...)
  .window(...)
  .apply(new MyWindowFunction()); // 算子3

上面这段代码，算子1和算子2会被链在一起。但如果MyMapFunction处理逻辑很重，而MyFilterFunction过滤率很高（比如过滤掉90%的数据），链在一起反而不好。因为算子1处理完的数据，如果算子2过滤掉了，那算子1的工作就白费了。

我建议，遇到以下情况手动断开算子链：

• 过滤率高的算子：比如过滤掉80%以上数据，断开后能让下游算子少处理很多无用数据
• 计算密集的算子：比如复杂的特征工程，断开后可以单独分配更多资源
• 涉及网络I/O的算子：比如调用外部服务，断开后避免阻塞整个链

断开方式很简单：

source
  .map(new MyMapFunction()).disableChaining()  // 手动断开
  .filter(new MyFilterFunction())
  .keyBy(...)
  .window(...)
  .apply(new MyWindowFunction());

嗯，这里要注意：不要为了断开而断开。每个断开点都会引入一次序列化/反序列化，增加CPU开销。我一般只在性能瓶颈明显时才动手。

四、并行度设置：别拍脑袋，要算清楚

并行度设置，是很多同学容易忽略的点。我见过有人把并行度设成64，结果集群只有8个slot，任务全排队。也见过有人设成2，结果数据倾斜严重，一个task处理99%的数据。

我个人习惯，先算一个基准值：

并行度 = 数据源分区数 × 每条记录处理耗时(ms) × 目标吞吐量(条/秒) / 1000

举个例子：Kafka有12个分区，每条记录处理耗时约5ms，目标吞吐量是10万条/秒。那么：

并行度 = 12 × 5 × 100000 / 1000 = 6000

等等，6000显然不合理。这说明单条处理耗时太长，需要优化算子逻辑，而不是堆并行度。实际上，金融场景下，单条处理耗时一般控制在1ms以内。如果超过5ms，先查算子性能。

更实用的方法是：

• Source端：并行度等于Kafka分区数，最多不超过分区数的1.5倍
• KeyBy/Window：并行度设为Source并行度的1-2倍，避免数据倾斜
• Sink端：根据下游写入能力设定，比如数据库连接池大小

五、资源分配：别让作业饿死，也别撑死

资源分配，是作业稳定性的最后一道防线。我习惯用「三明治模型」来分配：

• TM堆内存：给足状态存储和计算用，一般建议8-16GB
• TM堆外内存：给网络缓冲和RocksDB用，建议2-4GB
• TM CPU：每个slot分配1-2个vcore，避免CPU争抢

我曾经踩过一个坑：某作业堆内存给了32GB，堆外只给了512MB。结果RocksDB的写缓存频繁触发flush，导致写入性能骤降。后来把堆外内存调到4GB，问题解决。

资源分配的几个经验：

场景	TM堆内存	TM堆外内存	每个Slot的CPU
轻量计算（无状态）	4-8GB	1-2GB	1 vcore
中等状态（窗口聚合）	8-16GB	2-4GB	1-2 vcore
重状态（CEP/复杂事件）	16-32GB	4-8GB	2-4 vcore

另外，别忘了给TaskManager预留一些内存给JVM自身。我一般会在总内存基础上多给10-15%的buffer。

知识体系总览

下面这张图，是我自己总结的稳定性调优知识体系。你可以把它当成一个检查清单，每次调优时对照着看。

这张图把五个核心模块串起来了。你想想看，内存溢出和GC问题其实是一体两面——内存管理不好，GC必然频繁。算子链优化和并行度设置又直接影响资源利用率。资源分配则是兜底方案。调优时，我习惯从监控告警开始，定位到具体瓶颈后，再针对性地调整。每次只改一个参数，观察效果后再继续。别想着一次搞定所有问题，那不现实。

好了，这一章的内容就到这里。记住：稳定性调优不是一锤子买卖，而是一个持续迭代的过程。你在生产环境里遇到的具体问题，往往比教科书上写的复杂得多。但只要你掌握了这些核心思路，再难的问题也能拆解开来，一步步解决。

---

公众号:蓝海资料掘金营，微信deep3321