Java OutOfMemoryError和卸载类sun.reflect.GeneratedMethodAccessor

我有一个设置为：-Xmx2048M，-Xms2048M，-XX:MaxPermSize=256M的应用程序。
有时我会在日志中收到很多消息：

[Unloading class sun.reflect.GeneratedMethodAccessor9]  
[Unloading class sun.reflect.GeneratedMethodAccessor129]  
[Unloading class sun.reflect.GeneratedMethodAccessor12]  
[Unloading class sun.reflect.GeneratedMethodAccessor11]  
[Unloading class sun.reflect.GeneratedMethodAccessor12]  
[Unloading class sun.reflect.GeneratedMethodAccessor11]  
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor29]  
[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor25]  

和获取错误：

OutOfMemoryError:Java堆空间

阅读本文后：

我知道，类是在Perm Gen中加载的，应该出现以下错误：

OutOfMemoryError:永久空间

我的问题是，为什么我有error OutOfMemoryError:Java堆空间而不是

---

OutOfMemoryError:PermGen空间？

这意味着您的堆空间不足（或者您的空间由于某种原因无法增长）

只有当此空间的最大值用完时，才会得到

PermGen空间。

作为原因

简言之，您之所以会遇到此错误，是因为您的堆空间无法增长以容纳其中的对象。

像@Peter一样，告诉您这是一个堆问题。卸载是完全垃圾收集的副作用，而不是任何出错的迹象

以下是如何解决和防止OOM：

• 允许在OOM上进行堆转储

  -XX:+HeapDumpOnAutofMemoryError

  在hotspot上，该选项没有性能损失
• 研究堆转储并了解堆的泄漏或过度使用的位置，例如从数据库中进行的大量选择
• 一旦您精通堆分析，就可以在开发期间通过jmap进行堆转储，并分析是否存在泄漏
• 如果您认为在生产中可能存在漏洞：

  jmap-histo

  是一个很好的选择，因为它只会对性能造成很小的影响

---

感谢您的回复。但此消息[卸载类sun.reflect.generatedMethodAccessor 9]表明Perm-Gen中存在问题，以及为什么我不退出内存错误：PermGen空间，或者可能先退出内存错误：PermGen，然后再退出内存错误：Java堆空间？此消息表明PermGen已清理。仅此而已。在

oomejava堆空间之前，您总是会得到一个完整的GC，这将清理所有区域，包括perm gen（即使那里有足够的空间），到目前为止，我认为，当GC无法正确清理它时，这个outofmemory错误是由软引用触发的。但是看起来，OOME还有另一个原因？软引用可以改变你的GC行为，但不会触发OMEE，除非你有数百万个。谢谢。我有几百条消息，比如卸载类sun.reflect.GeneratedMethodAccessor。堆喷溅上升到约1.8克，并触发OOEM。所以有非常密集的对象创建或只是内存泄漏？