在我的过程中,我不断创建一个新的Thread对象(实际上是Thread的子类)(每秒最多几个),运行它并干净地结束。
我注意到,例如,当该过程已经持续25天时,该过程可能会因为hprof而死亡,因此这意味着一个OOM。但是,与堆分配的内存相比,堆转储很小,所以它可能是一个PermGen OOM,我试图找出罪魁祸首。
我没有使用任何特殊的jvm param禁止-XX:+ HeapDumpOnOutOfMemoryError
答案 0 :(得分:0)
你的堆转储当然应该告诉你PermGen的用法 - 你看过吗?
无论如何,如果加载类的类加载器是GCd,那么它加载的类也是GCd;通常这是卸载课程的唯一方法。您应该考虑使用应用程序级类加载器,并定期丢弃它;这将阻止你的记忆问题。
答案 1 :(得分:0)
您是否尝试过使用jhat来查看生成的转储帽,而不仅仅是假设这是一个烫发问题?我不确定hrof文件的大小与正在转储的堆的大小之间存在直接关联。
答案 2 :(得分:0)
我正在回答这个问题以便关闭。经过大量调查,至少在我的情况下,创建非常大量的线程并不是 OOM的罪魁祸首。
我以两种方式排除了它:
在另外几个实例中报告了该问题,并且在这些情况下产生的线程不多。
我创建了一个测试,我生成了超过250万个线程(在我们的情况下正常工作)并且没有OOM问题。
因此,仅创建非常大量的线程不是问题。