Java中用char[]替代String存储敏感信息，核心目的是实现安全擦除：因String不可变且可能驻留常量池，而char[]可主动调用Arrays.fill(pwd, '\0')立即覆写明文，防止内存dump泄露。
Java 中用 char[] 替代 String 处理敏感信息（如密码、密钥、令牌），核心目的是防止明文在内存中长期驻留，降低被内存转储（heap dump）、调试器或恶意代码窃取的风险。因为 String 是不可变对象，一旦创建就无法清除其内部字符数组，即使不再引用，也要等 GC 回收——而 GC 时间不可控，期间明文可能一直留在堆中；char[] 是可变的，使用完可立即手动清零。
为什么 String 不适合存敏感信息
String 在 Java 中是 final 类，其内部的 char[]（Java 8 及以前）或 byte[]（Java 9+，启用 compact strings 后）一旦初始化就不可修改。即使你把字符串变量设为 null，原字符数组仍保留在堆中，直到垃圾回收器决定清理它——这期间可能被通过 jmap -dump、VisualVM、JFR 或 JNI 直接读取到明文。另外，字符串常量池还可能导致重复或意外驻留。
如何正确使用 char[] 处理敏感数据
用 char[] 存储敏感内容后，务必在使用完毕后**立即、显式清空数组**，并尽快让引用失效。推荐做法包括：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 从用户输入（如控制台、GUI）直接读入
char[]，避免中间生成String。例如：Console.readPassword()返回的就是char[] - 若必须从
String转换（如配置项、测试场景），用string.toCharArray()，但之后立刻对原String和新char[]做清理意识处理（注意：原String本身无法清除，只能避免它出现） - 使用完
char[]后，调用Arrays.fill(chars, '\0')或循环赋'\0'清零——不要只置null引用 - 作用域尽量小，避免将
char[]作为类字段长期持有；优先放在方法局部变量中
实际操作示例（安全读取与清理）
以下是一个典型的安全密码读取片段：
立即学习“Java免费学习笔记（深入）”；
Console console = System.console();
if (console != null) {
char[] password = console.readPassword("Enter password: ");
try {
// 使用 password（如传给 PasswordAuthentication、DigestUtils 等）
authenticate(password);
} finally {
// 关键：无论成功失败，都立即清空
if (password != null) {
Arrays.fill(password, '\0');
}
}
}
注意：readPassword() 不会回显、不走标准输入流缓冲，且返回 char[]，天然规避了 String 创建。如果环境无 Console（如 Web 应用），需配合前端掩码 + HTTPS + 后端接收时直接解析为 char[]（如 Spring 的 @RequestBody 配合自定义反序列化器），避免经由 String 中转。
配套注意事项
- 日志中禁止打印
char[]或String形式的敏感内容——连Arrays.toString(pwd)都会泄露 - JVM 参数可辅助防护，如
-XX:+UseG1GC（更及时回收）、-XX:+ExplicitGCInvokesConcurrent（减少System.gc()影响），但不能替代主动清零 - 某些加密库（如 Bouncy Castle、javax.crypto）原生支持
char[]输入（如PBEKeySpec），应优先选用，而非先转成String - 注意 JVM 内存映射（如堆外内存、Native Memory）和序列化框架行为——有些框架会自动转成
String，需审查数据流
