技术群为String上限吵翻天？从JDK源码到JVM内存，说清字符存储极限与OOM真相

事情源于技术群里的一次热议——某大厂二面的一道经典题，让一位有五年经验的同行陷入了沉默。问题很直接：“Java 里的 String 最多能存多少个字符？”

群里的讨论立刻分成了几派：
A：“这不就是 Integer.MAX_VALUE 吗？背过八股文的都知道！”
B：“不对，我之前试过，字符串稍微大点就 OOM 了，理论值根本达不到。”
C（补刀王者）：“你们是不是忘了 JDK 版本？9 之前和之后底层都不一样！”

一个看似简单的问题，背后却关联着JVM内存模型、JDK版本演进、底层数据结构等多个知识点。今天，我们就从String的“储物箱”开始，层层剖析，彻底弄清楚它的容量极限。

一、String 的“储物箱”长啥样？JDK 版本说了算

想知道能存多少字符，得先看它用什么容器来装。

1.1 JDK 8 及以前：char 数组，每个格子 2 字节

当你写下 String s = "abc"，在 JDK 8 及之前的版本中，底层是一个 char[] value 数组。每个 char 类型固定占用 2 个字节，无论存放的是英文字母 'a' 还是汉字 '好'。

这就像一个固定大小的格子铺，每个格子大小相同，放什么进去都占一格。

1.2 JDK 9 以后：byte 数组，格子大小可变

Java 团队意识到，大部分时候存储的都是拉丁字母、数字这类 Latin-1 字符，一个字节（1 Byte）足矣。用两个字节存储，无疑是种浪费。

于是，从 JDK 9 开始，String 的底层存储改为了 byte[] value 数组。存储 Latin-1 字符时，每个字符仅占 1 字节；当需要存储中文等“大家伙”时，则采用 UTF-16 编码，每个字符占用 2 字节。

这相当于换成了可变形乐高积木——装小东西用小积木块，装大东西时自动组合成大块，显著节省了内存。

所以，当被问到“String 最大能存多少字符”时，先别急着报数字。反问一句：“您指的是哪个 JDK 版本？”这一问，能立刻展现出你考虑问题的周全性。

二、理论上限：数组长度是 int，天花板就在那儿

无论是 char[] 还是 byte[]，其本质都是数组。在 Java 中，数组的长度是用 int 类型表示的，因此其最大长度就是 int 的最大值：2^31 - 1 = 2147483647。

• JDK 8 及以前：char[] 长度上限为 2147483647，每个元素占 2 字节，因此理论上能存储 2147483647 个字符。
• JDK 9 以后：byte[] 长度上限同样为 2147483647，但能存储的字符数取决于编码：
  • 如果全是 Latin-1 字符（如英文、数字），1字符占1字节，能存 2147483647 个字符。
  • 如果全是 UTF-16 字符（如中文），1字符占2字节，能存 2147483647 / 2 = 1073741823 个字符（约10.7亿）。

这个数字听起来很唬人，对吧？但这只是数学上的“理想情况”。就像“理论上人类百米能跑进9秒”，现实中我们离博尔特还很远。为什么？因为内存这个“拦路虎”不允许。

三、实际限制：内存是“拦路虎”，OOM 比理论值先到

假设你非要在 JDK 8 环境下，创建一个长度为 2147483647 的 char 数组，我们来算算需要多少内存：
2147483647 * 2 = 4294967294 字节 ≈ 4 GB。

这还仅仅是数组本身，加上 String 对象头等开销，整个 String 对象所需内存非常接近 4GB。

然而，JVM 的默认堆内存是多少？通常是物理内存的 1/4。比如一台 8GB 内存的电脑，堆内存默认可能只有 2GB，连这个 String 所需内存的一半都装不下。

即便你手动将堆内存调大：-Xmx4G，设置为 4GB，也未必能成功创建。因为堆内存中还需要存放其他类信息、常量池、线程栈等，4GB 的空间早已被瓜分殆尽。

实际测试中，在 JDK 8 环境下，设置堆内存为 4GB，尝试 new char[2147483647]，会直接抛出 OutOfMemoryError。将长度减小到 2147483647 - 100000 左右，才有可能勉强创建，但此时 JVM 已经不堪重负。

因此，实际能存储的字符数，远小于理论值。具体多少？这取决于你的堆内存大小，以及堆内其他对象占用了多少空间。但可以肯定的是——千万别在生产环境进行这种极限测试。

四、还有个坑：编译期常量和运行期对象是两码事

上面讨论的都是运行时通过 new String() 或拼接产生的对象。还有一种字符串是在编译期就确定的常量，例如 String s = "abc"。

Java 编译器对此有一条硬性规定：字符串常量池中的字符串，其 UTF-8 编码后的字节数不能超过 65535。原因在于，class 文件中用于存储字符串常量的结构 CONSTANT_Utf8_info，使用两个字节（u2）来记录长度，最大值即为 65535。

如果你这样写：

String s = "a".repeat(65536); // 65536 个 'a'

编译时会直接报错：“常量字符串过长”。

更需要注意的是，这个 65535 限制的是字节数。如果你的字符串中包含中文，在 UTF-8 编码下，每个中文字符通常占 3 字节。那么最多只能存储 65535 / 3 ≈ 21845 个汉字，超过即编译失败。

而运行期通过 new String(new char[100000]) 创建的对象则不受此限制——只要内存足够，你可以随意创建。很多人被这道题问住，正是因为没有分清“编译期常量”和“运行期对象”的区别。

五、StringBuilder 和 StringBuffer：两个“扩容狂魔”

StringBuilder 和 StringBuffer（本文不讨论线程安全区别）的底层目前依然是 char[]（截至主流版本，尚未像 String 一样改为 byte[]），因此它们的理论上限同样是 int 的最大值。

但它们有一个显著特点：自动扩容。

例如 new StringBuilder(16)，初始容量为 16。当不断添加字符导致容量不足时，它会进行扩容：新容量 = 旧容量 × 2 + 2。如果所需容量巨大，扩容机制会尝试直接将容量扩至所需大小。

然而，再强大的扩容也逃不出 int 的范围。当 append 操作导致所需容量超过 int 最大值时，会抛出 OutOfMemoryError；或者即便没超过，但内存不足以分配如此大的数组时，同样会 OOM。

曾有测试尝试循环 append 2000 个 'a'，在大约 1000 万次循环后（总字符数约 20 亿）就因内存耗尽而 OOM 了——距离 int 的最大值（21 亿多）尚有距离，但内存已先一步告急。

所以，StringBuilder/StringBuffer 的最大字符数，理论上与 String 一致，实际上同样由内存决定。

六、面试满分回答模板

下次面试官再问：“String 最多能存多少字符？”

你可以从容地给出一个层次分明的回答：

“面试官，这个问题需要从几个维度来看，取决于您问的是哪个 JDK 版本、实际内存条件，还是编译期常量。

• JDK 8 及以前：底层为 char[]，理论最大长度为 Integer.MAX_VALUE（2147483647）个字符。但实际受内存限制，一个这样的字符串约需 4GB 堆内存，通常难以实现。
• JDK 9 及以后：底层改为 byte[]。若全为 Latin-1 字符，理论上限为 2147483647 个；若全为 UTF-16 字符（如中文），理论上限约为 10.7 亿个。
• 编译期常量：受 class 文件格式限制，UTF-8 编码字节数不得超过 65535。若全是中文，最多约 21845 个汉字。
• 运行期对象：只要堆内存充足，可以无限接近上述理论值，但通常堆内存会先成为瓶颈。
• StringBuilder/StringBuffer：理论极限同上，但其自动扩容机制可能在达到理论极限前，因内存不足而提前触发 OOM。

因此，这个问题的答案不是一个孤立的数字，而是一套结合了JVM内存管理、JDK实现演进和语言规范的组合分析。”

七、代码验证：理论与实践的结合

最后，附上几个验证代码，帮助理解（请勿在生产环境运行）。

7.1 运行时 OOM 演示（JDK 8）

public class StringMaxTest {
    public static void main(String[] args) {
        // 尝试创建一个接近理论极限的 char 数组
        int length = Integer.MAX_VALUE - 8; // 稍微减一点，避免数组头部开销
        try {
            char[] chars = new char[length];
            System.out.println("创建成功，长度：" + chars.length);
        } catch (OutOfMemoryError e) {
            System.err.println("OOM 了，理论值只是传说：" + e);
        }
    }
}

运行前可尝试调小堆内存（如 -Xmx500m），以便更快观察到 OOM。

7.2 编译期常量超长报错

public class ConstantTooLong {
    // 下面这行在编译时会报错：常量字符串过长
    public static final String LONG_STRING = "a".repeat(70000);
}

7.3 StringBuilder 扩容观察

public class StringBuilderGrow {
    public static void main(String[] args) {
        StringBuilder sb = new StringBuilder(10);
        for (int i = 0; i < 20; i++) {
            sb.append("1234567890");
            System.out.println("容量：" + sb.capacity() + "，长度：" + sb.length());
        }
    }
}

运行此程序，可以清晰地看到容量如何按“旧容量×2+2”的规则进行扩容。

八、总结

String 能存多少字符？这道题表面是考一个数字，实质是考察你对 Java 底层数据结构的理解、对 JVM 内存管理的认知、对 class 文件格式的熟悉，以及对 JDK 版本演进细节的掌握。

很多基础的面试题都是如此，水面之下暗流涌动。平时多深究一层，面试时才能游刃有余，将话题引向自己熟悉的领域。

希望这篇从技术讨论到源码分析的文章，能帮你彻底厘清这个经典问题。下次再遇到，你就可以自信地开场：“这题我熟，咱们先从 JDK 版本和底层数据结构聊起……”