download：Android 面试超级攻略，全面攻破技术疑难及面试痛点

0. 前言

前阵子在生产上碰到了一个诡异景象：全量作业无奈失常进行，日志中充斥着java.util.concurrent.TimeoutException: Heartbeat of TaskManager with id container xxxx(HOSTNAME:PORT) timed out 的报错。

场景为 Oracle 全量抽取至 Hive，数据会流过 Kafka，数据量为 T 级别，依据工夫字段每天做一个分区。报错的Job 负责抽取 Kafka 的数据并写至 Hive，应用的是 TableAPI。

1. 排查思路

这个问题报到我这边的时候，有同学曾经排查过一轮了。依据网上搜寻，会告知你可能是 yarn 的压力过大、网络短暂不稳固等，能够调大 heartbeat.timeout 来缓解这个问题，经调整改问题并未解决。

另外一个说法会告知你是GC 频繁的起因。倡议调整内存，调整后，确实有肯定的成果（使出问题的工夫变慢）。那很显然和代码有关系了。

因为之前一个版本同步数据都没有出问题，因而开始寻找最近代码的改变，找了几圈下来并没有找到可疑的代码。登时感觉有点头皮发麻。于是让现场的同学切换到上个版本持续做全量，景象依旧会产生。

这时我就有点狐疑生产环境的个性了——比方数据个性，但现场的同学告知我数据并没有什么非凡之处。于是我要了一份现场的 HeapDump，丢到了剖析软件上进行查看，发现 org.apache.flink.streaming.api.functions.sink.filesystem.Bucket 的对象特地多。