目前，我们的服务器上存在大量内存问题。它们有时会在一小时内耗尽内存。我们有一台256GB的服务器和一台来自hetzner的E5-1650 v3 Hexa-Core。这是垃圾收集日志。
https://pastebin.com/7NUEGQs1
public void run(){}它让我把代码放在这里，即使这个问题是关于内存泄漏和垃圾收集
我不认为它会清除旧一代的任何物体，为什么分配的内存从10gb下降到9.3gb，当它真正挨饿时。
我已经尝试了一切来解决这个问题，我甚至将我的服务器重置为出厂默认设置并重新安装了所有内容。这可能是我不知道的内存泄漏。即使它是内存泄漏，这似乎也非常奇怪。它不应该快速运行那么多完整的gcs。
我们注意到的另一件事是当我们停止一台服务器时，其他3台也开始崩溃。这可能是一个ram问题，因为四个服务器中的每一个都分配了8-10 GB。
这是否意味着没有删除旧的gen对象？
3978.597：[全GC（人机工程学）[PSYoungGen：1165312K-> 647763K（2330112K）] [ParOldGen：6990613K-> 6990765K（6990848K）] 8155925K-> 7638529K（9320960K），[Metaspace：41441K-> ; 41441K（1087488K）]，3.7144066 secs] [次：用户= 34.89 sys = 0.09，真= 3.71秒]
无论我的申请是什么，它必须是非常错误的，以便从6gb的旧版数据中清除150kb吗？
ParOldGen：6990613K-> 6990765K（6990848K）
答案 0 :(得分：0)
另一个答案是完全正确的，但它并没有反映出你所说的一些不真实的假设：
当处理年轻的撤离时，通过从根开始的引用访问对象以找出无法访问的对象。
不，无法到达的人无法到达。这是提高效率的关键，因为GC运行时大多数新创建的对象都无法访问。它只处理可到达的对象，将它们复制到幸存者空间，剩下的是可用内存。 GC不知道它留下了多少无法到达的物体。它根本就不在乎。
实际上，＆＃34;垃圾收集器＆＃34;应该被称为＆＃34;非垃圾救助者＆＃34;正如它所做的那样
因此，将考虑所有对象，包括在旧代中分配的对象也会被访问并标记是否可以访问。
没有。 Eden和Survivor Spaces中无法触及的物体永远不会被触及（*）。
老一代中的对象只有在Holger解释的记忆集中才会被触及。这包括旧代中无法访问的对象，因为在次要GC期间，我们不知道哪些旧对象仍然可以访问（通常，大多数都是）。
据我所知，同时回收年轻一代和老一代的要求很高，因为这些世代位于记忆的不同连续部分。
没有。由于老一代很大，GC主要要求很高。
（*）实现finalize或扩展Reference的对象在无法访问时需要特殊处理。