jdk 9+ string改用byte[]+coder字段实现compact strings优化：全latin-1字符时1字节/字符，含中文等则升格utf-16双字节，纯ascii字符串内存减半，实测堆内存节省25%～30%。

Java 中 String 底层在 JDK 9 以后改用 byte[] 数组 + byte 类型的 coder 字段 来存储字符，取代了 JDK 8 及之前使用的 char[] 数组。这一改动不是简单替换，而是引入了“紧凑字符串”（Compact Strings）机制，核心目标是减少内存占用。

为什么放弃 char[]？

Java 的 char 是 16 位（2 字节），按 UTF-16 设计。但现实中大量字符串（如变量名、JSON 键、HTTP 头、日志文本）只含 ASCII 或 Latin-1 范围（0–255）字符，每个字符本可用 1 字节表示。用 2 字节存，等于白占一半内存。

• JDK 8：无论内容，“hello” 和 “你好” 都用 char[5] 或 char[2]，每个元素固定占 2 字节
• JDK 9+：系统自动判断——全 Latin-1 字符 → 用 1 字节/字符；含中文等 → 升格为 UTF-16，2 字节/字符

新结构怎么工作？

String 内部现在有两个关键字段：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• private final byte[] value：真正存字符数据的字节数组
• private final byte coder：编码标识，0 表示 LATIN1（单字节），1 表示 UTF-16（双字节）

这个判断发生在字符串创建时（如 new String("abc") 或字面量 "abc"），对开发者完全透明。例如：

• "abc" → coder = 0，value 是长度为 3 的 byte[]
• "你好" → coder = 1，value 是长度为 4 的 byte[]（两个汉字 × 2 字节）
• "abc你好" → 混合内容，整体升格为 UTF-16，coder = 1

对开发有什么实际影响？

绝大多数代码无需修改，API 行为完全兼容（length() 仍返回字符数，charAt(i) 逻辑不变）。但要注意几个隐含变化：

• 反射直接读取 String.value 得到的是 byte[]，不再是 char[]，旧反射工具可能出错
• 序列化、JNI 或手动内存操作若硬编码假设 value 是 char[]，需适配 coder 字段
• toCharArray() 等方法会临时解码复制，有少量开销，但内存节省远大于此成本

效果有多明显？

官方实测显示，在以英文为主的应用中（如微服务、Web 容器），字符串堆内存平均减少 25%～30%。GC 压力下降，CPU cache 命中率提升，equals、compareTo 在纯 Latin-1 场景下也更快——因为只需逐字节比较，不用处理 16 位 char。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南