Skip to content

Commit 4eeaf4d

Browse files
committed
Update Java内存区域.md
1 parent da9c0c5 commit 4eeaf4d

File tree

1 file changed

+12
-5
lines changed

1 file changed

+12
-5
lines changed

docs/java/jvm/Java内存区域.md

Lines changed: 12 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -65,7 +65,6 @@ Java 虚拟机在执行 Java 程序的过程中会把它管理的内存划分成
6565
<div align="center">
6666
<img src="https://my-blog-to-use.oss-cn-beijing.aliyuncs.com/2019-3/JVM运行时数据区域.png" width="600px"/>
6767
</div>
68-
6968
**JDK 1.8 :**
7069

7170
<div align="center">
@@ -226,14 +225,22 @@ JDK 1.8 的时候,方法区(HotSpot 的永久代)被彻底移除了(JDK1
226225
227226
### 2.6 运行时常量池
228227
229-
运行时常量池是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外,还有常量池信息(用于存放编译期生成的各种字面量和符号引用)
228+
运行时常量池是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述信息外,还有常量池表(用于存放编译期生成的各种字面量和符号引用)
230229
231230
既然运行时常量池是方法区的一部分,自然受到方法区内存的限制,当常量池无法再申请到内存时会抛出 OutOfMemoryError 错误。
232231
233-
**JDK1.7 及之后版本的 JVM 已经将运行时常量池从方法区中移了出来,在 Java 堆(Heap)中开辟了一块区域存放运行时常量池。**
232+
~~**JDK1.7 及之后版本的 JVM 已经将运行时常量池从方法区中移了出来,在 Java 堆(Heap)中开辟了一块区域存放运行时常量池。**~~
233+
234+
> 修正([issue747](https://github.com/Snailclimb/JavaGuide/issues/747)[reference](https://blog.csdn.net/q5706503/article/details/84640762)):
235+
>
236+
> 1. **JDK1.7之前运行时常量池逻辑包含字符串常量池存放在方法区, 此时hotspot虚拟机对方法区的实现为永久代**
237+
> 2. **JDK1.7 字符串常量池被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区, 也就是hotspot中的永久代**
238+
> 3. **JDK1.8 hotspot移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace)**
239+
>
240+
>
241+
>
234242
235-
![](http://my-blog-to-use.oss-cn-beijing.aliyuncs.com/18-9-14/26038433.jpg)
236-
——图片来源:https://blog.csdn.net/wangbiao007/article/details/78545189
243+
相关问题:JVM 常量池中存储的是对象还是引用呢?: https://www.zhihu.com/question/57109429/answer/151717241 by RednaxelaFX
237244
238245
239246
### 2.7 直接内存

0 commit comments

Comments
 (0)