Java内存回收.md 如何判断一个常量是废弃常量描述不正确

[wardseptember]

原文

运行时常量池主要回收的是废弃的常量。那么，我们如何判断一个常量是废弃常量呢？

假如在常量池中存在字符串 "abc"，如果当前没有任何 String 对象引用该字符串常量的话，就说明常量 "abc" 就是废弃常量，如果这时发生内存回收的话而且有必要的话，"abc" 就会被系统清理出常量池。

字符串常量池已经在堆中开辟一块空间存储了，运行时常量池里面没有字符串常量了。回收方法区更谈不上回收字符串常量池了，这里是有点小问题的。

[wangpeipei90]

@wardseptember 运行时常量池 runtime constant pool 和 字符串常量池 string pool 不是一个概念。

[wardseptember]

@wangpeipei90 这我知道，运行时常量池里面应该没有字符串常量了，待我再去查查jdk官网。

[wangpeipei90]

https://github.com/Snailclimb/JavaGuide/blob/master/docs/java/jvm/Java%E5%86%85%E5%AD%98%E5%8C%BA%E5%9F%9F.md#26-%E8%BF%90%E8%A1%8C%E6%97%B6%E5%B8%B8%E9%87%8F%E6%B1%A0

JDK1.7之前运行时常量池逻辑包含字符串常量池存放在方法区, 此时hotspot虚拟机对方法区的实现为永久代 JDK1.7 字符串常量池被从方法区拿到了堆中, 这里没有提到运行时常量池,也就是说字符串常量池被单独拿到堆,运行时常量池剩下的东西还在方法区, 也就是hotspot中的永久代 。 JDK1.8 hotspot移除了永久代用元空间(Metaspace)取而代之, 这时候字符串常量池还在堆, 运行时常量池还在方法区, 只不过方法区的实现从永久代变成了元空间(Metaspace)

应该是1.7之前的JVM GC的机制

[Snailclimb]

运行时常量池主要回收的是废弃的常量。那么，我们如何判断一个常量是废弃常量呢？

这部分描述简单完善了一下。