在 JDK 1.7 及以往的 JDK 版本中，Java 类信息、常量池、静态变量都存储在 Perm（永久代）里。类的元数据和静态变量在类加载的时候分配到 Perm，当类被卸载的时候垃圾收集器从 Perm 处理掉类的元数据和静态变量。当然常量池的东西也会在 Perm 垃圾收集的时候进行处理。
JDK 1.8 的对 JVM 架构的改造将类元数据放到本地内存中，另外，将常量池和静态变量放到 Java 堆里。HotSopt VM 将会为类的元数据明确分配和释放本地内存。在这种架构下，类元信息就突破了原来 -XX:MaxPermSize 的限制，现在可以使用更多的本地内存。这样就从一定程度上解决了原来在运行时生成大量类的造成经常 Full GC 问题，如运行时使用反射、代理等。
分配本地内存发给类元数据在一个称为「块」的数据结构上，不同类元数据将会用不同大小的块存放。每个块与一个类加载器相关联，并且所有被这个类加载器加载的类元数据在这个块下分配的空间存储元数据。不同的应用块的大小将会不同，块大小的分配将会被内部碎片和外部碎片所限制。当类加载器不再使用，所有和这个类加载器相关联的块空间将会被释放。
如果服务器内存足够，升级到 JDK 1.8 修改 JVM 参数最简单的办法就是将 -XX:PermSize 和 -XX:MaxPermSize 参数替换为 -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize，因为现在里面只存元数据信息了，给它个大的空间肯定没问题。不过堆得空间因为现在要多存储原来在永久代的常量池和静态变量可能需要稍微扩大些。具体可以根据 GC 日志，和 $JAVA/bin 下的工具做一些权衡和调优
总结
通过上面分析，大家应该大致了解了 JVM 的内存划分，也清楚了 JDK 8 中永久代向元空间的转换。不过大家应该都有一个疑问，就是为什么要做这个转换？所以，最后给大家总结以下几点原因：
1、字符串存在永久代中，容易出现性能问题和内存溢出。
2、类及方法的信息等比较难确定其大小，因此对于永久代的大小指定比较困难，太小容易出现永久代溢出，太大则容易导致老年代溢出。
3、永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。
4、Oracle 可能会将HotSpot 与 JRockit 合二为一。
参考文章
Java8内存模型—永久代(PermGen)和元空间(Metaspace) - liuxiaopeng - 博客园
jdk源码剖析五：JDK8-废弃永久代（PermGen）迎来元空间（Metaspace）
标签：JDK,虚拟机,永久,类元,XX,内存,代和元,加载 来源： https://blog.csdn.net/qqchenjunwei/article/details/122026087
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。