在Java中，使用char[]而非String存储密码是否仍有意义？

早年推崇char[]的核心逻辑 #

• String是不可变类型，一旦创建就没法直接修改内容，密码明文会一直留在内存里，直到GC主动回收。如果服务器内存被dump、进程被挂起，这段明文就可能被泄露。
• char[]可以在使用完后，主动用Arrays.fill()把数组内容覆盖成垃圾数据，能立即清除内存里的明文密码，从根源上降低这类泄露风险。

为什么主流API现在都用String？ #

这不是“理念空洞”，而是现实场景里的权衡选择：

• 下游依赖的限制：像你提到的URLConnection这类基础类，内部就是用String处理数据。就算你上层用char[]传密码，最终还是会被转换成String流入底层，提前清除char[]的意义就被削弱了。
• 开发易用性优先：String是Java里最基础的字符串类型，API设计用String能降低开发者的使用门槛，减少因为char[]操作不当（比如忘了填充垃圾数据）带来的额外bug。
• 特殊场景的风险抵消：比如Thales Luna这类HSM厂商，HSM本身是硬件级的安全设备，密码传入后会立即被硬件处理并清除内存明文，String不可变性的风险在硬件防护下几乎可以忽略，厂商自然优先保证API好用。

内存泄露风险的现状 #

• 现在获取服务器内存的难度确实高了：现代操作系统有ASLR、内存分页保护这些机制，加上云环境的隔离，直接dump进程内存提取明文的攻击成本变高。
• 但风险没完全消失：如果服务器被入侵，攻击者还是能通过内存dump工具拿到敏感数据；而且Java的GC行为不可控，String可能在内存里留更久，极端情况依然有泄露可能。

实际开发的建议 #

• 如果你能完全掌控核心密码逻辑，还是推荐用char[]，用完立刻调用Arrays.fill(charArray, '\0')清除数据，尽可能降低风险。
• 如果是依赖第三方API，跟着API要求来就行，没必要强行转char[]——反正下游已经用String处理了，额外操作意义不大。
• 不管用哪种方式，绝对别把密码打日志、存缓存或者序列化到磁盘，这些行为带来的泄露风险，比存储方式的差异大得多。

内容的提问来源于stack exchange，提问作者KC Wong