其中一个就是PermGen大小真的没设够。以前在淘宝我会建议设到-XX:PermSize=256m -XX:MaxPermSize=256m（注意最小和最大设成一样来避免某些bug）。256MB很多情况下够用了。
如果是用Oracle JDK8/OpenJDK8的话，由于PermGen自身已经不存在了，也就没有PermGen爆掉的问题。替代PermGen的新的Metaspace区域默认不限大小。所以如果是PermGen大小没设够的话，升级到Oracle JDK8/OpenJDK8可以迎刃而解。

另一个是由于使用反射或动态语言而导致不断有新类加载，但之前被加载的类没有被卸载导致类元数据所使用的内存空间越来越多。

Foo必须没有任何活的实例（换句话说没有任何活引用指向Foo或其子类的实例）；
Foo对应的的java.lang.Class对象必须没有被任何活引用所指向；
Foo的defining class loader A必须没有被任何活引用所指向；如果A是bootstrap class loader的话则Foo一定不能被卸载；
A所加载的所有类都满足上述条件。

这样，class loader A及其所加载的所有类（包括Foo）才可以被卸载。上述条件有任何一条不满足都会阻碍卸载。
举个无法卸载Foo的例子：如果class loader实例A既是Foo类又是Bar类的defining class loader，并且Bar类还有活的实例，那么Foo类就肯定无法卸载

另外，还有一种可能会导致PermGen爆掉。在Sun JDK6或更老版本里的HotSpot VM不只在PermGen里放类的元数据，还会存放interned String实例。所以如果对太多不同的String调用了String.intern()的话，也可以轻松撑爆PermGen。
Oracle JDK7的HotSpot VM则把interned String挪到了普通Java heap那边而不放在PermGen里了，于是不会因为interned String太多而撑爆PermGen；Oracle JDK8进一步移除了PermGen所以就根本没有楼主提到的问题。

有一些部门在play的基础上有用spring，有一些没有；有一些用到hibernate/mybatis，有一些只用了公司特有的数据库访问工具（支持分库分表，行缓存列缓存）。总的来说，每个部门的基础框架可能有细节上的不同。

顶一个吧，看着挺不错的，有料，有资源，感觉是挺好的

加油啊，没有什么是不可以的，就看你付出多少努力了

支持一下，询问楼主，c语言2级水平。对于java一点不了解，从哪开始学习呢

楼主加油更呀，我在学习中。
�行的