JDK1.8为什么使用元空间代替了永久代

简介: JDK1.8为什么使用元空间代替了永久代

JDK 1.8中元空间的引入

在JDK 1.8中,元空间(Metaspace)被引入作为替代永久代(PermGen,Permanent Generation)的一部分内存模型的改变。这一改变主要是基于以下几个原因:

1. 永久代的限制

「永久代」是Java堆的一部分,用于存储类的元数据、静态变量和JVM内部用于类和方法的数据结构。它有一个固定的大小,当应用程序加载了大量的类或者大量使用反射时,永久代很容易发生溢出。这种溢出会导致OutOfMemoryError异常,而调整永久代的大小需要手动设置JVM参数(如-XX:PermSize-XX:MaxPermSize),这不仅增加了配置的复杂性,而且在不同的场景下需要不断调整,给开发和运维带来了不便。

2. 垃圾收集的复杂性

永久代的垃圾收集比较复杂,因为它涉及到类的卸载,而类的卸载又和类加载器有关。在某些情况下,即使类不再被使用,但由于类加载器的存在,类也不会被卸载,从而导致内存泄漏。此外,永久代的垃圾收集通常与Java堆的其他部分分开进行,增加了垃圾收集器的实现复杂性。

3. 向操作系统的内存模型靠拢

「元空间」使用本地内存(也就是操作系统的内存),而不是JVM堆内存。这样做的好处是元空间可以动态地根据应用程序的需求扩展大小,而不需要像永久代那样设置一个固定的大小。这种方式更加灵活,可以减少因为永久代大小不当设置导致的内存错误。

4. 性能优化

使用元空间代替永久代还有助于性能优化。因为元空间是基于本地内存的,它的扩展通常比永久代更快,且不受JVM堆大小的限制。这意味着元空间可以更快地响应类加载的需求。

5. 与HotSpot JVM的兼容性

Oracle希望通过引入元空间,简化HotSpot JVM的维护和开发,因为这样可以移除与永久代相关的代码,使得JVM的内存管理更加简洁。

结论

总的来说,「元空间」的引入是为了解决永久代固有的一些问题,如内存空间限制、垃圾收集的复杂性以及性能问题。通过使用元空间,JVM的内存管理变得更加灵活和高效,同时简化了JVM的维护工作。

相关文章
|
存储 Java
HashMap扩容机制详解
HashMap扩容机制详解
|
Java Spring
Spring Boot 2.X(八):Spring AOP 实现简单的日志切面
AOP 1.什么是 AOP ? AOP 的全称为 Aspect Oriented Programming,译为面向切面编程,是通过预编译方式和运行期动态代理实现核心业务逻辑之外的横切行为的统一维护的一种技术。
3374 1
|
存储 算法 NoSQL
还分不清 Cookie、Session、Token、JWT?看这一篇就够了
Cookie、Session、Token 和 JWT(JSON Web Token)都是用于在网络应用中进行身份验证和状态管理的机制。虽然它们有一些相似之处,但在实际应用中有着不同的作用和特点,接下来就让我们一起看看吧,本文转载至http://juejin.im/post/5e055d9ef265da33997a42cc
47597 13
荔枝派Zero(全志V3S)运行Qt5程序
本文重新配置 buildroot,利用 buildroot 重新交叉编译 Qt,编译完成后将编译产生的可执行文件拷贝到 SD 卡,板子上电后跑到文件系统下再手动运行。
294 0
|
Oracle Java 关系型数据库
Oracle jdk 的国内下载镜像
Oracle jdk 的国内下载镜像
53118 0
|
缓存 算法 安全
被追着问UUID和自增ID做主键哪个好,为什么?
讨论了UUID和自增ID作为数据库主键的优缺点。UUID全局唯一,适合分布式系统,但存储空间大,不适合范围查询。自增ID存储空间节省,查询效率高,但分库分表困难,可预测性高。UUID版本包括基于时间戳(V1)、随机数(V4)以及基于名称空间的MD5(V3)和SHA1(V5)散列。
被追着问UUID和自增ID做主键哪个好,为什么?
|
存储 大数据 关系型数据库
【数据库三大范式】让我们来聊一聊数据库的三大范式和反范式设计
数据库三大范式是指数据库设计中的规范化原则,它们分别是第一范式(1NF)第二范式(2NF)和第三范式(3NF)。第一范式(1NF)第二范式(2NF)第三范式(3NF)
|
XML Java 数据格式
Spring Bean的生命周期总结(包含面试题)
Spring Bean的生命周期总结(包含面试题)
499 0
|
SQL 存储 算法
聊聊 Sharding-JDBC 分库分表
聊聊 Sharding-JDBC 分库分表