Java中不推荐用String存储密码，因其不可变性导致无法主动清除明文，只能依赖不可控的GC时机，易被内存转储、调试工具或日志意外泄露；而char[]可立即用Arrays.fill()清空，显著压缩敏感信息驻留窗口。
Java 中不推荐用 String 存储用户密码等敏感信息，核心原因是它的不可变性和内存驻留不确定性，这会显著增加明文密码被意外泄露的风险。
String 不可变，导致密码无法主动清除
一旦创建，String 对象内容就无法修改。任何“修改”操作（比如拼接、截取）都会生成新对象，原对象仍保留在堆内存中，直到垃圾回收器（GC）决定清理它。而 GC 的时机不可控——可能几秒、几分钟，甚至更久。在这期间，如果发生内存转储（memory dump）、调试器附加或恶意进程扫描，密码明文就可能被直接读出。
- 即使把变量设为
null，也只是断开引用，原 String 实例还在内存里 - String 常驻字符串常量池（尤其字面量），生命周期更长、更难清理
- 日志误打（如
log.info("pwd: {}", password)）会直接输出明文，且难以拦截
char[] 可主动擦除，控制泄露窗口
字符数组是可变的，使用完后能立即用 Arrays.fill(chars, '<p>字符数组是可变的，使用完后能立即用 <code>Arrays.fill(chars, '\0') 或其他占位符覆盖全部元素，从逻辑上抹去敏感内容。虽然 JVM 垃圾回收时仍可能残留碎片，但已大幅压缩攻击者捕获有效明文的时间窗口。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
JPasswordField.getPassword()返回char[]，Swing 官方已默认采用该模式 - 清空操作应放在
try-finally或try-with-resources的finally块中，确保执行 - 打印
char[]默认输出地址而非内容，降低日志误曝风险
现实限制：JDBC 等规范仍需 String
尽管应用层可用 char[] 管理密码，但底层接口常强制要求 String。例如 JDBC 驱动的 setPassword(String) 方法，HikariCP、Druid 等连接池均无法绕过。这意味着在调用驱动前，密码终将被转成 String —— 这是协议约束，不是编码疏忽。
立即学习“Java免费学习笔记（深入）”；
- 试图修改连接池源码支持
char[]会破坏 JDBC 兼容性，影响监控、代理、事务组件集成 - 真正有效的做法是纵深防御：加密存储、最小权限访问、网络传输加密、定期轮换、限制内存 dump 权限
- 安全目标不是“绝对不留痕”，而是让攻击成本远高于收益
更稳妥的实践建议
单纯换用 char[] 是必要但不充分的措施。生产环境应组合使用：
- 前端输入直接进
char[]，避免中间转 String - 服务端认证完成后立刻清空，不用等业务逻辑结束
- 数据库密码等配置项，优先用密钥管理服务（KMS）或环境变量 + 启动时解密
- 永远对密码做加盐哈希（如 BCrypt），绝不以明文或可逆加密形式落库
