Java中char固定占2字节，String内存开销包含对象头等且底层存储依内容动态选择byte[]或char[]；getBytes()字节数取决于编码而非字符数×2。
Java 中 char 和 String 的内存占用本质
Java 的 char 类型固定占 2 字节，这是由 JVM 规范决定的——它始终以 UTF-16 编码单元（code unit）方式存储 Unicode 字符。这意味着无论存的是 'a' 还是 '中'，一个 char 变量在栈或数组中都占 2 个字节。
而 String 对象本身是引用类型，其内存开销不止字符数据：包含对象头、哈希码缓存、长度字段、字符/字节数据引用等。真正影响“文本体积”的是底层存储：
- JDK 9+ 启用紧凑字符串优化：若字符串只含 Latin-1 字符（U+0000–U+00FF），内部用 byte[] 存储，每个字符 1 字节；
- 一旦出现中文、emoji 等超出该范围的字符，自动回退为 char[]（即 UTF-16 表示），每个字符占 2 字节；
- 注意：String.length() 返回的是 UTF-16 code unit 个数，不是 Unicode 字符数（如 emoji ? 占 2 个 char，但只是 1 个 code point）。
getBytes() 的字节数 ≠ char 数 × 2
很多人误以为 String.getBytes().length 就是 “字符个数 × 2”，其实完全取决于指定的编码格式。String 内部是 Unicode 抽象表示，getBytes() 是一次编码转换，把 Unicode 映射成目标编码的字节序列。
-
"中".getBytes(StandardCharsets.UTF_8).length → 3（UTF-8 中文占 3 字节） -
"中".getBytes(StandardCharsets.UTF_16BE).length → 2（大端 UTF-16，无 BOM） -
"中".getBytes(StandardCharsets.GBK).length → 2（GBK 下中文也是 2 字节） -
"?".getBytes(StandardCharsets.UTF_8).length → 4（emoji 在 UTF-8 中占 4 字节）
⚠️ 特别提醒：getBytes() 无参调用会使用系统默认编码（Windows 常为 GBK，Linux/macOS 多为 UTF-8），极易引发跨平台乱码，务必显式传入 Charset。
立即学习“Java免费学习笔记（深入）”；
避免乱码的关键实践
乱码本质是“编码写入”与“解码读取”不匹配。Java 程序中常见场景及对策如下：
-
文件读写：用
Files.readString(path, StandardCharsets.UTF_8)和Files.writeString(path, str, StandardCharsets.UTF_8)，避免 FileReader/FileWriter（它们依赖默认编码）； -
网络请求：HTTP Header 显式声明
Content-Type: text/plain; charset=utf-8，客户端解析时按此 charset 解码； -
数据库交互：JDBC URL 添加
?useUnicode=true&characterEncoding=UTF-8（MySQL），并确保库/表字符集为 utf8mb4； -
IDE 与编译：IntelliJ/Eclipse 设置项目编码为 UTF-8；javac 编译时加
-encoding UTF-8参数。
Unicode 处理进阶建议
面对 emoji、古汉字、数学符号等超出基本多文种平面（BMP）的字符，仅靠 char 和 length() 会出错：
- 用
str.codePointCount(0, str.length())获取真实字符数； - 遍历 Unicode 字符应使用
str.codePoints().forEach(...)或手动配合String.offsetByCodePoints()； - 判断是否为代理对：可通过
Character.isSurrogate(c)检测单个 char 是否属于代理区； - 序列化/日志输出时，优先用
String.valueOf(codePoint)而非强制转 char，防止截断。
本质上，Java 的 String 是 Unicode 文本容器，它不“属于”任何编码格式；编码只发生在进出 JVM 边界时——理解这点，就能把字符处理从玄学变成可控工程。
