Java GC幸存者空间已满

我有一个连接器（卡夫卡连接）将数据从卡夫卡传输到其他系统。在处理了60000多条记录后，速度急剧下降，最终导致连接器死机

我使用jmap命令查看GC，似乎只有我的幸存者空间已满（100%使用）

这怎么可能？幸存者空间不是一个临时的地方吗？据我所知

我不能理解的是，它在完全使用幸存者空间之前处理了60000条记录。为什么以前不会发生这种情况？难道他不应该把一部分空间留给老根来释放这个空间吗

顺便说一句：我在独立模式下运行这个连接器，堆的容量为256MB（107代表伊甸园+1代表幸存者+95代表旧版）

下面是一个示例jmap

Heap Configuration:

MinHeapFreeRatio         = 40
MaxHeapFreeRatio         = 70
MaxHeapSize              = 268435456 (256.0MB)
NewSize                  = 1363144 (1.2999954223632812MB)
MaxNewSize               = 160432128 (153.0MB)
OldSize                  = 5452592 (5.1999969482421875MB)
NewRatio                 = 2
SurvivorRatio            = 8
MetaspaceSize            = 21807104 (20.796875MB)
CompressedClassSpaceSize = 1073741824 (1024.0MB)
MaxMetaspaceSize         = 17592186044415 MB
G1HeapRegionSize         = 1048576 (1.0MB) 

Heap Usage:

G1 Heap:
regions  = 256
capacity = 268435456 (256.0MB)
used     = 130770392 (124.71236419677734MB)
free     = 137665064 (131.28763580322266MB)
48.71576726436615% used
G1 Young Generation:
Eden Space:
regions  = 107
capacity = 167772160 (160.0MB)
used     = 112197632 (107.0MB)
free     = 55574528 (53.0MB)
66.875% used
Survivor Space:
regions  = 1
capacity = 1048576 (1.0MB)
used     = 1048576 (1.0MB)
free     = 0 (0.0MB)
100.0% used
G1 Old Generation:
regions  = 18
capacity = 99614720 (95.0MB)
used     = 17524184 (16.712364196777344MB)
free     = 82090536 (78.28763580322266MB)
17.591962312397204% used`

好吧，你说的是“它的速度急剧下降”，但你甚至没有做基本的数据收集，例如，它是被固定在100%的CPU上，还是被其他资源所限制

假设它正在消耗CPU时间，下一步是确定它是花在GC中还是花在应用程序代码中。GC日志和运行jstack和jstat或探查器将在这方面有所帮助。缓解将取决于这些调查结果

---

GC后幸存者空间已满是不寻常的，但由于您正在进行流处理，分配的对象可能会很短，以至于对象无法存活足够长的时间，无法离开eden空间。如果没有更多的信息，很难判断这是否是一个问题。

我发现问题是由另一个正在进行缓冲的应用程序造成的。无论如何谢谢你

哪个JDK？希望您会说版本8或更高。从Oracle、IBM、OpenJVM或其他地方？了解您正在运行的操作系统也会很有帮助。您的推理有了飞跃。为什么你认为经济放缓与特定的GC数据有关？您应该启用GC日志记录或jstat来查看它实际花费在gcingjdk1.8、redhat7.2x8664上的时间。我确实同意它可能与GC无关，但它可能是什么（我在修复bug之前有OOM）？我在做无状态操作，基本上是读取和放置记录。会出什么问题？谢谢你的回答：）我确实看了顶部。cpu不是问题。我最终发现是某个库在做内部缓冲。无论如何，谢谢你：）