问题描述
|
在我的过程中，我不断创建一个新的Thread对象（实际上是Thread的子类）（每秒最多几个），运行它并干净地结束。
我已经注意到，例如，当该过程进行了25天时，该过程可能会死掉而将hprof抛在后面，这意味着OOM。但是与堆中分配的内存相比，堆转储很小，因此它可能是PermGen OOM，我正在尝试找出罪魁祸首。
我没有使用任何特殊的jvm参数禁止-XX：+ HeapDumpOnOutOfMemoryError
解决方法
您的堆转储肯定会告诉您PermGen的用法-您是否看过？
无论如何，如果加载类的类加载器是GCd，则其加载的类也是GCd。通常，这是卸载类的唯一方法。您应该考虑使用应用程序级别的类加载器，并定期丢弃它。这将防止您的内存问题。
,您是否尝试过使用jhat来查看生成的转储帽子，而不仅仅是假设这是烫发问题？我不确定hrof文件的大小与正在转储的堆的大小之间是否存在直接关联。
,我正在回答这个问题，以求结案。经过大量调查，至少在我看来，创建大量线程不是OOM的罪魁祸首。
我用两种方法排除了它：
该问题是在另外两个实例中报告的，在这些情况下没有产生太多线程。
我创建了一个测试，在该测试中产生了超过250万个线程（完成了本例中的正常工作），并且没有OOM问题。
因此，仅创建大量线程就不是问题。