字符串常量池内存扇区和垃圾收集

Question

我在网站上读到了这个问题：java内存池是如何划分的？我想知道“字符串常量池”属于这些扇区中的哪一个？

还有池中的字符串文字是否曾经被 GC 化？

intern（）方法从池中返回String文字的基链接。

如果池确实被 GC 处理，那么它不会对字符串池的想法适得其反吗？将再次创建新的字符串文本，使 GC 无效。

（假设池中仅存在一组特定的文本，它们永远不会过时，迟早会再次需要它们）

Answer 1

字符串池

字符串池(有时也称为字符串规范化)是用单个共享字符串对象替换多个具有相同值但不同标识的字符串对象的过程。您可以通过保留自己的映射(根据您的要求，可能有软引用或弱引用)并将映射值用作规范化值来实现这一目标。或者你可以使用JDK提供的String.intern()方法。

在Java 6中，使用String.intern（）被许多标准禁止，因为如果池化失控，很有可能获得OutOfMemoryException。Oracle Java 7 字符串池的实现发生了很大的变化。您可以在 http://bugs.sun.com/view_bug.do?bug_id=6962931 和 http://bugs.sun.com/view_bug.do?bug_id=6962930 中查找详细信息。

Java 6中的String.intern()

在那些美好的过去，所有被扣留的字符串都存储在 PermGen 中——堆的固定大小部分，主要用于存储加载的类和字符串池。除了显式的字符串之外，PermGen 字符串池还包含程序之前使用的所有文字字符串（这里使用的重要词 - 如果从未加载/调用过类或方法，则不会加载其中定义的任何常量）。

Java 6 中这种字符串池的最大问题是它的位置 – PermGen。PermGen 具有固定大小，无法在运行时扩展。您可以使用 -XX：MaxPermSize=96m 选项进行设置。据我所知，默认的PermGen大小在32M和96M之间变化，具体取决于平台。您可以增加其大小，但其大小仍将是固定的。这种限制需要非常谨慎地使用 String.intern – 您最好不要使用此方法实习任何不受控制的用户输入。这就是为什么 Java 6 时代的字符串池主要在手动管理的映射中实现。

Java 7 中的 String.intern（）

Oracle工程师对Java7中的字符串池逻辑进行了极其重要的更改——字符串池被重新定位到堆中。这意味着您不再受单独的固定大小内存区域的限制。现在，所有字符串都与大多数其他普通对象一样位于堆中，这允许您在调整应用程序时仅管理堆大小。从技术上讲，这一点就足以成为重新考虑使用String的理由。在Java 7程序中使用intern（）。但还有其他原因。

字符串池值被垃圾回收

是的，如果没有程序根对JVM字符串池中的所有字符串的引用，那么这些字符串都可以进行垃圾收集。它适用于所有讨论的Java版本。这意味着，如果您的实习生字符串超出范围，并且没有其他对它的引用，那么它将从JVM字符串池中被垃圾收集。

由于有资格进行垃圾收集并驻留在堆中，JVM字符串池似乎是所有字符串的合适位置，不是吗？理论上这是正确的——未使用的字符串将从池中被垃圾收集，使用过的字符串将允许您节省内存，以防您从输入中获得相同的字符串。似乎是一个完美的内存节省策略？几乎如此。在做出任何决定之前，您必须知道字符串池是如何实现的。

来源。

Answer 2

读取JavaDoc for String。intern（）没有给实现提供提示，但根据本页，实例化的字符串由弱引用保存。这意味着，如果GC检测到除了保存内部字符串的存储库之外，没有对内部字符串的引用，则允许收集它们。当然，这对外部代码是透明的，所以除非您使用自己的弱引用，否则您永远不会知道垃圾收集。

Answer 3

据我所知，字符串文字最终出现在非堆JVM内存的“Perm Gen”部分。Perm Gen空间仅在完整的GC运行期间进行检查(而不是部分检查)。

在早期的JVM中(我承认我不得不查一下，因为我不确定)，字符串池中的字符串文字从来没有被GC'ed过。在较新的JVM中，WeakReferences被用来引用池中的字符串，所以被保留的字符串实际上可以被GC'ed，但只是在完全垃圾收集期间。