代码中的字符串常量/文字是否会大大减慢编译速度？答案

【问题标题】：Do String constants/literals in code slow down compiling considerably?代码中的字符串常量/文字是否会大大减慢编译速度？
【发布时间】：2016-12-14 15:28:33
【问题描述】：

字符串编译时常量（内部化字符串）和文字可以与 == 进行比较，因为如果它们以某种方式相等，则在编译时为它们分配相同的引用。

这是否意味着编译由 n 个字符串字面量组成的代码需要 n log(n) 时间来编译？

我在这里问这个问题是因为有人可能已经知道答案，我不确定我是否可以编写一个测试来以可靠、可重复或重要的方式测量效果。或者该测试将反映现实世界的约束等。

不过，我会发布我能想到的任何测试用例，欢迎提出一些建议，我会尽快实施。

【问题讨论】：

我记得上次我尝试将大约 100 kB 的文本放入 String 时，结果不太好。我相信编译时间也取决于字符串长度，但不确定其趋势
为什么编译时间会在这里不同？比较仍然在运行时进行。
@DaveNewton 使用 == 的字符串比较依赖于被实习的字符串，我认为会在字符串文字的编译时发生。
实习发生在编译时，我问如果n是可实习字符串的数量，为什么会是n log(n)编译时间。在任何情况下，任何额外的时间对于合理大小的字符串都是微不足道的。
n log(n) 的概念从何而来？查找实习字符串是O(1)，因此实习字符串文字的时间是O(n)，其中n 是实习的不同字符串的数量。编译器不实习字符串，它只是将字符串嵌入到类图像中。实习发生在班级初始化时。 JLS 指定它由String.intern 完成。 docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.5

【解决方案1】：

代码中的字符串常量/文字是否会大大减慢编译速度？

没有。

字符串编译时常量（内部化字符串）和文字可以与 == 进行比较，因为如果它们以某种方式相等，则在编译时为它们分配相同的引用。

不，他们不是。它们在编译时被池化到 .class 文件的常量区域中，并且它们在类加载时被分配引用时interned。

这是否意味着编译由 n 个字符串字面量组成的代码需要 n log(n) 时间来编译？

没有。这里没有固有的 O(N log(N)) 过程。在任何合理的实现中，池化都是O(1)，通过哈希表实现，实习同上。

[当然可能构造一个编译器或intern()方法O(N log(N))或O( N^3) 或更糟，但您的问题中没有任何内容。]

【讨论】：

@HopefullyHelpful 每个字符串都在编译时存储在哈希表中。或者你问的是运行时间？
所以您在询问运行时间？它有助于回答您被问到的问题。您需要考虑空间成本和时间成本。运行时字符串池直到 Java 1.3 左右才被垃圾收集，因此在此之前它会浪费大量空间，因此 intern() 设计。在大多数执行 Java 程序中，有一半的对象是 char 数组和包含它们的字符串
是的，在任何合理的实现中，正如我在回答中已经说过的那样。