【发布时间】：2020-03-23 12:50:43
【问题描述】：
【问题讨论】：
-
可以贴出你应用的代码。
标签： garbage-collection apache-flink flink-streaming
【发布时间】：2020-03-23 12:50:43
【问题描述】：
我假设您正在 flink 应用程序中执行一些有状态的操作。这将导致状态由 Flink 管理，该状态将存在于堆上。如果您不清除不再相关的状态，它将继续增长并最终导致 JVM 崩溃。
此状态不会被 GC，因为它对您的应用至关重要。
【讨论】：
-
我使用 jconsole 来查看这个，它有一个用于活动 GC 的按钮，它会清理堆内存。显然它只是清理了 Flink 不再需要的堆内存。我使用 java8 并且我读过它使用默认的并行 GC。 Flink 可以修改 GC 的类型吗？
Java 的垃圾收集器很难从应用程序中控制。如果机器没有空闲，GC 可能只会在它实际达到堆限制时发生。
从您的屏幕截图中，我可以看到可能从未调用过 GC。我实际上根本没有看到任何问题。如果您不希望 java 占用超过 50 MB 的 RAM，您应该相应地设置您的 Xmx。然后 GC 将在遇到障碍时被调用。
就像对 Java 领域的一次短途旅行：当不再使用对象时，不会立即释放内存。只有在调用 GC 时，才有可能回收该内存。您为 Java VM 提供了 2 GB 的 RAM，因此它认为它可以完全使用这 2 GB 而不会引起任何问题。为了提高性能，GC 被尽可能少地调用。因此，如果您离限制太远，它可能会选择根本不运行 GC。
Java 的 GC 不断改进，Java 8 已经相当老了。较新的版本可能更具侵略性，您实际上可能会在 Java 13 上看到不同的行为。您可以直接在 JVM_ARGS 中设置 GC。但我认为没有必要这样做。
正如 Gaurav Kumar 指出的那样，某些对象可能永远不会被释放，因为它们至关重要（状态）。
但是，我认为您提供的内容没有任何问题。我猜您还有其他尚未分享的担忧。您能否以反映您最初问题背后想法的方式重新表述您的问题？
【讨论】：
-
是的，我使用 java8，Flink 1.7.1。我有一个来源：kafka topic；我处于流媒体模式。我只使用一次，我将检查点的间隔固定为 12 秒。我使用 jconsole 来查看这个结果。
-
我怀疑较新的 Java 版本会浪费更多的 CPU 周期来清理使用率低于 3% 的堆。在“游览 Java 领域”之后，值得注意的是，其他编程语言实际上也没有立即免费。只是一种不同类型的簿记可以让您绘制更好看的图表，而不会对系统产生任何真正的影响。
-
没问题，我想了解它是如何工作的。 1,8 Gb 是 jdk 的默认内存吗？或者，它是否取决于 Flink 参数？
-
这取决于你如何执行 Flink。如果你启动一个集群，Flink's default is 1 GB for task and jobmanager。如果您在 IDE 中运行，则取决于您的 java version, java implementation, and hardware。
-
我在集群中启动它。有3个流程： 1.作业管理流程； 2.任务管理器进程； 3.申请流程。进程 1 和 2 各有 1 Gb 的内存，第 3 个有 1.8 Gb，为什么？ 1.8 Gb 取决于什么？这张图描述了第3个进程的堆内存使用情况，为什么这么线性？